A.2 Detailed Specification of IS Messages
28.0623GPPInband Tandem Free Operation (TFO) of speech codecsService descriptionStage 3TS
A.2.1 IS_REQ Message
With the IS_REQ Message an IS_Sender can test, if there is an IS Partner and indicates that it is willing to negotiate.
IS_REQ is used to initiate the IS Protocol or to indicate changes in the configuration, etc.
IS_REQ has at least one IS_Extension_Block, containing the IS_System_Identification. (see clause A.5).
Other IS_Extension_Blocks may follow, see Figure A2.1-1.
Figure A.2.1-1: General Construction of an IS_REQ Message
In general an IS_REQ Message shall be as short as possible. Special care must be taken in the design of the IS_Extension_Blocks to avoid audible effects, since sometimes an IS_REQ Message may be transmitted for quite some time (several seconds).
A.2.2 IS_ACK Message
With the IS_ACK Message an IS Partner typically answers an IS_REQ Message or an IS_ACK Message. It can also be used to submit further information to the other IS Partner. IS_REQ and IS_ACK are the main message types between IS Partners.
The IS_ACK has at least an IS_Extension_Block containing the IS_System_Identification (see clause A.5).
Other IS_Extension_Blocks may follow, see Figure A.2.2-1.
Figure A.2.2-1: General Construction of an IS_ACK Message
No specific design constraints with respect to audibility exist, since IS_ACK is typically not sent very often.
A.2.3 IS_IPE, IS_TRANS and IS_NORMAL Messages
The IPE command denotes IS_IPE Messages. An IPE shall always look for this type of message and follow the instruction. An IS_Sender shall use this IS_IPE Message to command all IPEs into a specific mode of "Bit Transparency".
This Message has one IS_Extension_Block, indicating the requested IPE_Mode. See Figure A.2.3-1.
Figure A.2.3-1: General Construction of an IS_IPE Message
No specific design constraints with respect to audibility exist, since IS_IPE is typically not sent very often.
Table A-2 defines 16 out of 32 possible IPE_Commands. The other codes are reserved for future extensions.
Table A.2.3-1: Defined IPE_Modes
|
Index |
IPE_Mode |
Code |
MEANING / ACTION |
|
hexadecimal |
|||
|
0 |
Normal |
0x00000 |
Normal Operation |
|
1 |
Trans_1_u |
0x044DC |
pass 1 LSB; 7 upper Bits are used |
|
2 |
Trans_2_u |
0x089B8 |
pass 2 LSBs; 6 upper Bits are used |
|
3 |
Trans_3_u |
0x0CD64 |
pass 3 LSBs; 5 upper Bits are used |
|
4 |
Trans_4_u |
0x11570 |
pass 4 LSBs; 4 upper Bits are used |
|
5 |
Trans_5_u |
0x151AC |
pass 5 LSBs; 3 upper Bits are used |
|
6 |
Trans_6_u |
0x19CC8 |
pass 6 LSBs; 2 upper Bits are used |
|
7 |
Trans_7_u |
0x1D814 |
pass 7 LSBs; 1 upper Bit is used |
|
8 |
Transparent |
0x22CE0 |
Full Transparent Mode for all eight bits |
|
9 |
Trans_1 |
0x2683C |
pass 1 LSB; 7 upper Bits are free and unused |
|
10 |
Trans_2 |
0x2A558 |
pass 2 LSBs; 6 upper Bits are free and unused |
|
11 |
Trans_3 |
0x2E184 |
pass 3 LSBs; 5 upper Bits are free and unused |
|
12 |
Trans_4 |
0x33990 |
pass 4 LSBs; 4 upper Bits are free and unused |
|
13 |
Trans_5 |
0x37D4C |
pass 5 LSBs; 3 upper Bits are free and unused |
|
14 |
Trans_6 |
0x3B028 |
pass 6 LSBs; 2 upper Bits are free and unused |
|
15 |
Trans_7 |
0x3F4F4 |
pass 7 LSBs; 1 upper Bit is free and unused |
|
16 |
reserved |
0x41D1C |
reserved |
|
17..31 |
reserved |
Reserved |
reserved |
The IPE_Mode is protected by the binary, systematic (16,5) block code with generator polynomial g(x) = x^11 + x^7 + x^5 + x^4 + x^2 + x + 1. The minimum Hamming distance of this code is dmin=7, which allows the correction of up to 3 bit errors within each code word of length 16 bits.
Bits 1 (MSB) and 11 are the synchronisation bits and set to "0", see Figure A-9. The EX field is set to "0.0" in all currently defined IPE_Modes, i.e. no further IS_Extension_Block is following.
Table A2.3-2 defines the coding in hexadecimal notation for the complete IPE_Mode_Extension_Block, with EX := 00.
Figure A.2.3-2: IPE_Mode_Extension_Block for the IS_IPE Message
An IS_ IPE Message containing the NORMAL command is termed IS_NORMAL Message.
An IS_ IPE Message containing a TRANS_x command is termed IS_TRANS_x Message.
An IS_ IPE Message containing a TRANS_x_u command is termed IS_TRANS_x_u Message.
The latter two are sometimes also termed IS_TRANS Message, if the details are not important.
The behaviour of IPEs, when receiving such commands, is described in Annex B.
The first IS Message in a series is often "swallowed" by IPEs (see Annex B). An IS_IPE Message must therefore never be the first message of a series of IS Messages, i.e. it shall be sent as an isolated IS Message or after a (sufficiently long) uninterrupted IS Protocol.
A.2.4 IS_FILL Message
The IS_FILL Message has no IS_Extension_Block and no specific meaning. An IS_ Sender can use the IS_FILL Message to fill a temporary gap in the protocol flow. This may be important to keep all IPEs in synchronization and open for further IS Messages, see Figure A-10. An IS_FILL Message shall also be used by the IS_Sender to resynchronize all IPEs in case of a phase shift of the Keep_Open_Indication.
Figure A.2.4-1: Construction of the IS_FILL Message
IS_FILL is designed in a way that multiple repetitions cause minimal audible effects.
A.2.5 IS_DUP Message
The IS_DUP Message may be used between IS Partners to indicate an half duplex mode. It may be especially important in Handover situations. The IS_DUP Message has no IS_Extension_Block, see Figure A.2.5-1.
Figure A.2.5-1: Construction of the IS_DUP Message
A.2.6 IS_SYL Message
The IS_SYL Message may be used between IS Partners to indicate the loss of synchronisation. It may be especially important in Handover situations. The IS_SYL Message has no IS_Extension_Block, see Figure A.2.6-1.
Figure A.2.6-1: Construction of the IS_SYL Message
A.3 Keep_Open_Indication
In Transparent_Mode, i.e. after properly receiving an IS_TRANS Message, all IPEs shall monitor the bypassing bit stream for the Keep_Open_Indication. If this Keep_Open_Indication is not seen for some time, then the IPEs shall fall automatically back into normal operation, i.e. the mode of operation before the IS_TRANS Message.
This automatic fall back shall have the same effect as the IS_NORMAL Message would have.
By definition the Keep_Open_Indication is a continuous bit stream of one "0"-Bit in the LSB of every 160th PCM sample, i.e. every 20 ms. At least one "1"-Bit must be present within the LSBs of the other 159 PCM samples, see Figure A.3-1.
Figure A.3-1: Keep_Open_Indication
The "0"-Bit stream of the Keep_Open_Indication shall always be present as long as the IPEs need to be in Transparent_Mode.
The Keep_Open_Indication shall be in phase with the preceding IS Messages., i.e. the first bit of the Keep_Open_Indication shall be in the position of the first bit of the (hypothetical) next IS Message. In fact, the IS Messages themselves contain this Keep_Open_Indication by definition.
In case of a known phase shift of the Keep_Open_Indication, the IS_Sender has to send at least one IS Message, which defines the new phase position of the Keep_Open_Indication. If no other IS Message is to be sent, then the IS_FILL Message shall be used. If an IS Message longer than 160 ms is scheduled for transmission, then an IS_FILL Message should be inserted before, to guarantee fast resynchronization of the IPEs.
A.4 Rules for Sending of IS Messages
IS Messages replace some bits of the PCM samples and therefor cause a minimal signal distortion. Therefore IS Messages shall be used with care and not longer than necessary. The IS Protocol is kept to a minimum to avoid unnecessary complexity. One basic assumption is that only one IS Protocol is active at a time between two IS Partners.
Only specific telecommunication entities shall be allowed to initiate IS Protocols. They are called IS_Active or active IS Partners. In principle these shall only be terminal devices or their "representatives" within the network. Examples are ISDN-Terminals, Speech-Servers and Transcoders (as representatives of the MSs).
Other telecommunication entities shall only react on IS Protocols. They are called IS_Passive. Most IPEs are of this type. They bypass the IS Messages, they obey the IS_IPE Messages, but they never initiate IS Messages.
Other telecommunication entities are IS_Passive by default. But if they receive IS Protocols that they can understand, then they may become IS_Active and start to initiate IS Protocols. They thus become active IS Partners and shall take care that only one IS Protocol is active on both of their sides. They are called IS_Responsive. TCMEs are examples of such entities.
Active IS Partners shall send:
– either continuous sequences of IS Messages without interruption of the 16_PCM_Sample_Grid; or
– isolated IS Messages with same message lengths; or
– isolated IS Messages with sufficient distance between them, if shorter IS Messages follow longer IS Messages.
The latter case is important, because shorter isolated IS Messages travel faster through IPEs than longer ones, see annex B.
As said above, after initialisation of an IS Message sequence, no interruption of the 16_PCM_Sample_Grid shall occur within the sequence. Adjustments of the phase position of the Keep_Open_Indication shall be done only after the IS_TRANS Message by inserting the necessary number n (with 0 n 160) of "1" Bits (termed "T_Bits") into the LSBs of the PCM samples that have to be skipped. The first PCM sample for this insertion of T_Bits is the one where the next regular IS Message or next regular Keep_Open_Indication would begin. At the new phase position the next IS Message or the IS_FILL Message shall be sent, to allow IPEs to resynchronize fast, see Figure A.4-1.
Figure A.4-1: Phase Shift of the 16_PCM_Sample_Grid by inserting T_Bits
Similarly, the adjustment of the phase between two Keep_Open_Indications shall be done by inserting the necessary number of T_Bits and by sending an IS Message – preferably, but not necessarily – the IS_FILL.
Finally a "negative" phase adjustment between two Keep_Open_Indications shall be allowed by shortening the cycle by a maximum of 2 PCM samples and sending an IS Message (see above) at the new phase position.
A.5 System Identification and IS_System_Identification_Block
The IS_System_Identification_Block is a mandatory IS_Extension_Block for the IS_ACK and IS_REQ messages with the 16-bit Information_Field containing the IS_System_Identification. It identifies the system within which the message is generated. Table A.5-1 shows the defined IS_System_Identification codes and the SysID as used in TFO16k Frames (see also Figures A.5-1 and A.5-2).
Table A.5-1: Defined SysID and IS_System_Identification Codes
|
System |
SysID (S1..S8) |
IS_System_Identification |
|
|
if EX == "0.0" |
if EX == "1.1" |
||
|
GSM |
0000.0000 |
0x53948 |
0x5394B |
|
TIA/EIA-136 (TDMA) |
0000.0001 |
0x53414 |
0x53417 |
|
TIA/EIA-95 (CDMA) |
0000.0010 |
0x528AC |
0x528AF |
|
reserved |
0000.0011 |
0x525F0 |
0x525F3 |
|
UMTS |
0000.0100 |
0x51C80 |
0x51C83 |
|
reserved |
0000.0101 |
0x511DC |
0x511DF |
|
reserved |
0000.0110 |
0x50D64 |
0x50D67 |
|
reserved |
0000.0111 |
0x50038 |
0x5003B |
All other codes are reserved. Additional IS_System_Identification Codes for other systems shall be defined in a way that the audibility is minimal and the hamming distances to the already defined codes is maximal.
The SysID is protected by the binary, systematic (16,8) block code with generator polynomial g(x) = x^8 + x^7 + x^6 + x^4 + x^2 + x + 1. The minimum Hamming distance of this code is dmin=5, which allows the correction of up to 2 bit errors within each code word of length 16 bits. The first, upper eight bits represent the systematic part, the following lower eight bits the redundant part of the code words.
The resulting 16 bits are placed into the IS_System_Extension_Block and then the whole 20 bit word is additionally EXORed with the fixed code word 0x53948 to minimize audible effects. The final result gives the IS_System_Identification and is shown in Figure A.5-1 for GSM and A.5-2 for UMTS.
Figure A.5-1: IS_System_Identification for GSM
Figure A.5-2: IS_System_Identification for UMTS
Please note that the systematic part is also used within the TFO16k Frames (S1…S8) of GSM, TIA/EIA-136, TIA/EIA-95 and UMTS systems for System Identification , see main part of the document.
Annex B (informative):
In Path Equipment: Generic Rules and Guidelines
Scope: See Annex A