9 Interworking to PSTN

29.0073GPPGeneral requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

9.1 Speech Calls

9.1.1 Interworking indications to PLMN terminal

An indication to inform the PLMN terminal that:

i) instead of receiving out‑of‑band indications for certain types of failure conditions, a tone or announcement will be received in‑band from the PSTN.

ii) the available compatibility information will be not exhaustive for deducing a PLMN Basic Service and there will be a limitation on address ‑ the terminal may be required to accept the call on the basis of indicating its compatibility requirements.

iii) (if a DTE) in‑band handshaking signals should be anticipated.

9.1.2 Transmission aspects

Includes control of Speech Processing and Echo Control Devices, see 3GPP TS 43.050.

9.1.3 Generation of In‑band Tones and Announcements (PLMN-PSTN)

In‑band tones and announcements shall be provided for all speech and 3,1 kHz audio bearer services between a PLMN and a PSTN.

9.2 Data Calls

Low Layer Compatibility Checking on the received PLMN bearer capability information element will be carried out by the MSC/IWF to check if the call setup is compatible to the bearer service (3,1 kHz audio) provided by a PSTN and to the IWFs provided by the PLMN.

In case the call setup does not conform to these requirements (e.g. an information transfer capability value "unrestricted digital information" is requested), the call shall fail with an error cause indicating that the network is unable to support the service requested.

As well as compatibility checking subscription checking shall be performed. If the subscription check fails the call setup shall be rejected.

For the case where the UE offers negotiable values in the PLMN bearer capability information element (e.g. both transparent and non‑transparent connection element) refer to the definitions specified in 3GPP TS 27.001.

For interworking of data calls between a PLMN and a PSTN a modem will be utilized to provide the interworking function.

Figure 1: PLMN PSTN interworking for circuit switched calls

9.2.1 Network interworking mobile originated

9.2.1.1 Selection of interworking function

The interworking function will need to negotiate with the user to establish the appropriate modem selection e.g. data rate, modulation scheme, etc. In addition, it will also be required to convert the signalling format, from a combination of out of band and in band, to that suitable for controlling the modem and the autocalling line procedure function where applicable. It is assumed that the interworking function and modems will be associated with each MSC.

For a data call originated by a circuit mode data terminal on the PLMN, the modem selection is done by using the elements "modem type" and "other modem type" in the bearer capability (PLMN-BC) of the call set‑up message.

In addition, other elements of the call setup will indicate the user rate, etc. to be used via that modem. The use of this information however means that the network is only able to select a modem from the modem pool which conforms to the speed which the terminal is utilizing at the DTE/DCE interface at the UE (e.g. V.22 for 1 200 bps). The exception to this is where the user has selected the non transparent service in which case either an autobauding or multi self selecting speed modem (e.g. V.32) may be used.

If in A/Gb or GERAN Iu mode the PLMN-BC(s) received with the set-up message indicated a multislot, 14.4 kbit/s, or EDGE-operation (refer to 3GPP TS 27.001) and the network does not support any of the required such services, the PLMN-BC(s) sent with the call proceeding message shall not contain the "fixed network user rate", "other modem type" and "user initiated modification indicator" parameters – the MSC shall discard the multislot, 14.4 kbit/s and EDGE-related parameters and use the fall-back bearer service indicated by the remaining parameters of the PLMN-BS(s) on a singleslot configuration (refer to 3GPP TS 48.020 and 3GPP TS 44.021) on the MSC/IWF-RAN link. The MSC/IWF shall modify the relevant parameters in a possibly present LLC accordingly.

If the MSC supports in A/Gb or GERAN Iu mode the multislot, 14.4 kbit/s, or EDGE-operation or if the MSC supports UTRAN Iu mode, the PLMN-BC(s) shall include the "fixed network user rate", "other modem type" and if applicable the "user initiated modification indicator" parameters of the call proceeding message if these parameters were present in the call set-up message received from the UE. In A/Gb or GERAN Iu mode the MSC shall apply on the MSC/IWF-RAN link a singleslot or multislot configuration according to the rules defined in 3GPP TS 44.021, 3GPP TS 48.020 and 3GPP TS 24.022. In case the UE signals an ACC containing TCH/F4.8 only and the network does not support TCH/F4.8 channel coding, then the MSC may act as if TCH/F9.6 were included in the ACC.

If in A/Gb or GERAN Iu mode the PLMN-BC(s) received with the set-up message did not indicate a multislot, 14.4 kbit/s or EDGE-operation, the MSC shall not include the "fixed network user rate", "other modem type" and "user initiated modification indicator" parameters in the PLMN-BC(s) of the call proceeding message – the MSC shall use a singleslot configuration on the MSC/IWF-RAN link.

The MSC may negotiate parameters with the UE according to the rules defined in 3GPP TS 27.001. The MSC/IWF shall modify the relevant parameters in a possibly present LLC accordingly.

9.2.1.2 Modem Selection

In general terms the indication of the bearer capability parameter "Information Transfer Capability" will be utilized in the call set‑up message to determine when the modem should be selected in the call.

In case of single calls, the modem function shall operate in the calling mode in case of mobile originated calls and in the answering mode in case of mobile terminated calls.

In case of dual data calls (alternate speech/facsimile group 3) the operation mode of the modem (working in calling or answering mode) depend on the initial call setup direction and on the optional parameter "Reverse Call Setup Direction" information element of the MODIFY message. If this information element is omitted the direction is derived from the initial call setup direction, i.e. the mode is the same as in case of single calls.

For the attribute value "3,1 kHz audio Ex PLMN" and "facsimile group 3", the modem will be selected immediately. The line procedure according to ITU-T Recommendation V.25 will then be carried out using the appropriate modem functions.

For the Teleservice 61 "Alternate speech/facsimile group 3", (if speech is selected as the first service), the modem is made available but not selected until the subscriber indicates the change of service request (see subclause 9.3).

For "alternate speech/facsimile group 3" calls refer to 3GPP TS 43.045 (A/Gb mode) and 3GPP TS 23.146 (UTRAN Iu mode).

9.2.1.3 Mapping of BC‑IE from PLMN to ISUP (or other)

As it cannot be determined from the called address whether the distant network is a PSTN or an ISDN the same mapping takes place as for ISDN calls (see table 7A), if ISDN signalling is used between different MSCs (e.g. on the link VMSC ‑ GMSC).

9.2.2 Network Interworking Mobile terminated PSTN Originated

This subclause describes the interworking of calls where the calling subscriber cannot generate or communicate Compatibility Information exhaustive for deducing a PLMN Basic Service to a PLMN (gateway MSC/interrogating node) because of lack of ISDN signalling capability. Thus the HLR is relieved from any compatibility checking for such calls.

