10 Functions in the CTM environment
26.2263GPPCellular text telephone modemGeneral descriptionRelease 17TS
This section gives a summary of the behavior of the CTM communication in case of an interruption in the communication, restart or rerouting during the call. Different CTM network architectures are possible and they have different behavior in these cases.
10.1 CTM to CTM communication
If both ends of the text conversation support CTM communication, then no further support within the network is necessary. The communication is robust and requires just an ordinary speech path. Even mobile-to-mobile communication will in nearly all situations be satisfyingly robust. Typically neither side of the communication is replaced during the call.
Short interruptions of the CTM channel and changes of the signal delay between the CTM partners may occur due to cell handover of the mobile system. If no CTM communication is ongoing during the handover, then no effect is visible at all. Otherwise, if a CTM burst transmission is ongoing during the handover, then resynchronisation, interleaving and FEC error correction will eliminate most or all of the effects on the output character stream, since the CTM communication resides outside of this cellular handling. At the latest, the next CTM burst will be in good shape again.
In few cases supplementary services like "call on hold", "call forwarding", "conference call" or others may be applied. Depending on these services text transmission may be influenced, but not more than in ordinary land based text telephony.
Since the CTM communication is end-to-end and no network support is needed, roaming of the mobile side to any other network is always possible. As long as the speech path is good enough even a change of the mobile system technology will be possible.
10.2 CTM between the mobile side and a gateway
In this scenario, where the CTM device on the network side is placed within a gateway to perform the adaptation between CTM and a traditional text telephone standard, typically neither side of the CTM communication (mobile and gateway) is replaced during the call. CTM re-negotiation is then not necessary. The unprotected traditional text telephony signal is completely unaffected by all handovers.
CTM interruption and signal delay variation due to cell handover is handled exactly as described above in 10.1. Same holds for supplementary services etc.
Text Telephony users roaming in other networks that do not provide CTM Gateways will have still unrestricted CTM communication with other CTM users, either on the mobile or the fixed side. When the home environment is provided also to the roaming user, then he is able to use the CTM-Gateway of his home network (the call is automatically routed through that CTM-Gateway) and he can communicate with all users of traditional text telephones as within his home network.
10.3 CTM within the transcoding equipment
In this scenario the CTM on the network side is integrated into the transcoding equipment. Since the FCC requires 100% reliable 911 emergency calls, it seems to be obvious that all transcoders within a network must be equipped with CTM functionality, or text telephone calls need to be identified and routed though these specifically equipped transcoding equipment. The effects on character transmission are similar to the cases described above in 10.1 and 10.2, as long as the transcoding equipment is not replaced during handover.
But when this transcoding equipment (and therefore the CTM device as well) is replaced during cell handover, then more adverse effects may occur.
If no CTM communication was ongoing at the moment of handover, then no major effect is visible. The newly invoked CTM device will either receive first a CTM burst from the mobile side: then it knows that CTM is available. Or it receives first text input from the network side: in this case it will insert an <ENQUIRY> character to trigger a CTM acknowledgement. After that normal CTM communication continues.
If a CTM burst was ongoing at the moment of handover, then part of the CTM burst in uplink is received by the old transcoder and the other part by the new transcoder. Depending on the length of the handover interruption and the specific transcoder architecture (which is not standardized), some of the text characters up to the full CTM burst may be corrupted or lost. The unprotected traditional text telephony signal is in this scenario also affected by the handover. Similar error effects occur in downlink. The next CTM burst will, however, be received with good quality.
10.4 Cascading of CTM adapters in the speech path
Due to various reasons it might happen that more than one CTM adapter is placed into the speech path. One example is a Mobile-to-Mobile call with CTM at both ends, but with one CTM adapter on each radio leg. Another example may be when a text telephony user has traditional equipment and starts to use CTM by buying a "smart cable". He will be able to use his old text telephone and his old mobile device and just connects them with the cable to get CTM functionality. Later he might decide to buy a new CTM based text telephone, but he forgets to replace the smart cable. Now he has two CTM devices in cascade on the mobile side.
The CTM devices within the path will in these cases never receive a traditional text telephony signal from either side and will therefore stay in transparent mode in both directions. Effectively only two CTM partners are active in all cases.
10.5 Rerouting of a call from a CTM supported environment to a non-supported environment
Due to the FCC requirement for ubiquitous text telephony support for 911 emergency calls this scenario is unlikely to occur in ordinary cell handovers.
If, by any reason, a call is rerouted during a CTM session into an environment where CTM is not supported, there is a risk of a period of text loss. If the mobile station continues to transmit CTM signals, the network base traditional text telephony device will not be able to decode it after the rerouting. The CTM at the mobile side will, however, receive suddenly traditional text telephony signals and will pass them transparently through. It may also detect this event. The use of the <ENQUIRY> burst as described above for re-negotiation is a method to discover the disruption in the CTM service.
Annex A (Informative):
CTM Receiver
The following example implementation of a CTM receiver is provided for guidance.
A.1 Demodulator
The CTM Demodulator works on a frame-by-frame basis with a nominal frame length of 40 samples. Due to the fact that the demodulator synchronizes itself permanently on the incoming bit-stream, the instantaneous frame length might be 39, 40, or 41 samples. The structure of the CTM demodulator is shown below.
Figure A.1 – Structure of the CTM demodulator
The received CTM signal is filtered by means of four band-pass filters (BP) with the frequencies 400 Hz, 600 Hz, 800 Hz, and 1000 Hz. The output signals of the band‑pass filters are rectified and low‑pass filtered (LP). The output signals of these low‑pass filters can be understood as the envelopes of the band‑pass filters. These envelope signals are used for updating the sampling instant, which takes place 39, 40, or 41 samples after the last sampling instant. This tracking is made in such a way, that the sampling takes place at time instants where the differences between the four envelope signals are as great as possible. Finally, for each frame of 39, 40, or 41 samples, a pair of two bits is decoded depending on the decision, which of the four band‑pass channels contains the maximum energy. The decoded bits contain soft information about the security of the decision. This reliability information depends on the magnitude of the difference between the envelope signals as well as on the ratio between the band-pass envelope signals and the broad‑band envelope signal, which is processed in the fifth branch (the lowest signal path in Figure A.1).
A.2 Synchronization and de-interleaver
The deinterleaver is the inverse operation of the interleaver and can be implemented accordingly.
The synchronization of the deinterleaver is based on the preamble that has been generated by the interleaver at the dummy positions as described in Section 8.2.5. Due to the special characteristics of the preamble’s auto‑correlation function, the synchronization is based on calculating the cross‑correlation function between the bit‑stream coming from the CTM demodulator and a copy of the preamble, which has been used at the transmitter side. Since the bipolar sequence 
has an auto‑correlation function with a very distinct maximum, the correct time alignment can be easily found by comparing the actual cross-correlation with an appropriate threshold value.
This regular synchronization of the deinterleaver might fail for several reasons. One reason might be an extremely weak radio channel, which prevents a correct detection of the preamble due to a high bit error rate. A second reason might be a cell handover between two transcoders, while an CTM burst is active. In either case the initial burst might not be received causing loss of synchronization.
In order to recover synchronization, the receiver is equipped with back-up synchronization. This back‑up synchronization is based on the detection of the resynchronization sequence (see Section 8.2.4). The resynchronization sequence has similar auto‑correlation properties than the preamble, which allows detecting the resynchronization sequence by means of correlation techniques. If the receiver detects this resynchronization sequence while it is in idle mode, it changes into active mode.
A.3 Puncture and resynchronization
This function eliminates the bits of the resynchronization sequence as well as the muted bits from the bit-stream. This puncturing is based on look‑up tables, which contain the bit positions that refer to resynchronization or muted bits.
The resynchronization is used for detecting non‑constant time delays on the speech traffic channel, which might occur after a cell hand‑over. The detection of the correct alignment is also based on a cross‑correlation between the received bit‑stream and a copy of the resynchronization sequence that has been inserted at the transmitter side. The resynchronization detects non‑constant delays that lead to a misalignment of up to 14 bits due to variations in the time delay of up to 35 ms.
A.4 FEC error correction
The channel decoder, which corresponds to the convolutional encoder described in Section 8.2.2, is based on the Viterbi algorithm. The Viterbi algorithm may use "Soft Decisions" in order to exploit the soft information, which is coded in the magnitude of the bits generated by the CTM demodulator. Typically, the Viterbi algorithm introduces a delay of 5·K=25 net bits for the decoding process.
The Viterbi algorithm is (re‑) initialized in the same moment as the deinterleaver switches from idle mode into active mode. The Viterbi algorithm is executed as long as the burst is running and as long as there are bits coming from the block "Puncture+Resynchronization".
Annex B (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG SA# |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
12-2000 |
10 |
SP-000569 |
Specification approved for Release 4 |
4.0.0 |
|||
|
03-2001 |
11 |
TSG-SA Plenary decided to move this spec to Release 5 |
5.0.0 |
||||
|
12-2004 |
26 |
Version for Release 6 |
5.0.0 |
6.0.0 |
|||
|
06-2007 |
36 |
Version for Release 7 |
6.0.0 |
7.0.0 |
|||
|
09-2007 |
37 |
SP-070634 |
0001 |
1 |
Requirement to send traditional text telephone signaling in case of native text conversion and CTM negotiation failure |
7.0.0 |
8.0.0 |
|
12-2009 |
46 |
Version for Release 9 |
8.0.0 |
9.0.0 |
|||
|
03-2011 |
51 |
Version for Release 10 |
9.0.0 |
10.0.0 |
|||
|
09-2012 |
57 |
Version for Release 11 |
10.0.0 |
11.0.0 |
|||
|
09-2014 |
65 |
Version for Release 12 |
11.0.0 |
12.0.0 |
|||
|
12-2015 |
70 |
Version for Release 13 |
12.0.0 |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
75 |
Version for Release 14 |
14.0.0 |
||||
|
2018-06 |
80 |
Version for Release 15 |
15.0.0 |
||||
|
2020-07 |
– |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-04 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |