11 Network implementation considerations
22.2263GPPGlobal Text Telephony (GTT)Release 17Stage 1TS
The GTT feature may be implemented in a number of ways. The GTT specifications shall allow cost effective implementations both for networks with a small part of the subscribers using GTT as well as networks with relatively many subscribers using GTT.
Annex A (informative):
Background
Text telephone systems were implemented mainly for distant conversation with deaf, hard-of-hearing, speech-impaired and deaf-blind users. The text telephone systems offer a real time, character by character, conversation in text, optionally combinable with voice. With proper implementation in mobile systems, the feature is expected to be of interest for any user.
The general user needs are described in ETSI ETR 333 Human Factors, Text Telephony; User requirements and Recommendations [2].
In PSTN, seven different, openly specified systems for text telephony exist, and are used in different regions. Some proprietary modes are also used.
The open specifications are called Baudot, DTMF, EDT, V.21, Bell103, Minitel and V.18. They all use different modem technologies and character coding for the transmission of text. They are briefly described in the annexes of ITU-T V.18 [6].
ITU-T V.18 [6] is an automoding mechanism that enables communication with all the legacy modes on the modem level. It also detects when both parties have V.18, and invokes an internationally useful character set, defined in ITU-T T.140, and optionally transmission of text and voice simultaneously. Native modulation for V.18 is V.21, while V.61 is used when simultaneous voice and text is wanted. Other modulations can be negotiated.
V.18 and T.140 are intended for use in new PSTN text telephones. They are also intended for use in gateways, bridging from the fragmented situation in the PSTN, into new services, designed according to the Total Conversation concept.
A.1 Total Conversation
Total Conversation adds text conversation to multimedia protocols in a standardised way, so that simultaneous communication in video, text and voice is accomplished. For the text part, the Unicode based text presentation protocol ITU-T T.140 is used. It is transmitted with a specific standardised transport channel for each environment. Subsets can be used for example for text telephony enabled in the multimedia architectures.
Total Conversation is currently defined in the following environments:
1. Packet networks, where the procedures described in ITU-T H.323 Annex G can be used for text conversation sessions, using TCP or RTP/T140 for the transport of T.140. A simple packet text telephone is defined, called Text SET.
2. Packet networks, where the IETF Session Initiation Protocol SIP can be used for setting up and conducting text conversation sessions using RTP/T140 for the transport of T.140 text media. RTP/T140 is MIME registered and specified in IETF RFC 2793 [9].
3. The H.324 multimedia environment in PSTN, ISDN and Mobile networks, where an AL1 channel connected by H.245 procedures is used for T.140.
4. The H.320 multimedia environment, where a H.224 channel with client ID=2 is specified for transport of T.140.
5. The T.120 data conferencing environment, that can be used alone or in conjunction with any of the environments above, where T.134 specifies the application entity and T.125 the data channel for T.140.
6. Text Telephony in the PSTN using the ITU-T V.18 modem and T.140 for the presentation without any further transport protocol.
A.2 Interworking
Interworking between these forms of Text Conversation can be achieved through the use of gateways or interworking functions. One gateway mechanism (in the process of standardisation) is ITU-T H.248, where Annex F, Facsimile, Text conversation and call discrimination packages [3] describes additions for handling text telephony and text conversation.
A.3 Additional services
Apart from the basic user – to – user conversation, the following are examples of important additional services that can be offered text telephone users and Total Conversation users.
Emergency services
The ability to call to emergency services, announce an emergency situation and discuss the actions can be offered text telephone users and Total Conversation users. Calls from the emergency service with support for text conversation is also needed.
Relay services
In order to have conversations with users of plain voice telephones, text relay services are established. Currently, manned relay services dominate, offering real time translation between written and spoken language. Automatic and semi-automatic versions are emerging. A through connection of the voice channel is usually offered as an option to satisfy users who can benefit from multiple modes.
With Total Conversation services, both traditional text relay services and other relay services are established. Examples are sign language relay services with text support during service establishment and speech-support relay services with visual enhancement.;
Annex B (informative):
Initial requirements
This section is informative and specifies the initial requirements that formed the base of definition of GTT. The 3GPP GTT specifications together define what requirements will be met.
Most requirements in this chapter are derived from the requirements expressed to be urgent by the FCC and the CTIA TTY forum in USA. The relation with these requirements are documented for each requirement.
Many of these requirements are written with the view that a PSTN text telephone is attached to the mobile station for implementation of the basic GTT functionality.
B.1 Transmission Performance
A1: The printable character error rate (PER) shall be less than 1% for stationary calls under nominal radio conditions, i.e. where also speech calls show an acceptable quality (TTY/FCC 1).
A2: The printable character error rate (PER) shall be less than 1% for calls with pedestrian speed or typical vehicle speed under nominal radio conditions (TTY/FCC 13, TTY Forum, extended).
A3: An output volume control should be provided in order to allow adaptation to existing Text Telephone equipment for optimal receiving quality (TTY/FCC 4).
A4: The input range shall be automatically adapted to the proper receiving level (new).
A5: The Text Telephone shall allow to transmit Speech and Text (VCO/HCO) in an automated way, without user interaction, either by alternating between speech and text mode or by transmitting speech and text in parallel (objective) (TTY/FCC 9, extended).
A6: The delay of the speech path shall not exceed that of a normal speech call in that situation by more than 40ms in one way, if the text telephone functionality is activated. Otherwise no additional delay shall occur to the speech signal. The delay of the speech path should not vary during a speech phrase.
A7: The delay of the text path shall not exceed that of the speech path by more than 1000 ms (one way) at typing speed of 7 characters per second. The delay of the text path may be variable.
A8: The time of switching between Text and Speech mode shall not exceed 1000 ms at normal typing speed.
A9: The printable character throughput shall not be smaller than 10 characters per second under nominal radio operating conditions (TTY/FCC 10, extended).
A10: Under impaired radio conditions the character throughput may be reduced in order to achieve the desired printable character error rate (TTY/FCC 10, modified).
A11: The signals used for transmission should pass existing fixed and wireless “analogue” speech channels with a printable character error rate below 1% under nominal radio conditions, if two devices are connected “back to back”.
A12: The data transmission bit rate should be as high as possible under the given radio conditions with the objective of 300 Bit/s with a bit error rate below 10^-3 and a residual bit error rate below
10^-5 (after removing detected bit errors).
A13: It shall be possible to transmit both, single characters, as well as long text or data strings (from file) efficiently.
A14: The transmission mechanism should provide data flow control to adapt the source data rate (when in file transfer mode) to the varying radio transmission conditions, in order not to loose data on the path.
A15: The character coding shall allow transmission of characters from any language in a consistent way.
B.2 Man Machine Interface (MMI)
These Requirements and Objectives are to some extent depending on implementation and not on the transmission standard. This list shall by no means restrict the innovation capabilities of vendors, but give guidelines and define a minimum set, against which the transmission standard needs to be checked.
B1: The Text Telephone user must be able to monitor all aspects of call progress (same or more information as provided to voice users) by tones and visualisation (TTY/FCC 2). The transmission standard shall provide the necessary monitor information to the MMI.
B2: There must be an indication, by tones and visualisation, when the call is connected or disconnected (TTY/FCC 3).
B3: Call information such as caller identification, where provided in mobile voice services, should also be provided for Text Telephony calls (TTY/FCC 11 adapted).
B4: The Text Telephone system must be able to send “Text Tones” to a normal telephone user, to indicate that he is using a text telephone, even if the other user has only a normal phone (TTY/FCC 6 adjusted).
B5: The Text Telephone user must have a means of tactile (vibrating) ring signal indication. (TTY/FCC 5), besides an acoustical and optical ring signal indication (new).
B6: Emergency calls (e.g. to 112 or 911 numbers) shall not require any further user interaction than for any normal voice call. (except to connect the possible additional equipment) (new).
B7: Call back from Emergency Call Centres should not require any further user interaction than for any normal voice call (except to connect the possible additional equipment) (new.
B8: Call setup to and from other Text Telephone users of the same type according to the new standard should not require any further user interaction than for any normal voice call (new).
B9: Call setup to and from other Text Telephone users of an other kind ( e.g. those defined in ITU V.18) may require some user activity, like
- sending a short additional precode (e.g. 2..3 digits) or
- typing a short digit sequence to invoke the service (e.g. like #55*) or
- (on user´s preference) the permanent subscription to such a service
- a capability signalling by the mobile
- activating a text telephone application
- others
B10: The new standard should allow the usage of ordinary unmodified mobile phones as already available to the user or on the mass market, in order to get the advantage of high volumes price level.
B10: The new standard shall allow to hide the intermediate (with existing phones) necessary user interaction, as described in the items before, in modern equipment (automatic service).
B11: The use of the Text Telephone for emergency calls with unregistered phones or without SIM/USIM shall be possible as for normal voice calls.
B12: The interface to the possible adapters shall be exactly specified with
- mandatory interfaces (as to allow interaction to existing Text Telephones and the basic access to the mobile phone) and
- optional interfaces (as to connect microphone and loudspeaker, the control port of the mobile phones, …)
B.3 Compatibility
C1: The standard shall be compatible to equipment on the landline side as specified in ITU recommendation V.18 (TTY/FCC 12, extended), including all annexes of V.18 and V.18 with V.61 for voice and text simultaneously
C2: The landline party’s Text Telephone equipment shall not need modifications or additions in order to be compatible and to achieve the desired error rate (TTY/FCC 7).
C3: It shall be possible to deploy the Text Telephone standard world wide in all systems based on 3GPP specifications (new).
C4: The wireless Text Telephone (i.e. on the Mobile user side) may require modifications or additions or the development of new equipment (TTY/FCC 8). The smaller the modifications or additions the better.
C5: Roaming between networks of different operators of the same kind of wireless technology shall be possible, provided the operators has installed the service.
C6: Is should be possible to connect equipment implementing the standard to any existing mobile phone of any existing wireless standard.
C7: Communication between Text Telephones in different kinds of wireless technologies shall be possible.
C8: Communication with text between mobile text telephones and multimedia devices with text shall be possible.
B.4 Complexity of Implementation and Roll Out
D1: The standard shall allow a fast first step implementation and roll out
D2: The standard shall allow integration into the mobile phone or the Text Telephone terminal or integration of everything together into a single device.
B.5 Referenced consumer requirements
In the previous sections of this annex, the “TTY /FCC” requirements refer to the points below. They are formulated in November 1999 as the consumer requirements by the TTY Forum administered by CTIA in USA. The comments are inserted here for clarification.
1. The character error rate should approximate that of AMPS, which has been demonstrated at <1% for stationary calls. More research on AMPS performance with TTY would be useful to assist in specifying a range of conditions.
2. The TTY caller must be able to visually monitor all aspects of call progress provided to voice users. Specifically, the ability to pass through sounds on the line to the TTY (so that the user can monitor ring, busy, answered-in-voice, etc.) should be provided.
3. There must be a visual indication when the call has been disconnected.
4. A volume control should be provided.
Comment: This item is intended to allow the TTY user to adjust volume for better reception of TTY tones into a mobile terminal attached TTY. It has no meaning for other solutions.
5. The TTY user must have a means of tactile (vibrating) ring signal indication.
6. The caller must be able to transmit TTY tones independent of the condition of the receiving modem.
Comment: This is to permit Text Telephone signalling, to let a hearing person know that the incoming call is from a text telephone.)
7. The landline party’s TTY must not require retrofitting in order to achieve the desired error rate.
8. The wireless party’s TTY may require retrofitting, or a new model TTY to be developed, or the use of a portable data terminal such as a personal digital assistant.
9. VCO and HCO should be supported where possible.
Comment: VCO= Voice carry over. HCO= Hearing Carry Over. These are terms for alternating voice and text in the same call.
10. Reduction of throughput (partial rate) on Baudot is highly undesirable and should not be relied upon to achieve compliance (see #7). It may be useful as a user-selectable option to improve accuracy on a given call.
11. Call information such as ANI and ALI, where provided in wireless voice, should also be provided for TTY calls.
Comment: ANI= Automatic Number Identification, ALI= Automatic Location Identification.
12. On the landline side, the solution need not support little-used or obsolete TTY models, but in general should support the embedded base of TTY’s sold over the past ten years. The landline equipment supported must not be limited to that used in Public Service Answering Points (911 centers).
13. Drive conditions must be supported, again using AMPS as a benchmark.
Annex C (informative):
Change history
|
Document history |
||
|
V. 0.0.1 |
April 2000 |
First Draft (Presented at TSG-S1 10th – 15th April 00) |
|
V.0.3.0 |
July 2000 |
Includes changes required by S1#9. |
|
V.0.3.1 |
Aug. 2000 |
Align with 3GPP doc structure |
|
V.0.3.2 |
Aug. 2000 |
Comments from Ericsson and Siemens accepted |
|
V.1.0.0 |
Sept. 2000 |
Updated to version 1.0.0 for presentation to SA #9 |
|
V.1.1.0 |
May 2001 |
Updated with output of GTT ad-hoc. To be sent for approval at SA#12 |
|
V.2.0.0 |
May 2001 |
Raised to version 2.0.0 for approval at SA #12 |
|
V5.0.0 |
June 2001 |
Approved at SA #12 |
|
V5.1.0 |
Oct. 2001 |
Creation of 5.1.0 by inclusion of CRs at SA #13 |
|
Change history |
|||||||||||
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
WI |
|
Dec 1999 |
02.01 |
Transferred to 3GPP SA1 |
8.1.0 |
3.0.0 |
|||||||
|
SP-13 |
SP-010433 |
S1-010861 |
22.226 |
001 |
Rel-5 |
F |
CR to 22.226 version 5.0.0 GTT Stage 1 as requested by SA |
5.0.0 |
5.1.0 |
GTT |
|
|
SP-15 |
SP-020045 |
S1-020457 |
22.226 |
002 |
– |
Rel-5 |
F |
Editorial CR to correct terms and references |
5.1.0 |
5.2.0 |
CORRECT |
|
SP-26 |
SP-040744 |
S1-040997 |
22.001 |
Rel-6 |
Updated from Rel-5 to Rel-6 |
5.0.0 |
6.0.0 |
||||
|
SP-36 |
22.001 |
Rel-7 |
Updated from Rel-6 to Rel-7 |
6.0.0 |
7.0.0 |
||||||
|
SP-42 |
– |
– |
Rel-8 |
Updated from Rel-7 to Rel-8 |
7.0.0 |
8.0.0 |
|||||
|
SP-46 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-9 by MCC |
8.0.0 |
9.0.0 |
|
|
2011-03 |
– |
– |
– |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.0.0 |
10.0.0 |
|
|
2012-09 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-11 by MCC |
10.0.0 |
11.0.0 |
|
|
2014-10 |
Updated to Rel-12 by MCC |
11.0.0 |
12.0.0 |
||||||||
|
2015-12 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-13 by MCC |
12.0.0 |
13.0.0 |
|
|
2017-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-14 by MCC |
13.0.0 |
14.0.0 |
|
|
2018-06 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-15 by MCC |
14.0.0 |
15.0.0 |
|
|
SA#88e |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
15.0.0 |
16.0.0 |
|
|
2022-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
16.0.0 |
17.0.0 |
|