Two methods of allocating UE International ISDN Numbers (MSISDNs) are allowed: Firstly, a separate MSISDN may be allocated for each service, or service option, which a subscriber uses for incoming calls; or, alternatively, a single number, applicable for all incoming calls is used.

It should be noted that it is possible for both schemes to co‑exist within the PLMN and that they are not mutually exclusive.

a) Multiple MSISDNs are used ("The Multi‑numbering Scheme"). See figure 2.

b) A single MSISDN is used ("The Single-numbering Scheme"). See figure 3.

9.2.2.1 Multi-numbering Scheme

In this scheme, the HPLMN will allocate a number of MSISDNs to a subscriber and associate with each of these numbers a Bearer Capability to identify a Bearer or a Teleservice. This Bearer Capability comprises a complete PLMN Bearer Capability (PLMN BC) information element with contents according to 3GPP TS 27.001 and coded as per 3GPP TS 24.008. In either case, when the HLR receives an interrogation relating to an incoming call (i.e. the MAP "Send Routing Information" procedure), it requests a roaming number (MSRN) from the VLR. This request will contain the PLMN BC reflecting the service associated with the called MSISDN, i.e. the PLMN BC is passed to the VLR within the MAP parameter "GSM Bearer Capability" of the message "Provide Roaming Number".

If the HLR completes the MAP "Send Routing Information" procedure by providing the MAP "GSM Bearer Capability" to the interrogating entity, as specified in sub-clause 10.2.2.3, the GMSC may then map the received PLMN BC into the User Service Information field of the IAM message sent to the succeeding node according to the rules defined in table 7A. This allows subsequent transit switches to select a codec transparent for data call (e.g. G.711). If the GMSC belongs to a Layered Architecture -backbone, it may also use the PLMN BC to select an appropriate codec for the call during the BICC codec negotiation (e.g. transparent codec for a data call).

If the MAP "GSM Bearer Capability" is not included in the MAP "Send Routing Information" response, the GMSC may use the MAP "Basic Service Code", if received in the MAP "Send Routing Information" response, to determine whether the call is a speech or data call.

At the VMSC, when the incoming call arrives, the PLMN BC associated with the MSRN are retrieved from the VLR and sent to the UE at call set‑up.

Where the PLMN specific parameter "connection element" contained in the retrieved PLMN BC‑IE, indicates dual capabilities then the VMSC shall set it according to its capabilities/preferences. Additionally the parameters correlated to "connection element" shall be modified in accordance with 3GPP TS 27.001.

The same applies to the parameter modem type if "autobauding type 1" is indicated but the IWF does not support this feature. The parameter "data compression" may also be modified according to the capabilities of the IWF.

Where single capabilities are indicated then the VMSC shall use the requested values if it is able to support the service requested. If it is unable to support the requested service then it shall set them according to its capabilities/preferences.

Where the Compatibility Information is provided in a degree exhaustive to deduce a PLMN Basic Service (see application rules in subclause 10.2.2), then the VMSC in providing the PLMN BC IE in the setup message shall set the PLMN specific parameters to its capabilities/preferences.

On receipt of a Set‑up message containing the compatibility information, the UE will analyse the contents to decide whether the service can be supported (with or without modification, see 3GPP TS 27.001) and the call will be accepted or rejected as appropriate.

The UE may negotiate parameters with the MSC according to the rules defined in 3GPP TS 27.001. If the UE proposes to the network to modify the User Rate as well as the correlated parameters Modem Type and Intermediate Rate in the call confirmed message or if the UE proposes to the network to modify the Fixed Network User Rate and Other Modem Type parameters for multislot, 14.4kbit/s, EDGE and Iu Mode operations, the network may accept or release the call (see 3GPP TS 27.001).

This negotiation takes place by means of the UE reflecting back to the MSC a complete bearer capability information element in the call confirmed message, with the relevant parameters changed. If this does not take place (i.e. if there is no PLMN BC present in the call confirmed message), than the MSC will assume that the values originally transmitted to the UE are accepted with the following exceptions:

● If in A/Gb or GERAN Iu mode, the PLMN-BC sent with the set-up message contained the "fixed network user rate", "other modem type" and if applicable the "user initiated modification indicator" parameters and no multislot, 14.4 kbit/s, and/or EDGE related parameters (refer to 3GPP TS 27.001 and 24.008) are received in the PLMN-BC of the call confirmed message or no PLMN-BC is received, the MSC shall discard the "fixed network user rate", "other modem type" and "user initiated modification indicator" parameters – the MSC shall use the fall-back bearer service indicated by the remaining parameters of the PLMN-BC on a singleslot configuration (refer to 3GPP TS 48.020 and 3GPP TS 44.021) on the MSC/IWF-RAN link.

● On the other hand, if in A/Gb or GERAN Iu mode the PLMN-BC received with the call confirmed message contain(s) multislot, 14.4kbit/s or EDGE‑related parameters the MSC shall apply on the MSC/IWF-RAN link a singleslot or multislot configuration according to the rules defined in 3GPP TS 44.021, 3GPP TS 48.020 and 3GPP TS 24.022. In case the UE signals an ACC containing TCH/F4.8 only and the network does not support TCH/F4.8 channel coding, then the MSC may act as if TCH/F9.6 were included in the ACC.

● If in UTRAN Iu mode the PLMN-BC sent with the set-up message contained the "fixed network user rate", "other modem type" and if applicable the "user initiated modification indicator" parameters, but no related parameters (refer to 3GPP TS 27.001 and 24.008) are received in the PLMN-BC of the call confirmed message or no PLMN-BC is received, the MSC shall release the call.

The VMSC may map the received PLMN BC into an ISDN BC according to the rules defined in table 7A. This ISDN BC can be transported together with possibly available LLC and HLC in the access transport parameter of the Answer message (ANM) according to ITU-T Q.763.

NOTES: (1) The HLR translates the received MSISDN_ called address (MSISDNk) into the relevant bearer capability information (BCk).

(2) Some parameters of BCk may be provided/modified according to the MSC’s capabilities/preferences. See subclause 9.2.2.

(3) In the "Call Confirmed" message, the UE may modify some parameters of the BC. See subclause 9.2.2.

(4) The VMSC may map the PLMN BC (BC’k) into an ISDN BC (BC’’k) according to the rules defined in table 7A.

Abbr.: SRI ‑ Send Routing Information.

PRN ‑ Provide Roaming Number.

MSRN ‑ Mobile Station Roaming Number.

IAM ‑ Initial Address Message.

SIFICSU ‑ Send Information For Incoming Call Set Up.

ANM- Answer Message

Figure 2: Call Flow for a mobile terminated, PSTN originated call
where the compatibility information provided are not exhaustive for deducing a PLMN Bearer Service; HLR uses multiple MSISDN numbers with corresponding BCs

9.2.2.2 Single-numbering Scheme

In the single‑numbering scheme, the HPLMN will allocate one MSISDN to a subscriber, applicable to all services.

In this case, when the HLR receives an interrogation relating to an incoming call without compatibility information exhaustive for deducing a PLMN Basic Service (i.e. the MAP "Send Routing Information" procedure), the request to the VLR for a roaming number will not contain compatibility information i.e. a PLMN BC.

At the VLR, when the incoming call arrives, there is no PLMN BC associated with the MSRN and so the call set‑up to the UE will not contain the PLMN BC information element. However, the VMSC may include all available information in the BACKUP BC information element of the call set-up message, see subclause 10.2.2.7.

In the case the PLMN was not able to provide a PLMN BC, the UE will return a complete single or dual PLMN BC in the Call Confirmed message, indicating the service required by the mobile subscriber. The VMSC will analyse this PLMN BC and optionally perform subscription checking (see 3GPP TS 22.001). If the requested PLMN BC can be supported the call is established, otherwise the call will be released.

NOTE: (1) This BC is derived from information stored in the UE, according to its configuration. The UE may also use the information provided in the Backup BC.

(2) The Backup BC may be included if the BC is missing.

(3) The VMSC may map the PLMN BC (BC) into an ISDN BC (BC’) according to the rules defined in table 7A

(4) Abbreviations: see figure 2.

Figure 3: Call Flow for a mobile terminated, PSTN originated call
where the compatibility information provided are not exhaustive for deducing a PLMN Bearer Service; HLR uses single MSISDN numbers (no corresponding BC stored). Per call MSRN allocation

9.2.3 Transparent service support

The protocol stacks for transparent services are specified in 3GPP TS 43.010 and in Clause 11a.3.

In Iu mode, the transparent services are based in the Iu User Plane protocol specified in 3GPP TS 25.415.

In A/Gb mode the rate adaptation scheme shall be utilized on the RAN to MSC link as identified in 3GPP TS 48.020. The transcoding function will generate the 64 kbit/s rate adapted format utilizing the 8 and 16 kbit/s intermediate data rates. The MSC to MSC/IWF link (e.g. in the case of handover) will utilize the same 64 kbit/s rate adaptation scheme as that indicated in 3GPP TS 48.020.

For the transparent service support the MSC/IWF will select the modem and speed based on the Compatibility information contained in either the call set‑up or call confirmed message reference subclauses 9.2.1 and 9.2.2. Where the modem type indicated is one of the multi‑speed versions, e.g. V.32, then the MSC/IWF will restrict the modem to the speed indicated in the call set‑up and call confirmed message, respectively, i.e. will inhibit the modem from changing speed, irrespective of the conditions, error rate, encountered on the PSTN link. This scenario is also applicable for the use of "autobauding" modems, in that only the specifically requested modem type and speed will be selected at the MSC/IWF (however Facsimile Group 3 can use channel mode modify).

9.2.3.1 Structure of the MSC/IWF for Iu mode

The transmission towards the RNC is based on AAL2. The Iu UP is used in the transparent mode.

Figure 4: Structure of MSC/IWF

9.2.3.2 Structure of the MSC/IWF for A/Gb mode

The rate adaptation process is a reverse of that provided in the Terminal Adaptation function of the UE. The rate adaptation RA1 is based on the ITU-T Recommendation V.110 80 bit frame for TCH/F2.4, TCH/F4.8 and TCH/F9.6 and on A-TRAU frame for TCH/F14.4. 3GPP TS 44.021 and 3GPP TS 48.020, respectively, refer to the rate adaptation mechanisms to be provided. For multislot configurations refer to 3GPP TS 43.010.

NOTE: From MSC/IWF’s perspective a TCH/F28.8 EDGE configuration is identical to a multislot 2TCH/F14.4 configuration.

Figure 5: Rate adaptation schematic

In case of asynchronous bearer services and the facsimile teleservices in the transparent mode, the IWF shall disregard the value of bits E4, E5, E6 and E7 in the data transmission phase.

9.2.3.3 Mapping of signalling UE/MSC/IWF to modem interface requirements

This process also is a reverse of the function provided in the Terminal Adaptation function of the UE for the mapping of DTE/DCE signalling information to Dm channel and in band signalling information. See 3GPP TS 27.002 and 3GPP TS 27.003.

Figure 6: Signalling mapping schematic

Status bits SA, SB and X can be used to convey channel control information associated with the data bits in the data transfer state. Table 5 shows the mapping scheme between the V.24 circuit numbers corresponding to the V-series DCE functions and the status bits for the transparent mode. It also shows how the unused status bits should be handled. It is derived from the General Mapping scheme described in annex B. A binary 0 corresponds to the ON condition, a binary 1 to the OFF condition.

The transport of these status bits by the various channel codings is described in 3GPP TS 44.021 and 3GPP TS 48.020 for A/Gb mode. For Iu mode refer to Clause 11a.

NOTE Although the interface to the modem is described in terms of V.24 interchange circuit functions, this does not imply that such circuits need to be physically realised.

Table 5: Mapping scheme at the IWF for the transparent mode

Mapping direction: UE to IWF	Mapping direction: IWF to UE	Signal at IWF modem interface or condition within the IWF
always ON (note 1)		CT 105
	to status bit X	CT 106
	not mapped (note 5)	CT 107
not mapped (note 6)		CT 108
	to status bit SB	CT 109
always ON (note 2)		CT 133
from status bit SA (note 3)		ignored by IWF
from status bit SB (note 1)		ignored by IWF
from status bit X (note 4)		ignored by IWF
	to status bit SA (note 3)	always ON
NOTE 1: The SB bit towards the IWF, according to the General Mapping (annex B), could be used to carry CT 105 from the mobile DTE to the modem in the IWF. However, CT 105 should always be ON at the DTE interface in the data transfer state since only duplex operation is supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. Therefore, CT 105 shall always be set to ON at the IWF modem during the data transfer state. NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. NOTE 3: The SA bits in both directions are available only with certain channel codings. Therefore, for maximum compatibility, they should not be mapped. NOTE 4: The X bit towards the IWF is not mapped since there is no flow control in transparent mode. NOTE 5: CT 107 is not used by the IWF. NOTE 6: CT 108 is used in the call setup and answering processes.

In general it is not required for the modem in the MSC/IWF to support a "remote looping" request from a modem in the PSTN. In addition the invocation of a "remote looping" request from the mobile subscriber to a modem in the PSTN need not be supported (see also 3GPP TS 27.001). Specific test loops for mobile subscribers to contact may be provided at the network operators discretion.

9.2.3.4 Establishment of end‑to‑end terminal synchronizations

Prior to exposing the traffic channel of a PLMN connection to transmission of user data, the controlling entities of the connection shall assure of the availability of the traffic channel. This is done by a so called synchronizations process:

– starting on the indication of "physical connection established" resulting from the PLMN‑inherent outband signalling procedure. This indication is given:

– for MOC: on sending the CONNECT message;

– for MTC: on sending the CONNECT ACKNOWLEDGE message;

– for mobile initiated in‑call modification: on sending the MODIFY COMPLETE message (which is sent after reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and

– for network initiated in‑call modification: on reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message;

– ending by indicating the successful execution of this process to the controlling entity, which then takes care of the further use of the inband information (data, status).

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side (to the fixed network) of a connection. Both sides have to be treated individually related to the synchronizations process.

9.2.3.4.1 Terminating side (towards the UE)

9.2.3.4.1.1 Traffic channel types TCH/F4.8 and TCH/F9.6 for A/Gb mode

With respect to the terminating side the procedure is as follows:

‑ sending of synchronizations pattern 1/OFF (all data bits"1"/all status bits "OFF") to the UE using the RA1/RA2 rate adaptation function. In multislot transparent operation, the synchronisation pattern sent is 1/OFF with the exception of the bit positions S1, first X, S3, and S4 which contain the substream number and multiframe alignment pattern (see 3GPP TS 44.021);

– searching for detection of the synchronizations pattern from the UE within valid V.110 frames, and in multislot operation, also searching for the multiframe alignment pattern "0000 1001 0110 0111 1100 0110 1110 101" (see 3GPP TS 44.021) in bit position S4 and substream numbers in bit positions S1, first X, and S3. This implies that the E1, E2 and E3 bit of the V.110 frame shall be checked for the appropriate user rate in order to distinguish the synchronization pattern from the RAN idle data frame;

– timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the synchronizations pattern from the UE;

– when the frame alignment pattern and, in case of multislot operation, the multiframe alignment pattern have been recognized as a steady state, the MSC/IWF continues sending the synchronizations patterns to the UE until a timer T expires.

9.2.3.4.1.2 Traffic channel type TCH/F14.4 for A/Gb mode

With respect to the terminating side the procedure is as follows:

– sending A-TRAU frames with the data rate set in the bits C1-C4 (TS 48.020) and data bits set to one, sending the multiframe structure with the alignment pattern (bit M1) and with the status bits OFF (bit M2) and, in a multislot case, sending substream numbers (bit M2);

– searching for the detection of the multiframe alignment pattern "0000 1001 0110 0111 1100 0110 1110 101" (TS 44.021) in the bit M1 and, in a multislot case, searching for substream numbers in the bit M2. (Any 5 bit sequence in the multiframe alignment pattern is unique, i.e. the multiframe alignment can take place by recognition of five successive M1 bits);

– timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the synchronizations pattern from the UE;

– when the frame alignment pattern and the multiframe alignment pattern have been recognized as a steady state, the MSC/IWF continues sending the synchronizations patterns to the UE until a timer T expires.

9.2.3.4.1.3 User Plane for Iu mode

The IWF does not send any frame down link until the modem connection has been established and the modems have synchronised. Thereafter the IWF through connects, mapping data from the fixed network side onto frames that are sent toward the UE, and mapping data in the received frames to the fixed network side.

9.2.3.4.2 Transit side (towards the fixed network)

With respect to the transit side the procedure is as follows:

– at the start of timer T for each of the allocated traffic channel(s) of the call, circuit 108 to the selected modem associated with the connection will be switched from the "OFF" to "ON" condition, thus initiating the establishment of the modem connection. In the case of mobile originated calls, this initiates the auto calling sequence and after signalling, calling tone according to V.25 shall be generated by the modem in the IWF;

– the interchange circuits towards the modem (with the exception of CT108) are held in the OFF condition until timer T expires, when they are switched to ON;

– from this time, after the expiration of the timer T of every allocated traffic channel, the information on CT106 and CT109 from the IWF Modem are directly mapped to the SB and X bits toward the UE. For TCH/F14.4 the SB and X bits are mapped to the M2 multiframe bits according to 3GPP TS 44.021. The IWF is allowed to map CT104 to the data bits sent towards the UE and to map data bits received from the UE to CT103.

9.2.3.5 Network Independent Clocking (NIC)

The network independent clocking function applies only to A/Gb mode. It is invoked by the VMSC/IWF when the service requested (MO or MT) is 3,1 kHz Ex PLMN and synchronous. The above rule applies irrespective of the information contained in the 3GPP TS 24.008 setup message regarding NIC. For all other services NIC is not used.

Within the PLMN the coding of the values for bits associated with NIC is specified in 3GPP TS 44.021 and 3GPP TS 48.020. In the forward (transmitting) direction the multiframes shall be coded in exact accordance with that specified in those specifications. Bit E6 is set to "1" in alternate modified V.110 frames at the transmitter. However, the use of this bit at the receiver for monitoring frame synchronization, or any other purpose, is not specified and is left to the discretion of the implementer.

A "perfect linear block Code" is used in C1‑C5, whose error correction properties may be utilized in the receiver, in order to ensure reliable operation of NIC.

The NIC sending function shall recognize when the difference between the applicable clock speed of the PLMN and the interface speed generates a positive or negative whole bit requirement. When this positive or negative condition occurs, the NIC codewords specified in 3GPP TS 44.021 are used to transport this condition to the receiving NIC function. Transmission of the codeword shall clear the positive or negative condition related to that codeword at the sending function. The sending function shall not send more than one positive or negative compensation within a contiguous period of time corresponding to 10 000 user data bits minus the maximum NIC code framing delay (e.g. in the case of TCH/F2.4, TCH/F4.8 or TCH/F9.6, the number of user data bits necessary to make up an even number of V.110 frames between compensation). NIC compensation is coded in two V.110 frames in the case of TCH/F2.4, TCH/F4.8 or TCH/F9.6 and in one multiframe in the case of TCH/F14.4. This results from the requirements to compensate for maximum clock differences of ±100 parts per million. If the receiving function receives NIC compensations in the average more often than a contiguous period of time corresponding to 10000 user data bits, there is no guarantee that data will not be lost.

The NIC receiving function shall provide the capability to support the compensation requirements of the sending function. This compensation is managed by manipulating the clock speed of the interface, within the standard constraints of that interface.

Overall, the compensation functions shall be capable of managing clock tolerances of ±100 parts per million.

Action on loss of synchronization.

If five consecutive NIC multiframes in the V.110 frame have incorrect framing bit values in E7 or if the A-TRAU multiframe synchronisation is lost, the receiver shall stop applying clocking compensation to the received data. Resynchronization will be attempted and compensation will resume when synchronization is achieved.

9.2.4 Non‑transparent service support

The protocol stacks for non-transparent services are specified in 3GPP TS 43.010 and in Clause 11a.2. Both of the systems use the Radio Link Protocol (RLP) specified in 3GPP TS 24.022.

In Iu mode, the non-transparent services are based in the Iu User Plane protocol specified in 3GPP TS 25.415.

In A/Gb mode the corresponding necessary support concerning the rate adaptation scheme shall be utilized on the RAN‑MSC link as identified in 3GPP TS 48.020.

For the non-transparent service support the MSC/IWF will select the modem and speed based on the Compatibility information contained in either the call set‑up or call confirmed message, reference subclauses 9.2.1 and 9.2.2. Where the Modem Type indicated is autobauding type 1, the MSC/IWF may select any speed and modem type according to what it can negotiate with the remote modem. In this case User Rate and Fixed Network User Rate, if present, has no meaning.

9.2.4.1 Structure of the MSC/IWF for Iu mode

The transmission towards the RNC is based on AAL2. The Iu UP is used in the support mode. The RLP/L2R extends to the UE.

Figure 7: Structure of MSC/IWF

9.2.4.2 Structure of the MSC/IWF for A/Gb mode

The rate adaptation process will be the same as for the transparent case (see figure 5), except that a TCH/F43.2 channel coding is also supported. From MSC/IWF’s perspective a TCH/F43.2 EDGE configuration is identical to a multislot 3TCH/F14.4 configuration.

3GPP TS 43.010 identifies the protocol layer structures for the non‑transparent case, the physical layer to the PSTN is provided by means of a modem.

9.2.4.3 Re‑constitution of user data

3GPP TS 24.022 refers to the frame of user data in the radio link protocol. The layer 2 relay functions in the UE and the MSC/IWF (identified in 3GPP TS 43.010) contain the mechanism for packing and unpacking the user data into the L2R protocol data units.

9.2.4.4 Layer 2 relay functionality

Specific functionality is required of the L2R dependant upon the service which is being requested to be supported. The selection of the appropriate L2R function will be determined by the MSC/IWF on the basis of the bearer capability information signalled in either the call set‑up request, or call confirmation messages. The prime information element being transparent or non transparent service indication. In addition the particular L2R function will be selected on the basis of the users layer 2 indication ‑ type of protocol to be terminated and mode of flow control to be applied (see appropriate clauses of the 3GPP TS 27 series).

The specific interaction between the L2R function and the RLP function and the L2R frame structure will be the same as that detailed in the annex to the appropriate 3GPP TS 27 series.

9.2.4.5 In band signalling mapping flow control

This entails the L2R function providing the means of controlling and responding to flow control functions of the modem plus any synchronization requirements related to flow control. For asynchronous services a specific rule applies for flow control (see 3GPP TS 27.001).

The flow control function chosen will be dependent upon the information contained or not contained in the "user information layer 2" information element of the PLMN BC received from the UE.

If flow control is provided, irrespective of the type used the L2R function shall:

(a) provide immediate indication of flow control to the fixed network on receipt of flow control request from the UE; and/or

(b) provide immediate indication of flow control to the UE on receipt of flow control request from the fixed network i.e. in the next available L2R status octet to be transmitted.

Where in‑band (X‑on/X‑off) flow control is in use, then the X‑on/X‑off characters will not be passed across the radio interface.

For outband flow control refer to subclause 9.2.4.9.

If no flow control is provided, the involved end systems are responsible for performing in‑band flow control on their own by taking into account the buffer capacity of the MSC/IWF stated below.

9.2.4.5.1 Conditions requiring flow control towards the fixed network

The L2R function will initiate flow control ‑ if flow control is present ‑ in the following circumstances:

1) the transmit buffer reaches a preset threshold (BACK PRESSURE);

2) the L2R function receives an explicit "flow control active" indication.

No flow control initiation/removal will take place at the L2R function and loss of data may occur if no flow control is provided.

On removal of buffer congestion or receipt of L2R "flow control inactive" the flow control will be removed.

9.2.4.5.2 Conditions requiring flow control towards the UE

The L2R function will transmit to the UE an explicit "flow control active indication" if flow control is provided in the following circumstances:

1) if the receive buffer from the radio side reaches a preset threshold (BACK PRESSURE);

2) if a flow control indication is received from the fixed network customer. On receipt of this flow control indication, transmission of data from the receive buffers towards the fixed network terminal is halted.

On removal of the buffer congestion or fixed network flow control indication, the L2R function will send a "flow control inactive" indication towards the UE. In addition, for the fixed network indication, transmission of data from the receive buffers will be restarted.

If no flow control is provided at the L2R function, no flow control initiation/removal will take place by the MSC/IWF. Data might be lost without any indication by the MSC/IWF to the end systems involved.

9.2.4.6 Data buffers

9.2.4.6.1 Transmit buffers (towards UE)

Incoming data from the fixed network customer shall be buffered such that if the MSC/IWF is unable to transfer data over the radio path the data is not lost.

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer is half full flow control towards the fixed network shall be initiated if flow control is provided as per subclause 9.2.4.5.1.

9.2.4.6.2 Receive buffers (from UE)

Incoming data from the UE is buffered such that if the fixed network terminal is unable to accept the data then it is not lost.

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer becomes half full, the L2R function will send a "flow control active" indication towards the UE if flow control is provided at the L2R function, as per subclause 9.2.4.5.2.

9.2.4.7 Transportation of the Break condition

The "BREAK" condition shall be recognized by the L2R function and passed immediately to the UE. The L2R will generate a "BREAK" condition towards the fixed network on receipt of a break indication from the MS. The action of the "BREAK" on the L2R transmit and receive and the length of the "BREAK" signal to be generated towards the fixed network is described in 3GPP TS 27.002.

9.2.4.8 In band signalling mapping modem status information

Status information is carried between the modem in the IWF and the terminal adaptation function in the UE by the L2R function. The L2RCOP entity transfers interface status information between L2Rs via the status octets SA, SB and X in L2RCOP‑PDUs (3GPP TS 27.002). Table 6 shows the mapping scheme between the V.24 circuit numbers corresponding to the V-series DCE functions and the status bits for the non-transparent mode. It also shows how the unused status bits should be handled. It is derived from the general mapping scheme described in annex B. A binary 0 corresponds to the ON condition, a binary 1 to the OFF condition.

NOTE: Although the interface to the modem is described in terms of V.24 interchange circuit functions, this does not imply that such circuits need to be physically realised.

Table 6: Mapping scheme at the IWF for the non-transparent mode

Mapping direction: UE to IWF	Mapping direction: IWF to UE	Signal at IWF modem interface or condition within the IWF
always ON (note 1)		CT 105
	to status bit X (notes 4, 7)	CT 106 (note 7)
	not mapped (note 5)	CT 107
not mapped (note 6)		CT 108
	to status bit SB	CT 109
from status bit X (note 8)		CT 133 (notes 3, 8)
from status bit SA (note 2)		ignored by IWF
from status bit SB (note 1)		ignored by IWF
	to status bit SA (note 2)	always ON
NOTE 1: The SB bit towards the IWF, according to the General Mapping (annex B), could be used to carry CT 105 from the mobile DTE to the modem in the IWF. However, CT 105 should always be ON at the DTE interface in the data transfer state since only duplex operation is supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. Therefore, CT 105 shall always be set to ON at the IWF modem during the data transfer state. NOTE 2: The SA bits (both directions) are not mapped since CTs 107 and 108 are handled locally (notes 5 and 6). NOTE 3: The condition of CT 133 (or other flow control mechanism) may also be affected by the state of the L2R transmit buffer (towards the UE) in the IWF and the state of RLP (RR/RNR). NOTE 4: The condition of status bit X towards the UE may also be affected by the state of the L2R receive buffer (from the UE) in the IWF. NOTE 5: CT 107 is not used by the IWF. NOTE 6: CT 108 is used in the call setup and answering processes. NOTE 7: For inband flow control, CT 106 is not mapped and the status bit X towards the UE is controlled by the reception of XON and XOFF characters from the modem. NOTE 8: For inband flow control, changes in the condition of the status bit X from the UE result in the sending of XON or XOFF to the modem. CT 133 is always set to ON.

9.2.4.9 Support of out‑band flow control

Out‑band flow control in case of the asynchronous bearer service requires V.42 functionality in the modems in the MSC/IWF and the fixed network.

If this functionality is requested by the UE but cannot be provided by the MSC/IWF or the remote (fixed network) modem for any reason, the call shall be supported without V.42 functionality (fall back to the non‑error correction mode according to ITU-T Recommendation V.42).

This implies that no flow control initiation/removal (refer to subclause 9.2.4.5.1) is possible towards the fixed network. In this case the L2R transmit buffers in the IWF (towards the UE, refer to subclause 9.2.4.6.1) shall overbridge temporary throughput problems on the radio interface and the case where the UE initiates flow control. The IWF however shall release the connection if an overflow of these buffers occurs.

9.2.4.10 Establishment of end‑to‑end terminal synchronizations

– starting on the indication of "physical connection established" resulting from the PLMN‑inherent outband signalling procedure. This indication is given:

– for MOC: on sending the CONNECT message;

– for MTC: on sending the CONNECT ACKNOWLEDGE message;

– for mobile initiated in‑call modification: on sending the MODIFY COMPLETE message (which is sent after reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and

– for network initiated in‑call modification: on reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message;

– ending by indicating the successful execution of this process to the controlling entity, which then takes care of the further use of the in‑band information (data, status).

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side (to the fixed network) of a connection. Both sides shall be treated individually related to the synchronization process.

9.2.4.10.1 Terminating side (towards the UE)

With respect to the terminating side the procedure in A/Gb mode is as follows:

– reception of V.110 or A-TRAU frames on all allocated traffic channels for the call is required before the MSC/IWF shall reply with an RLP-UA frame to the MT’s RLP link establishment request (if the MSC/IWF initiates the RLP link establishment, reception of V.110 frames or A-TRAU on all allocated traffic channels for the call shall be detected first);

– waiting for the RLP link establishment by the MT (in addition the MSC/IWF may initiate the RLP establishment).

In Iu mode at the IWF, the synchronisation of modems on the transit network is performed after establishment of the physical connection. The RLP establishment may be initiated by the IWF, but is normally initiated by the UE. If the modems synchronise before the RLP has been established, the IWF stores the information received from the other modem in the L2R buffers.

9.2.4.10.2 Transit side (towards the fixed network)

Depending upon implementation ‑ CT108 will be turned ON to enable the autocalling/autoanswering function of the selected modem either when the RLP has been established or in parallel to RLP establishment. If CT 108 is turned ON in parallel to the RLP establishment, the modem connection may be established before the RLP is established. In this case, data received from the transit side during RLP establishment shall be stored within the L2R buffers until the RLP establishment at the terminating side has been finished. When the RLP has been established, the information from/to the RLP including status changes will be mapped by the L2R entity applicable to the particular bearer capability. After signalling, for MO calls, calling tone according to V.25 shall be generated by the modem in the IWF.

9.2.4.11 Data compression

When data compression is invoked within a non‑transparent bearer service, interworking to the fixed network is realized as follows.

The PLMN BC is used to indicate the interworking modem type and user rate. The modems shall try to negotiate data compression and flow control. If negotiation of data compression fails in the fixed network, the call continues with data compression between UE and IWF only.

9.2.4.12 Service level up and down grading

Service level up and down grading is only applicable for A/Gb mode and GERAN Iu mode. If the value of the RLP parameter "UP signalling" is negotiated to 1, the IWF shall send a suggestion to the UE to initiate an upgrading whenever the following condition holds:

The IWF:

1) is receiving user data from the fixed network side at a higher rate than the current AIUR; or

2) in symmetrical calls only, can send user data towards the fixed network side at a higher rate than the current AIUR.

When the above condition does not hold, the IWF sets the value of the UP bit continuously to 0. When the condition above does hold, the IWF indicates the number of traffic channels to upgrade by, by sending that number of 1s between two consecutive 0s in the UP bit sequence. This indication is not repeated since the FCS protects it. For instance, if the current number of traffic channels is two and an upgrading to four traffic channels is suggested, the UP bit sequence shall be ..01100… How the IWF detects the condition and additional details for setting and resetting of the UP bit, e.g., hysteresis levels, may depend on implementation.

NOTE: From MSC/IWF’s perspective a TCH/F28.8 or TCH/F43.2 EDGE configuration is identical to a multislot 2TCH/F14.4 or 3TCH/F14.4 configuration. In this case, rather than suggesting the number of channels to add, the IWF suggests a number of 14.4 substreams to add and therefore a factor of ½ or 1/3 shall be applied to the suggested increase when the assigned up link channel is TCH/F28.8 or TCH/F43.2 respectively.

9.2.5 DTE/DCE interface (Filtering)

The DTEs taken into account for the PLMN at the UE side conform to ITU-T’s DTE/DCE interface specifications, which assume basically an error‑free environment, i.e.:

– limited distance, point‑to‑point local interconnection of the interface circuits for data and status;

– steady state signalling.

The envisaged use of these DTE’s in the PLMN environment leads to the exposure of these "interconnections" ‑ which may, in the ISDN case, lead to the ISDN Rate Adaptation rather than to a Modem in the MSC/IWF ‑ to the PLMN Radio Channel. To assure proper operation even under these conditions appropriate measures shall be taken. In the "non‑transparent case" the RLP satisfies the requirement for both data and status lines. In the "transparent" case, the:

‑ data line aspects shall be dealt with end‑to‑end between the users; while

‑ status line aspects are of concern to the network which are dealt with in the following.

The use of the channel control information for the remote control of the DTE/DCE control interchange‑circuits between the UE and the MSC/IWF (the conveyance of which is supported by the rate adaptation scheme adopted for PLMN application) requires alignment to the particular transmission occurrences in the traffic channel to be taken into account within the PLMN. In principle this can be best achieved by:

– relying only on the PLMN outband signalling as far as connection control is concerned;

– eliminating the dependence upon the transmission of channel control information via the radio link.

Support for this strategy is given to a certain extent by the confinement of PLMN data connections to:

– full duplex operation (no turning round of the connection is required);

– switched service (demand access);

– mapping of connection‑control relevant conditions of the DTE/DCE control interchange‑circuits to/from outband PLMN signalling according to 3GPP TS 24.008 after successful traffic channel synchronization;

– flow control by a network entity supported only in non‑transparent mode;

– support of connections with the same user data rate only (no TA to TA end‑to‑end flow control in case of transparent mode).

The only DTE/DCE control interchange‑circuit conditions, which actually are not covered by the above confinements, are the indications of readiness for data transmission, i.e. CT106/109 in case of V.‑series interface and I‑circuit of X.‑series interface. As the effect of a condition change of the afore‑mentioned DTE/DCE interchange‑circuits depends on the:

– phase within the course of the connection;

– direction of change (ON‑OFF or OFF‑ON).

The required precaution to be applied (Filtering) shall be determined individually in view of:

– function deduced from the change;

– resilience of the connection needed;

– error condition possibly invoked due to a delay in performing the condition change of the control interchange circuit;

– potential loss of performance in connection usage.

The details of the filtering function are laid down in 3GPP TS 27‑ series. Filtering of channel control information is only relevant at the UE side in the transparent mode of operation.

9.3 Interworking Alternate Speech / Facsimile Group 3 Calls

9.3.1 General

The procedure for the alternate speech/facsimile group 3 services is invoked at UE‑MSC link during the call set‑up phase. This service is invoked by indication of repeated bearer capability information elements in the setup message and/or call confirmed message respectively (preceded by a repeat indicator "circular"), one indicating speech and the other indicating facsimile group 3. The facsimile service requested will be indicated by the information transfer capability "facsimile group 3", as for a normal single call. The bearer capability first indicated i.e. speech or facsimile group 3 determines the first selection required of the network by the subscriber. Depending on the type of service requested and direction of call establishment (M0/MT, see relevant clauses of 3GPP TS 27 series) low layer and high layer capabilities may also be included. The MSC/IWF will perform both compatibility checking and subscription checking on both sets of capabilities as for normal data calls. If either the subscription check or the compatibility check fails then the call will be rejected. The only exception to this is when TS61/TS62 negotiation takes place, see 3GPP TS 27.001.

The applicable rules for provision of supplementary services are laid down in 3GPP TS 22.004.

The "speech" phase of the call, when invoked is handled by the transcoder and will utilize normal telephony teleservice interworking requirements and mobile network capabilities. This includes any requirements for echo cancellers etc. as indicated in subclause 9.1. The "facsimile group 3" phase of the call, when invoked, shall utilize the appropriate data interworking capability (IWF including modem) and shall use the transparent mobile network capability in A/Gb mode or the non‑transparent mobile network capability in UTRAN Iu mode.

The network shall provide, for service and operational reasons, a rapid and reliable changeover of capability upon request from the mobile user. This changeover may involve the disabling, by‑passing or introduction of particular network functions (e.g. speech coder, modem etc.) and change of the channel configuration on the radio interface. This changeover is initiated on the receipt of the "MODIFY" message (see 3GPP TS 24.008) from the UE. The network itself will not initiate a changeover.

9.3.2 Mobile originated PSTN terminated calls

The call is set up in the normal manner (but with repeated bearer capability information elements as described in subclause 9.3.1 and handled by the MSC/IWF as indicated in the general clause.

9.3.3 PSTN originated mobile terminated calls

The call set up request for this particular service is performed in a similar manner to that indicated in subclause 9.2 for normal PSTN originated calls.

When multiple MSISDNs are used by the HLR ("Multi‑numbering scheme"), one PLMN BC‑IE with the ITC value set to "alternate speech/facsimile group 3, starting with speech" is passed to the VLR in the MAP operation "provide roaming number". The VLR stores this information against the MSRN.

When the call arrives at the visited MSC this information is retrieved from the VLR and sent to the UE in the setup message as defined in 3GPP TS 27.001.

If the ITC of the PLMN BC‑IE retrieved from the VLR has the value "alternate speech/facsimile group 3, starting with speech" this PLMN BC‑IE shall be mapped to two PLMN BC‑IEs (preceded by a repeat indicator "circular"), one representing speech, the other representing facsimile group 3. The order in which these two PLMN BC‑IEs are sent towards the UE, in the setup message, is a network option.

In order to allow auto answering mode for the facsimile phase (i.e. the call starts automatically with the facsimile phase), the UE can reflect back to MSC the dual Bearer Capability in the Call Confirm message with the BC elements interchanged to those in the original Call Set‑up message (i.e. facsimile element first or negotiate to facsimile only, see subclause 9.2.2 and 3GPP TS 27.001). In all other aspects it is handled as indicated for mobile originated.

NOTE: However, the PLMN specific parameters "connection element" and "radio channel requirements" of the retrieved PLMN BC‑IE may be modified, or added in line with the principles identified in subclause 9.2.2.

When a single MSISDN is allocated to the subscriber ("single numbering scheme"), the call is handled as described in case b) of subclause 9.2.2. In the "call confirmed" message, however, two PLMN BC‑IEs are preceded by a repeat indicator "circular", with the first PLMN BC‑IE indicating the initial phase of the connection.

9.3.4 BICC network architecture

In a BICC network architecture the following procedures apply for both mobile originated and mobile terminated alternate speech/facsimile group 3 calls:

The PLMN BC-IE value of ITC equal to “alternate speech/facsimile group 3, starting with speech” shall not be used in the H.248 signalling towards the MGW. Instead, the MGW terminations shall be configured for the speech portion of the call using the Acodec property.

To switch to fax mode, the PLMNBC property with ITC indicating "facsimile group 3" shall be applied on appropriate terminations, as detailed in Clause 11a.1.3, to insert the MGW IWF and configure the fax call. Usual procedures to setup a CSD call is followed as described TS 29.232 [82].

Similarly, to switch from fax to speech mode, the PLMNBC property shall be removed and the terminations shall be re-configured for the speech portion of the call using the Acodec property.

9.4 3G-H.324/M calls over 3,1kHz audio

In case of 3G-H.324/M calls over 3.1kHz audio, the IWF shall provide the V.34 modem modulation and the V.8 procedure with the indication of H.324 support in the call function category of the V.8 handshaking. H.223 and H.245 flow is not terminated in the modem function.

The performance of V.8bis by the modem function is FFS.

9.4.1 Mobile originated multimedia call

9.4.1.1 Call setup

The setup message sent by the UE contains either a multimedia BC-IE indicating a multimedia only call request (i.e. no fallback to speech allowed) or both a speech BC-IE and a 3.1kHz multimedia BC-IE to indicate the support of a fallback to speech (see 3GPP TS 27.001 and 3GPP TS 24.008).

The MSC shall not accept a requested service to which the user has no subscription. On the condition the user has the required subscriptions (i.e. to multimedia and/or speech) the following applies:

– in case of a multimedia only BC-IE the MSC may accept the setup as such or with modifications sent to the UE in the call proceeding message (see 3GPP TS 27.001);

– in case of both a speech BC-IE and a 3.1kHz multimedia BC-IE the MSC may either accept the possibility of a fallback to speech by responding with two BC-IEs or turn the call to a speech call by sending only a speech BC-IE in the call proceeding message or turn the call to a multimedia only call by sending only a multimedia BC-IE in the call proceeding message (See 3GPP TS 27.001).

The IWF V.34 modem shall initiate the ITU-T Recommendation V.8 handshaking and indicate the support of H.324/M in the call function category of the V.8 handshaking. If the called party’s modem does not indicate a H.324 support in its V.8 inband signalling response, the IWF may clear the call. If the called party responds with a modem answering tone but there is no V.8 response at all, the IWF shall clear the call.

If FNUR = 33.6 kbit/s is agreed on in the setup, the IWF shall configure its V.34 modem to operate in automode with an upper data rate limit of 33.6 kbit/s and a lower data rate limit of 28.8 kbit/s. If the modems handshake to 31.2 kbit/s or 28.8 kbit/s, the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate the new data rate to the UE. HDLC flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 (Annexes A, B and C) shall be used to adapt the 31.2 kbit/s or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between the UE and the IWF. In order to be able to use the correct stuffing pattern, the IWF shall detect the stuffing mode patterns exchanged between the multimedia terminals after the traffic channel setup (see ITU-T Recommendation H.324). The IWF may start the stuffing immediately after the detection of the used method. In downlink stuffing the IWF inserts stuffing patterns between the H.223 frames. In uplink stuffing the IWF removes stuffing patterns from between the H.223 frames received from the UE. If the UE responds with a MODIFY REJECT message, the MSC shall clear the call.

9.4.1.2 Fallback to speech after setup

If the MSC has accepted the possibility of a fallback to speech and the IWF modem does not recognize the answering tone of the called modem within the expiration of a timer started at the reception of the answer message, the MSC IWF shall initiate an In Call Modification procedure (see 3GPP TS 24.008) in order to fall back to a speech mode. As a result of the procedure the IWF resource shall be released and a speech channel shall be set up between the calling UE and the fixed network. If the fallback fails e.g. due to a failing In Call Modification procedure, the IWF shall clear the call.

A recommended minimum value for the timer is 3 seconds (see ITU-T Recommendation V.25).

9.4.2 Mobile terminated multimedia call

9.4.2.1 Call setup

If the user has a subscription to both the multimedia bearer service and the speech teleservice and if the network supports both services and the fallback functionality, the MSC shall send both a multimedia BC-IE and a speech BC-IE in the setup message to the user equipment. If the user has a subscription only to the multimedia bearer service the MSC shall send only a multimedia BC-IE.

In case of both a speech BC-IE and a 3,1 kHz multimedia BC-IE in the setup the user equipment may either accept the possibility of a fallback to speech by responding with two BC-IEs or turn the call to a speech call by sending only a speech BC-IE in the call confirmed message or to a multimedia only call (i.e. no fallback to speech allowed) by sending only a multimedia BC-IE in the call confirmed message. In case of a multimedia only BC-IE in the setup the UE may accept the setup as such or with modifications sent to the MSC in the call confirmed message.

If no service definition is available in the network, the MSC shall send no BC-IE(s) to the user equipment in the call setup. The MSC shall analyse the received BC-IE(s) and optionally perform a subscription check to the multimedia and/or speech service(s) requested by the user equipment in the call confirmed message and shall not accept a requested service rejected by the subscription check.

The IWF V.34 modem shall await the ITU-T Recommendation V.8 handshaking to be initiated by the calling party’s modem and shall recognize the support of H.324 in the call function category of the incoming V.8 handshaking. If the calling party’s modem does not indicate a H.324 support in its V.8 inband signalling, the IWF may clear the call. If the calling modem tries to handshake another than V.34 modem scheme, the IWF shall clear the call.

If FNUR = 33.6 kbit/s is agreed on in the setup, the IWF shall configure its V.34 modem to operate in automode with an upper data rate limit of 33.6 kbit/s and a lower data rate limit of 28.8 kbit/s. If the modems handshake to 31.2 or 28.8 kbit/s, the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate the new data rate to the UE. HDLC flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 (Annexes A, B and C) shall be used to adapt the 31.2 or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between the UE and the IWF. In order to be able to use the correct stuffing pattern, the IWF shall detect the stuffing mode patterns exchanged between the multimedia terminals after the traffic channel setup (see ITU-T Recommendation H.324). The IWF may start the stuffing immediately after the detection of the used method. In downlink stuffing the IWF inserts stuffing patterns between the H.223 frames. In uplink stuffing the IWF removes stuffing patterns from between the H.223 frames received from the UE. If the UE responds with a MODIFY REJECT message, the MSC shall clear the call.

9.4.2.2 Fallback to speech after setup

If the MSC supports a fallback to speech and the user has a subscription to the speech service and the user equipment accepts the possibility of a fallback to speech in the call confirmed message and the IWF modem does not recognize a call tone nor a V.8 Call Indication nor a V.8 Call Menu within the expiration of a timer started at the sending of the ANSam answer tone (i.e. the calling party is not a V.34 modem), the IWF shall initiate an In Call Modification procedure (see 3GPP TS 24.008) in order to fall back to a speech mode. As a result of the procedure the IWF resource shall be released and a speech channel shall be set up between the called UE and the fixed network. If the fallback fails e.g. due to a missing subscription to speech or a failing In Call Modification procedure, the IWF shall clear the call.

A recommended minimum timer value is 3 seconds (see ITU-T Recommendation V.8).

9.4.3 Seamless data rate change

If the modems change the data rate during an ongoing multimedia call (using the ITU-T Recommendation V.34 seamless data rate change mechanism), the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate the new data rate to the UE. HDLC flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 (Annexes A, B and C) shall be used to adapt the 31.2 or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between the UE and the IWF. The stuffing pattern found out during the traffic channel setup (see subclauses Call setup) is used. The IWF may start the stuffing immediately after the detection of the data rate change by the modems.