10 Interworking to the ISDN
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
The interworking to the ISDN is specified on the principle of the network supporting standardized associated signalling protocol as outlined in clause 6, i.e. DSS1 and ISUP. An ISDN not complying with this definition differs ‑ for the purpose of the present document ‑ in that it does not support the compatibility information to that degree necessary for deducing a PLMN Basic Service. These networks will find their reflection in the following where those implications are to be set out.
The calling address sent in a mobile originated call to the ISDN is always the basic MSISDN even if the ISDN user shall use a different MSISDN (multi numbering scheme, see 9.2.2 case a) for a mobile terminated call (call back) as only the basic MSISDN is available at the VLR (see 3GPP TS 29.002).
The scope of this clause is to describe the handling of the content of the Information Elements where "content" is understood to be the value of the parameter fields of the Information Elements, namely BC‑IE, HLC and LLC, after the length indicator. For the transport of these Information Elements within the PLMN refer to 3GPP TS 29.002.
The handling of multislot, 14.4kbit/s, EDGE and Iu Mode related parameters of the call control signalling and the applicability of single- or multislot configurations (refer to 3GPP TS 48.020 and 3GPP TS 44.021) is the same as for the PSTN interworking cases.
10.1 Speech Calls
Since at the interworking point the transcoder provides for A-law or µ-law (PCS-1900) PCM at 64 kbit/s, no particular interworking is required. It is anticipated that the ISDN Teleservice Telephony and ISDN Bearer Service speech, respectively would be used. Transmission aspects are covered in 3GPP TS 43.050. Any further requirements are a national matter.
10.2 Data Calls
In this case it is assumed that the ISDN bearer service 3,1 kHz audio shall only be interworked by means of a modem pool in the PLMN. If a network operator provides this facility, then the MSC/IWF operation will be similar to that described for interworking to the PSTN.
Where the bearer capability information indicates that the call is a circuit switched unrestricted digital call, then the MSC/IWF shall select the appropriate rate adapted ISDN and PLMN bearer services.
10.2.1 Network interworking mobile originated
Low layer compatibility checking of the mobile originated call is carried out by the MSC/IWF to determine the appropriate bearer service selection in the ISDN. This will entail the MSC/IWF in mapping appropriately the PLMN BC‑IE to the ISDN BC‑IE (bearer capability information element). If it is not possible for the MSC/IWF to provide a bearer service match, then the MSC/IWF shall fail the call and indicate the reason to the user.
The UE shall provide further compatibility information (LLC/HLC‑IEs) if required for defining end‑to‑end compatibility.
As well as compatibility checking, subscription checking should be performed.
The selection of the MSC/IWF will be by means of the bearer capability information within the call set up message. The mobile subscriber shall be able to select the unrestricted digital capability, which the MSC/IWF will map to the same capability in the ISDN call set up message. If an interworking point is encountered within the ISDN which does not support this service request, then either a call release message including an appropriate error cause or progress message is returned to the PLMN, indicating that the ISDN network is unable to support the service requested. In the case of a call release message the network shall release the call. In the case of progress message the network releases the call or forwards it (see 3GPP TS 24.008) to the mobile which will release the call.
10.2.2 Network interworking mobile terminated
10.2.2.1 General
This subclause describes the interworking of calls where the calling subscriber can communicate ISDN compatibility information with exhaustive contents for deducing a PLMN Basic Service to a PLMN (gateway MSC/interrogating node) i.e. by means of ISDN signalling.
The GMSC shall perform a mapping of the received Basic Service Information for the transport to the HLR, for details of this transport refer to 3GPP TS 29.002.
Compatibility checking of the low layers of the ISDN originated call is carried out by the MSC/IWF to determine the appropriate bearer service selection in the PLMN. This will entail the MSC/IWF in mapping appropriately the ISDN BC/LLC‑IE to the PLMN BC‑IE.
As well as compatibility checking, subscription checking should be performed. If either the subscription check or the compatibility check fails then the call will be rejected.
For ISDN originated calls it will not be possible to signal mobile specific requirements e.g. transparent/non transparent, full/half rate channel. Therefore the MSC/IWF shall select a default setting appropriate to the visited PLMN’s network capabilities. In general it will be beneficial, where a network supports both full and half rate channels and transparent/non transparent capabilities, to indicate so in the appropriate PLMN BC field of 3GPP TS 24.008. The mobile subscriber has the option to indicate in the call confirmation message a change to this default setting according to the rules specified in 3GPP TS 27.001. The appropriate MSC/IWF shall be selected on the basis of this requirement.
10.2.2.2 Functions in GMSC
At call Set‑up, the interrogating node passes in the "send routing information" to the HLR, the ISDN BC, LLC and HLC received in the initial address message. The coding of these parameters shall comply with Q.931 (05/98). For MT calls, and for backward compatibility purposes only, the mapping of the modem type according to ETS 300-102-1 (12/90) shall also be accepted, see note 12 of table 7B.
The information possibly signaled backwards from the VMSC to the GMSC contained in the access transport parameter of the Answer message (ANM) can be used to perform service related functions (e.g. accounting) at the GMSC.
10.2.2.3 Functions in HLR
According to the contents of the Compatibility Information, i.e. the ISDN BC, LLC and HLC received, the HLR applies one of the following:
1) No ISDN BC is received, or one from which a PLMN Basic Service cannot be deduced (i.e. with the information Transfer Capability field set to "3,1 kHz audio" but without any associated modem type[1]1 in the ISDN BC and LLC, or without HLC indication of group 3 facsimile). Two cases shall be considered:
a) The called MSISDN has a corresponding PLMN BC stored in the HLR (see 9.2.2.1); then the service attached to this number in the HLR tables is applicable and the corresponding PLMN BC is passed to the VLR in the "Provide Roaming Number" request. See figure 8;
b) The called MSISDN has no corresponding PLMN BC stored in the HLR (see 9.2.2.2). In this case no PLMN BC is passed to the VLR in the "Provide Roaming Number" request.
2) Compatibility Information is received from which a PLMN Basic Service can be deduced, i.e. the ITC field in the ISDN BC is "unrestricted digital" and the fields for the applicable user layer 1 protocol and user rate (except for the 64kbit/s case, see Note 22 Table 7B) are available (in either the ISDN BC or the LLC), or the ITC field is "3,1 kHz audio", and a modem type, user rate, etc. is indicated but the HLC does not indicate "facsimile group 3". The received ISDN BC (and possibly LLC plus HLC) is then considered applicable regardless of the kind of MSISDN received (PLMN BC associated or not) and either the equivalent PLMN BC or the original ISDN BC/LLC is sent to the VLR. In both cases the originally received HLC may also be sent to the VLR; see figure 9.
As an exception to this the BC stored in the HLR is regarded as valid if one of the following cases applies:
– If ITC = UDI/RDI and User Rate = 32 kbit/s /56 kbit/s and User information layer 1 protocol = V.110, I.460/X.30 and the stored BC indicates FTM, PIAFS or Multimedia.
– If ITC = 3,1 kHz audio and User Rate = 28.8 kbit/s and Modem Type = V.34 and the stored BC indicates Multimedia.
When the HLR interworks with a GSM phase 1 VPLMN (VLR/VMSC), then the HLR shall convert the ISDN BC to the equivalent PLMN BC, and forward it to the VLR. In this case the LLC cannot be forwarded.
3) Compatibility Information is received from which the PLMN Teleservice category Facsimile transmission can be deduced, i.e. the ITC field in the ISDN BC is "3,1kHz audio" and the HLC indicates "facsimile group 3" (see figure 9). The following two cases shall be considered:
a) The called MSISDN has a corresponding PLMN BC stored in the HLR (indicating either TS 61 or TS 62). In this case the service attached to the MSISDN in the HLR tables is applicable and the corresponding PLMN BC is passed to the VLR in the "Provide Roaming Number" request; see also subclause 10.3.1.3;
b) The called MSISDN has no corresponding PLMN BC stored in the HLR. In this case the HLR shall forward the appropriate PLMN BC to the VLR in line with the subscriber’s subscription to Teleservice TS 61 or TS 62.
For TS 61 the value of the PLMN BC parameter "Information Transfer Capability" shall be set to "alternate speech/facsimile group 3, starting with speech".
In both cases the HLC should be passed to the VLR in the "Provide Roaming Number" request.
Alternatively the HLR may forward the originally received ISDN/LLC/HLC, when interworking with a GSM or later phase 2 VLR
4) If the Compatibility Information received does not allow the HLR to deduce a PLMN Bearer Service, i.e. the ITC field in the ISDN BC is "unrestricted digital", but without the fields indicating the applicable user layer 1 protocol, user rate, etc. (in either the ISDN BC or the ISDN LLC), then the call is managed as for a UDI call according to subclause 9.2.2, i.e. either the "multi numbering" or "single numbering" scenario is applied depending on which capability is provided by the home PLMN/HLR.
5) Compatibility information is received, the ITC field in the ISDN BC is "speech" and this value differs from the ITC field in the PLMN BC stored in the HLR. Then the PLMN BC stored in the HLR is considered applicable and shall be sent to the VLR.
If the HLR supports the option to return the MAP "GSM Bearer Capability" to the GMSC in the MAP "Send Routing Information" response, it shall pass the PLMN-BC stored in the HLR if the latter is considered applicable as per the preceding rules. Otherwise no MAP "GSM Bearer Capability" shall be returned. This requirement shall apply irrespectively of whether the MAP "Send Routing Information" response contains a MAP "MSRN", "GMSC Camel Subscription Info", "Forwarding Data" or not. As an exception, to avoid transferring twice the MAP "GSM Bearer Capability" for a call involving two MAP "Send Routing Information" procedures to the HLR, the HLR should not include the MAP "GSM Bearer Capability" in the MAP "Send Routing Information" response if the MAP "Send Routing Information" request contains the MAP "Suppress T-CSI" IE.
10.2.2.4 Functions in VMSC
When the incoming call arrives, the VMSC attempts to derive a PLMN basic service from the information received in the IAM, and requests information from the VLR to handle the call. In general, the LLC and HLC are sent with the PLMN BC to the UE at call set‑up. In particular, however the following rules apply:
1) If the Initial Address Message (IAM) contains no ISDN BC and no PLMN or ISDN BC/LLC/HLC was retrieved from the VLR, the call is handled as in subclause 9.2.2.2.
2) If there is no ISDN BC in the IAM but a PLMN or ISDN BC/LLC/HLC was retrieved from the VLR, the PLMN or ISDN BC/LLC/HLC retrieved from the VLR applies.
3) If there is an ISDN BC in the IAM with the ITC field set to "3,1 kHz audio" but without any associated modem type or indication of facsimile group 3 in the HLC, the PLMN or ISDN BC/LLC/HLC retrieved from the VLR is considered as applicable when it exists. If no PLMN or ISDN BC is retrieved from the VLR, the call is handled as in subclause 9.2.2.2.
4) If there is an ISDN BC in the IAM with the ITC field set to "unrestricted digital information" and the fields for the applicable user layer 1 protocol and user rate (except for the 64kbit/s case; see note 22 to table 7B) are available (either in the ISDN BC or ISDN LLC), or if 3,1 kHz audio and a modem type is indicated, this ISDN BC is applicable regardless of what has been retrieved from the VLR. In this case the ISDN BC shall be mapped to an appropriate PLMN BC (refer to table 7B).
As an exception to this the BC retrieved from the VLR is sent to the UE if one of the following applies:
If ITC = UDI/RDI and User Rate = 32 kbit/s /56 kbit/s and User information layer 1 protocol = V.110, I.460/X.30 and the BC retrieved from the VLR indicates FTM, PIAFS or Multimedia.
If ITC = 3,1 kHz audio and User Rate = 28,8 kbit/s and Modem Type = V.34 and the BC retrieved from the VLR indicates Multimedia.
5) If there is an ISDN BC in the IAM with the ITC field set to "3,1kHz audio" and there is an HLC indicating "facsimile group 3", the PLMN BC retrieved from the VLR is applicable when it exists. If a PLMN BC with the parameter "information transfer capability" set to "alternate speech/facsimile group 3, starting with speech" (i.e. TS 61) is retrieved from the VLR, this shall be mapped to two PLMN BC‑IEs preceded by a repeat indicator, one representing speech, the other representing facsimile group 3.
For TS 61, the order in which the two PLMN BC‑IEs are sent towards the UE in the setup message is a network option.
6) If there is an ISDN BC in the IAM with the ITC field set to "unrestricted digital information" but without applicable "user layer 1 protocol" and "user rate", etc. fields, in either the ISDN BC no the ISDN LLC, then the PLMN or ISDN BC/LLC retrieved from the VLR is applicable, if available, otherwise subclause 9.2.2.2 applies.
7) If there is an ISDN BC in the IAM with the ITC field set to "Speech" and this value differs from the ITC field of the BC retrieved from the VLR for this call, then the BC/LLC/HLC retrieved from the VLR is considered applicable. If no PLMN or ISDN BC is retrieved from the VLR, the call is handled as in subclause 9.2.2.2.
In all cases where the VMSC retrieves a PLMN BC from the VLR, the VMSC may add or modify PLMN-specific parameters in the PLMN BC, as described in subclause 9.2.2, before sending the PLMN BCIE towards the UE.
In all cases when no PLMN or ISDN BC is retrieved from the VLR and no ISDN Compatibility information allowing deduction of a PLMN Bearer Service is available, then no PLMN BC is inserted by the VMSC and subclause 9.2.2.2 applies.
The mapping between PLMN and ISDN BCs is shown in table 7.
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, the network may accept or release the call (see 3GPP TS 27.001). For multislot, 14.4kbit/s, EDGE and Iu Mode operations, the UE may also propose to the network to modify the Fixed Network User Rate and Other Modem Type parameters (see 3GPP TS 27.001). In case a transparent service is used, the call shall be released. For a non-transparent service with flow control, the MSC/IWF shall use towards the fixed network the unmodified "fixed network user rate" and shall use the "wanted air interface user rate" or the modified "fixed network user rate" towards the user equipment.
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.
10.2.2.4A Functions in VLR
When the VLR receives from the VMSC a request for information to handle an incoming call, it performs two functions:
1) It determines the basic service which applies for the call, according to the following principles:
a) If the basic service received in the request from the VMSC was the same as the basic service indicated by the compatibility information received in the "Provide Roaming Number" request, the VLR applies that basic service.
b) If the basic service received in the request from the VMSC was Telephony but the compatibility information received in the "Provide Roaming Number" request indicated a basic service different from Telephony, the VLR applies the basic service derived from the compatibility information received in the "Provide Roaming Number" request.
c) If the basic service received in the request from the VMSC was Facsimile Group 3 and the compatibility information received in the "Provide Roaming Number" request indicated Alternate Speech and Facsimile Group 3, the VLR applies the basic service Alternate Speech and Facsimile Group 3.
d) If the basic service received in the request from the VMSC was Telephony and no compatibility information was received in the "Provide Roaming Number" request, the VLR applies the basic service Telephony.
e) If the basic service received in the request from the VMSC was Facsimile Group 3 but no compatibility information was received in the "Provide Roaming Number" request, the VLR checks the subscription information stored in its database, and applies the appropriate subscribed basic service (Facsimile Group 3 or Alternate Speech and Facsimile Group 3).
f) If the basic service received in the request from the VMSC was anything except Telephony or Facsimile Group 3, the VLR applies the basic service received in the request from the VMSC, regardless of any information received in the "Provide Roaming Number" request or stored subscription information.
g) If no basic service was received in the request from the VMSC but compatibility information was received in the "Provide Roaming Number" request, the VLR applies the basic service derived from the compatibility information received in the "Provide Roaming Number" request.
h) If no basic service was received in the request from the VMSC and no compatibility information was received in the "Provide Roaming Number" request, the VLR applies the basic service determined by the network operator, taking account of the subscribed basic services.
2) It returns compatibility information (PLMN BC or ISDN BC, and possibly ISDN HLC and ISDN LLC, according to the following principles:
a) If the request from the VMSC included a basic service Facsimile Group 3, the VLR checks the subscription information stored in its database, and returns the appropriate compatibility information according to the subscribed basic service:
i) A PLMN BC with the parameter "information transfer capability" set to "alternate speech/facsimile group 3, starting with speech" (i.e. TS 61) if the subscribed basic service is Alternate Speech and Facsimile Group 3;
ii) A PLMN BC with the parameter "information transfer capability" set to " facsimile group 3" (i.e. TS 62) if the subscribed basic service is Facsimile Group 3.
b) If the request from the VMSC did not include a basic service Facsimile Group 3 and compatibility information was received in the "Provide Roaming Number" request, the VLR processes the compatibility information received in the "Provide Roaming Number" request:
i) If the compatibility information received in the "Provide Roaming Number" request consisted of an ISDN BC/LLC/HLC the VLR maps this to an appropriate PLMN BC as shown in table 7B.
ii) If the compatibility information received in the "Provide Roaming Number" request consisted of a PLMN BC, possibly with an ISDN LLC/HLC, the VLR retains the PLMN BC
c) If the request from the VMSC did not include a basic service Facsimile Group 3 and no compatibility information was received in the "Provide Roaming Number" request, the VLR sends no compatibility information to the VMSC.
10.2.2.5 Call Flows
NOTE: (1) Some parameters of BCgk may be provided/modified according to the MSC’s capabilities/preferences. See subclause 9.2.2.
(2) In the "Call Confirm" message, the UE may modify some parameters of the PLMN BC. See subclause 9.2.2.
(3) The VMSC may map the PLMN BC (BC’’gk) into an ISDN BC (BC’’’gk) according to the rules defined in table 7A
(4) Abbreviations: see figure 2.
Figure 8: Call Flow for a mobile terminated, ISDN originated call
where compatibility information provided are not exhaustive for deducing a PLMN Bearer Service,
but Information Transfer Capability = 3,1 kHz audio, no modem type and no HLC IE indicating facsimile group 3 HLR stores PLMN BC against MSISDN number multi‑numbering scheme
NOTES: (1) BCij denotes ISDN BC*; BCgj is the corresponding PLMN BC.
(2) Assumes signalling capabilities permit the transfer of BC between IN and VMSC. If this is not the case, the VLR uses the stored BC/LLC/HLC.
(3) BC’ij denotes BCij as maybe modified by intervening networks.
(4) Some parameters of BCgk may be provided/modified according to the MSC’s capabilities/preferences. See subclause 9.2.2.
(5) In the "Call Confirm" message, the UE may modify some parameters of the BC. See subclause 9.2.2.
(6) For details on how the BC, HLC, and LLC are transported, refer to 3GPP TS 29.002.
* HLC and LLC refers to ISDN values.
(7) The VMSC may map the PLMN BC (BC’’gj,LLC,HLC) into an ISDN BC (BC’’’gj,LLC,HLC) according to the rules defined in table 7A
(8) Abbreviations: see figure 2.
Figure 9: Call Flow for a mobile terminated, ISDN originated call
where compatibility information provided are sufficient information to deduce a PLMN Bearer Service or Information Transfer Capability = 3,1 kHz audio with HLC IE indicating facsimile group 3
10.2.2.6 Mapping Functions
The following tables (7A + 7B) show that only the ISDN BC is used for mapping (exceptions are indicated).
NOTE: The ISDN/PLMN BC‑IE mapping shall be performed as specified in tables 7A and 7B. This shall be done to allow setup of a compatible end‑to‑end connection between two UEs or one UE and an ISDN terminal.
In the following tables 7A and 7B the comparison is drawn between parameters in the PLMN call set up request message and that of the ISDN call set up request message. In some cases no comparable values are available and these will be marked as such. In these cases reference will need to be made to the table of network interworking in 3GPP TS 29.007 to identify the appropriate choice. In some cases it is not necessary to support a particular option, and in this case those parameters will be annotated appropriately.
The PLMN parameters and values are as in 3GPP TS 24.008 in combination as in 3GPP TS 27.001. The ISDN parameters and values are as in Q.931 (05/98).
Table 7A: Comparable setting of parameters in PLMN and ISDN: Mobile Originated
|
Octet |
PLMN BC parameter value |
Octet |
ISDN BC parameter value |
|---|---|---|---|
|
1 |
Bearer Capability IEI |
1 |
Bearer Capability IEI |
|
2 |
Length of BC contents |
2 |
Length of BC contents |
|
3 |
Radio channel requirement |
No comparable field |
|
|
3 |
Coding Standard |
3 |
Coding Standard |
|
3 |
Transfer mode |
4 |
Transfer mode |
|
3 |
Information transfer capability |
3 |
Information transfer capability no comparable value |
|
5a |
Other ITC |
|
|
|
4 |
Compression (note 14) |
No comparable field |
|
|
4 |
Structure |
4a |
Structure (note 4) |
|
4 |
Duplex mode |
5d |
Duplex mode |
|
4 |
Configuration |
4a |
Configuration (note 4) |
|
4 |
Establishment |
4a |
Establishment (note 4) |
|
4 |
NIRR (note 12) |
No comparable field |
|
|
5 |
Rate adaptation CCITT X.31 flag stuffing (note 25) No comparable value (note 11) No comparable value (note 11) other rate adaptation (see octet 5a) |
5 |
User information layer 1 protocol |
|
5a |
Other rate adaptation |
No comparable value H.223 & H.245 (note 26) |
|
|
5 |
Signalling access protocol |
No comparable field |
|
|
6 |
Synchronous/asynchronous |
5a |
Synchronous/asynchronous |
|
6 |
User info. layer 1 protocol |
5 |
User info. layer 1 protocol |
|
6a |
Number of stop bits |
5c |
Number of stop bits |
|
6a |
Negotiation |
5a |
Negotiation |
|
6a |
Number of data bits 7 bits |
5c |
Number of data bits excluding parity if present |
|
6a |
User rate |
5a |
User rate |
|
6b |
Intermediate rate |
5b |
Intermediate rate (note 13) |
|
6b |
NIC on Tx |
5b |
NIC on Tx |
|
6b |
NIC on Rx |
5b |
NIC on Rx |
|
6b |
Parity information |
5c |
Parity information |
|
6c |
Connection element |
No comparable field |
|
|
6c |
Modem type |
5d |
Modem type |
|
7 |
User info. layer 2 protocol |
6 |
User info.layer 2 prot. (note 6) |
|
6d |
Fixed network user rate (note 15) FNUR not applicable (note 7) |
5a |
User rate no comparable value |
|
6e |
Maximum number of traffic channels 1 TCH |
No comparable field |
|
|
6f |
Wanted air interface user rate (note 23) air interface user rate not applicable (note 7) 57,6 kbit/s interpreted by the network as 38.4 kbit/s (note 7) |
No comparable field |
|
|
6d |
Other modem type (note 15) No other modem type |
5d #6..1 |
Modem type no comparable value |
|
6e |
Acceptable channel coding(s) TCH/F4.8 acceptable (note 19) |
No comparable field |
|
|
6f |
User initiated modification indicator (note 23) User initiated modification not |
No comparable field |
|
|
6g #7..5 |
Acceptable channel coding(s) (note 20) TCH/F28.8 acceptable TCH/F43.2 acceptable (note 22) |
No comparable field |
|
|
6g #4..3 |
Asymmetry preference indication (Note 23) no preference up link biased asymmetry preference down link biased asymmetry preference |
No comparable field |
General Notes
The application rules for coding the information elements ISDN‑BC/LLC/HLC as set out in ETR 018 and Q.931 (05/98) shall apply.
Other field values in the ISDN BC‑IE not supported in 3GPP TS 24.008 are:
Information transfer rate: In this case default 64 kbit/s is selected.
Flow control on transmission:
Flow control on reception: This shall be selected if outband flow control applies. Outband flow control is indicated by the absence of the UIL2P parameter for non‑transparent connections.
User information layer 3 protocol: Octet 7 shall not be sent unless specific application rules are given for particular cases (to be defined by PLMN). End‑to‑end significant User Information layer 3 protocol shall be sent by LLC.
Notes regarding particular entries in table 7A:
NOTE 1: If the PLMN BC "Information Transfer Capability" indicates "Facsimile group 3" and only a single PLMN BC is contained in the call set‑up request then this shall be mapped to an ISDN BC with:
– coding standard: CCITT;
– information transfer capability: 3,1 kHz audio;
– transfer mode: circuit;
– information transfer rate: 64 kbit/s;
– user layer 1 protocol: G711 A-law or µ-law (PCS-1900); and
– if an HLC is not present, the network will insert a "Facsimile group 2/3" HLC;
– if an HLC element is present, the network will pass it through unmodified.
If the PLMN BC "Information Transfer Capability" indicates "Facsimile group 3" and two PLMN BCs are contained in the call set‑up request, then the same ISDN BC as mentioned above is created. If the first PLMN BC indicates "facsimile group 3" an HLC "facsimile group 2/3" will be inserted by the network (if not received from the UE). However if the first PLMN BC indicates "speech", the network will not send a HLC, irrespective where a HLC was received from the UE or not.
NOTE 2: This value is present in combination with information transfer capability parameter value "3,1 kHz audio Ex PLMN" or "facsimile group 3" and will therefore be mapped to the value "Recommendation G.711 A‑law" or Recommendation G.711 µ-law" (PCS-1900) of the Q.931 (05/98) parameter user layer 1 protocol (see note 3).
NOTE 3: The value "Recommendation G.711 A-law" or "Recommendation G.711 µ-law" (PCS-1900) applies only when the Q.931 (05/98) parameter information transfer capability indicates "3,1 kHz audio" or "speech".
NOTE 4: When interworking with an ISDN according to ETS 300 102-1 octets 4a and 4b shall not be included because default values apply. In an ISDN according to Q.931 (05/98) these octets no more exist.
NOTE 5: In this case octet 5d shall not be included.
NOTE 6: Octet 6 shall not be sent unless specific application rules are given for a particular case (PLMN specified). End‑to‑end significant user information layer 2 protocol shall be sent by LLC.
NOTE 7: Not used for currently defined Bearer Services and Teleservices.
NOTE 8: These values will only be set if the "Information Transfer Capability" indicates "3,1 kHz audio", synchronous data transmission is used and octet 5b of the ISDN BC is present.
NOTE 9: (VOID).
NOTE 10: The PLMN BC‑IE parameter value "autobauding modem type 1" will be mapped to the ISDN BC‑IE parameter values "inband negotiation possible" and "user rate indicated by E‑bits specified in ITU-T Recommendation I.460 or may be negotiated inband" (octet 5a of ISDN BC‑IE). If data compression is used, high speed modems, like V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may also be used to support user rates less than 9.6 kbit/s towards the PSTN.
NOTE 11: The ITC value of the PLMN BC‑IE "speech", "3,1 kHz audio Ex PLMN" will indicate these requirements.
NOTE 12: For the use of NIRR see 3GPP TS 27.001.
NOTE 13: The value of the Intermediate Rate field of the ISDN Bearer Capability information element shall only depend on the values of the User Rate and the Information Transfer Capability in the same information element. The correspondence is:
Intermediate Rate = not used if User Rate > than 19.2 kbit/s.
Intermediate Rate = 32 kbit/s if User Rate = 19,2 kbit/s or 14.4 kbit/s.
Intermediate Rate = 16 kbit/s if User Rate = 9,6 kbit/s.
Intermediate Rate = 8 kbit/s otherwise.
For Audio calls the value of the Intermediate Rate may be set to "not used".
NOTE 14: If compression is supported by the MSC and "data compression allowed" is indicated, then the ISDN user rate for UDI calls shall be set as follows. If the parameter "FNUR" is present the ISDN user rate shall be set to this value. Otherwise the PLMN user rate shall be mapped to an equal or any higher ISDN user rate value (for V.110 the highest ISDN user rate shall be 19,2 kbit/s). The Intermediate Rate shall be set to an appropriate value.(see subclause 10.2.4.11).
For "3,1 kHz audio" the modem shall try to negotiate data compression and flow control (see subclause 9.2.4.11). For "autobauding type 1" high speed modems may be used (see note 10).
NOTE 15: User rate of the PLMN -BC is overridden by the fixed network user rate of the PLMN BC-IE if available. When the MT indicates „autobauding", „modem for undefined interface" or „none", the other modem type shall be set to „no other modem type"; any other value of the modem type is overridden by the other modem type value (see 3GPP TS 27.001). In Iu mode, if octet 6d is not present in the PLMN BC, the MSC shall reject the call. The support of user rates lower than 9.6 kbit/s in Iu mode are only possible in the scope of autobauding (see note 10).
NOTE 16: In the case Other rate adaptation = H.223 & H.245 the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: H.223 & H.245
In all the other cases the ISDN-BC will consist of the octets 1 to 4 only, coded:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
NOTE 17: V.120 interworking is selected.
If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. The PLMN -BC parameters negotiated with the UE shall be mapped to the LLC parameters. The LLC parameter Rate Adaptation will be set to "V.120".
When interworking with unrestricted 64 kbit/s networks the ISDN BC shall be coded according to note 16.
NOTE 18: When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an ITC = RDI.
When indirectly interworking with a restricted 64 kbit/s network the ISDN BC-IE shall be coded according to ETR 018, as shown below:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110/X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 56 kbit/s
If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. The PLMN -BC parameters negotiated with the UE shall be mapped to the LLC parameters according to the rules in this table. The LLC parameter Information Transfer Capability will be set to „restricted digital"
NOTE 19:If 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.
NOTE 20: Extension of the ‘Acceptable channel codings’ field in octet 6e if EDGE channel codings are supported.
NOTE 21: Void
NOTE 22: Only applicable for non-transparent services.
NOTE 23: This parameter shall be included if EDGE channel codings are indicated in ACC. In cases where this parameter would not otherwise be included, the value is set to ‘Air interface user rate not applicable’ or ‘User initiated modification not requested’ or ‘No preference’.
NOTE 24: This value was used by services defined for former PLMN releases and does not need to be supported.
NOTE 25: The case of FTM is identified by Rate adaptation in the PLMN BC-IE set to "CCITT X.31 flag stuffing", Connection element set to "non-transparent", and Synchronous/asynchronous set to "asynchronous". The MSC applies one of the following alternatives:
1) IF FNUR=64 kbit/s
– the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
– the LLC-IE shall be coded according to ETR 018 as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: (CCITT standardized rate adaptation
X.31 HDLC flag stuffing) (note: the
absence of octet 5 indicates that HDLC flag
stuffing applies)
User information layer 2 protocol: Recommendation X.25, link layer
User information layer 3 protocol: Recommendation X.25, packet layer
If user information layer 1 protocol is indicated by absence of octet 5 user information layer 2/3 protocol are also absent.
2) If FNUR=56 kbit/s and the MSC is directly connected to a
restricted 64 kbit/s network:
– the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: RDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
– the LLC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: RDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: (CCITT standardized rate adaptation
X.31 HDLC flag stuffing) (note: the
absence of octet 5 indicates that HDLC flag
stuffing applies)
User information layer 2 protocol: Recommendation X.25, link layer
User information layer 3 protocol: Recommendation X.25, packet layer
If user information layer 1 protocol is indicated by absence of octet 5 user information layer 2/3 protocol are also absent.
3) If FNUR=56 kbit/s and the MSC is indirectly interworking
with a restricted 64 kbit/s network:
– the ISDN BC-IE shall be coded according to ETR 018, as shown below:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110/X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 56 kbit/s
– If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. The PLMN -BC parameters negotiated with the MS shall be mapped to the LLC parameters according to the rules in this table. The LLC parameter Information Transfer Capability will be set to „restricted digital" and the LLC parameter User information layer 1 protocol will be set to “X.31 flag stuffing”.
NOTE 26: If FNUR=64 kbit/s the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: H.223 and H.245
If FNUR=56 kbit/s the ISDN BC-IE shall be coded as in note 18.
If FNUR=32 kbit/s the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110, I.460 & X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 32 kbit/s
If FNUR=28.8 kbit/s the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: 3,1 kHz Audio
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: G.711 A-law or µ-law
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
Modem type: V.34
User rate: 28.8 kbit/s
If FNUR=33.6 kbit/s the ISDN BC-IE shall be coded as follows:
Coding standard: ITU-T
Information Transfer capability: 3,1 kHz Audio
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: G.711 A-law or µ-law
NOTE 27: If FNUR=32 kbit/s the ISDN BC-IE shall be coded for PIAFS as follows:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110, I.460 and X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 32 kbit/s
If FNUR=64 kbit/s the ISDN BC-IE shall be coded for PIAFS as in note 16.
Table 7B: Comparable setting of parameters in PLMN and ISDN: Mobile Terminated
|
Octet |
ISDN BC parameter value |
Octet |
PLMN BC parameter value |
|---|---|---|---|
|
1 |
Bearer Capability IEI |
1 |
Bearer Capability IEI |
|
2 |
Length of BC contents |
2 |
Length of BC contents |
|
no comparable field |
3 |
Radio channel requirement |
|
|
3 |
Coding standard |
3 |
Coding standard |
|
3 |
Information transfer capability |
3 |
Information transfer capability |
|
(note 23) |
5a |
Other ITC |
|
|
4 |
Transfer mode |
3 |
Transfer mode |
|
4 |
Information transfer rate |
no comparable field |
|
|
No comparable field |
4 |
Compression (note 18) |
|
|
No comparable field (note 4) |
(4) 4 |
Structure (note 9) |
|
|
4a |
No comparable field (note 4) |
4 |
Configuration |
|
|
4 |
NIRR (note 17) |
|
|
4a |
No comparable field (note 4) |
4 |
Establishment |
|
4b |
|||
|
4b |
|||
|
5 |
User information layer 1 protocol |
5 |
Rate adaption |
|
No comparable value H.221 & H.242(note 28) |
5a |
Other rate adaptation |
|
|
no comparable field |
5 |
Signalling access protocol |
|
|
any of the above values |
6 |
User information layer 1 protocol |
|
|
5a |
Synchronous / asynchronous |
6 |
Synchronous/asynchronous |
|
5a |
Negotiation |
6a |
Negotiation |
|
5a |
User rate |
6a |
User rate (note 18 and 29) not supported |
|
5b |
Intermediate rate |
6b |
Intermediate rate (note 6) (note 18) |
|
5b |
NIC on Tx (note 14) |
6b |
NIC on Tx |
|
5b |
NIC on Rx (note 14) |
6b |
NIC on Rx |
|
5b |
Flow control on Tx (note 15) |
no comparable field |
|
|
5b |
Flow control on Rx (note 15) |
no comparable field |
|
|
5c |
Number of stop bits |
6a |
Number of stop bits |
|
5c |
Number of data bits |
6a |
Number of data bits |
|
5c |
Parity information |
6b |
Parity information |
|
no comparable field |
6c |
Connection element (note 1) |
|
|
5d |
Duplex mode |
4 |
Duplex mode |
|
5d |
Modem type |
6c |
Modem type (note 12) autobauding type 1 (note 16) |
|
5a |
User rate no comparable value |
6d |
Fixed network user rate (note 20) FNUR not applicable |
|
Modem type no comparable value (note 21) |
6d |
Other modem type No other modem type |
|
|
No comparable field |
6f |
User initiated modification indicator (note 1) (note 25) User initiated modification not |
|
|
6 #5..1 |
User information layer 2 protocol |
7 |
User information layer 2 protocol (note 8) |
|
7 |
User information layer 3 protocol |
not supported not supported |
General notes:
1) Other ISDN BC parameter values than those listed in the table, if indicated in the BC‑IE, will be rejected by clearing the call, exception see mapping note 4.
2) Only the PLMN BC parameter values listed in the table may be generated (comparable values) during a mobile‑terminated call by mapping the ISDN BC parameter values, exception see (10).
3) According to Q.931 (05/98) and 3GPP TS 24.008, respectively, the octets are counted from 1 to n onwards; the bit position in a particular octet is indicated by #x..y, with {x,y} = 1..8 (bit 1 is the least and bit 8 the most significant bit).
4) If octets 5 to 5d of the ISDN BC are absent but present in the LLC, the LLC octets should apply for the mapping as indicated above. For V.120 interworking (see note 24) these LLC octets shall apply.
5) If within the ISDN BC the parameters information transfer capability indicates "3,1 kHz audio" and user layer 1 protocol indicates "G711 A-law" or "G.711 µ-law" (PCS-1900) but no modem type is available and the HLC does not indicate "facsimile group 3", octets 5 to 5d of the LLC, if available, apply for the above mapping procedure.
6) The number of octets which shall be encoded for the PLMN BC‑IE must comply to encoding rules in 3GPP TS 24.008 and the combination of the different parameter values shall be in accordance to 3GPP TS 27.001.
Notes regarding particular entries in table 7B:
1) This PLMN parameter value is inserted according to user rate requirements and network capabilities / preferences.
2) This PLMN parameter value is inserted, if the information transfer capability in ISDN BC is "3,1kHz audio" and a comparable modem type is specified.
3) This PLMN parameter value is inserted, if the information transfer capability is "3,1 kHz audio" and the content of the HLC‑IE, if any, indicates "facsimile group 2/3", (for details refer to subclause 10.2.2.3 case 3 for HLR action and subclause 10.2.2.4 case 5 for VMSC action). Note that via MAP the value "alternate speech/facsimile group 3 ‑ starting with speech" shall be used, when TS 61 applies.
4) When interworking with an ISDN according to ETS 300 102-1, octets 4a and 4b may be present. The values are ignored and PLMN values are set according to notes 5 and 9.
5) This PLMN parameter value is inserted if the comparable ISDN parameter value is missing.
6) The value of the Intermediate Rate field of the PLMN Bearer Capability information element shall only depend on the value of the user rate in the same information element. If the connection element is "transparent", the value is 16 kbit/s, if the user rate is 9.6 or 12 kbit/s, and 8 kbit/s otherwise. For any other connection element setting the value is 16 kbit/s.
7) This PLMN BC parameter value is inserted, if the PLMN BC parameter "Information Transfer Capability" indicates "Unrestricted digital information", "facsimile group 3" or "alternate speech/facsimile group 3, starting with speech".
8) Where the network indicates "asynchronous" and connection elements "non‑transparent", "both, transparent preferred" or "both, non‑transparent preferred" , then the PLMN BC should be forwarded without parameter user information layer 2 protocol, see also (10).
9) The PLMN parameter value shall be set to "unstructured" where the network indicates connection element "transparent". Where the network indicates connection elements "non transparent" "both, transparent preferred" or "both, non transparent preferred" the value of the parameter structure shall be set to "SDU Integrity".
10) Mapping of parameter values of this octet to PLMN BC parameters and values are subject to specific application rules, i.e. unless otherwise explicitly stated in an appropriate TS mapping to PLMN BC parameters shall not take place.
11) This value shall be used when the value of the PLMN BC parameter "Information Transfer Capability" indicates the value "3,1 kHz audio ex PLMN", "facsimile group 3" or "alternate speech/facsimile group 3, starting with speech" which is reserved for MAP operations.
12) The modem encoding of both Q.931 (05/98) and ETS 300 102‑1 version 1 shall be accepted and mapped according to 3GPP TS 24.008.
13) Value not used for currently defined bearer services and Teleservices.
14) NIC is only supported in A/Gb mode for "3,1 kHz Ex PLMN audio" interworking with synchronous data transmission.
15) Because the required flow control mechanism can not be indicated to the UE (refer to 3GPP TS 27.001), the network shall check if the flow control mechanism selected by the UE and indicated in the CALL CONFIRMED message suits to the requirements requested by the ISDN terminal adaptor. If there is a mismatch the call shall be released in the IWF.
Because an asymmetric flow control mechanism (with respect to transmitting and receiving side) is not supported in the PLMN, the different values of the ISDN BC‑IE parameters "flow control on Tx" and "flow control on Rx" shall be interpreted in the following way:
‑ "Flow control on Rx" set to "accepted" matches with "outband flow control", irrespective of the value of the parameter "flow control on Tx".
‑ "Flow control on Rx" set to "not accepted" and "flow control on Tx" set to "not required" matches with "inband flow control" and "no flow control".
‑ where "Flow control on Rx" is set to "not accepted" and "flow control on Tx" to "required" the call shall be released by the IWF.
16) If 3,1 kHz audio interworking "inband negotiation possible" is indicated and the parameter user rate is set to "rate is indicated by E bits specified in Recommendation I.460 or may be negotiated inband" the user rate in the PLMN BC‑IE shall be set according to a network preferred value. If ISDN‑BC parameter modem type is present, its value shall be ignored. The PLMN BC parameter modem type shall be set according to the user rate for connection element "transparent" and to "autobauding type 1" for connection element "non transparent", "both, transparent preferred" or "both, non transparent preferred". If data compression is used, high speed modems, like V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may also be used to support user rates less than 9.6 kbit/s towards the PSTN.
For unrestricted digital interworking the call shall be rejected if these values are indicated.
If the PLMN-BC parameter modem type indicates "autobauding type 1" or "none", then the PLMN-BC parameter other modem type shall be set to "no other modem type".
17) For the use of NIRR see 3GPP TS 27.001. The VMSC shall set this parameter dependent upon its capabilities and preferences.
18) If compression is supported by the MSC, the value "data compression possible" may be set. Depending on the capabilities of the MSC, the user rate value and the intermediate rate value is set to an appropriate value.
19) Only applicable if the parameter ISDN-BC ITC indicates "3,1 kHz audio" and for "UDI" calls if User Rate > "19,2 kbit/s".
20) The user rate of the PLMN BC is set to the value for the fall-back bearer service. If the user equipment does not support the fixed network user rate (i.e. the call confirmation message does not contain the fixed network user rate parameter), the network may release the call for a transparent connection element.
21) The modem type parameter of the PLMN -BC is taken into account, only.
22) If no LLC is received and the ISDN-BC received consists of octets 1 to 4 only, coded:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64kbit/s
the following PLMN -BC parameters, shall be set to:
fixed network user rate: 64 kbit/s
connection element: transparent
bothNT or bothT (If IWF supports PIAFS)
The other parameters of the PLMN -BC shall be set to values indicating a fall-back service.
If an LLC indicating UIL1P=X.31 (either explicitly or implicitly by octet 5 missing) is received and the ISDN-BC received consists of 1 to 4 only, coded:
Coding standard: ITU-T
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64kbit/s
the following PLMN BC parameters, shall be set to:
fixed network user rate: 64 kbit/s
connection element: non-transparent
Synchronous/Asynchronous asynchronous
all other parameters shall be set according to 3GPP TS 27.001 to indicate FTM.
If an LLC indicating UIL1P=X.31 (either explicitly or implicitly by octet 5 missing) is received and the ISDN-BC received consists of 1 to 4 only, coded:
Coding standard: ITU-T
Information Transfer capability: RDI
Transfer mode: circuit
Information transfer rate: 64kbit/s
the following PLMN BC parameters, shall be set to:
fixed network user rate: 56 kbit/s
connection element: non-transparent
Synchronous/Asynchronous asynchronous
all other parameters shall be set according to 3GPP TS 27.001 to indicate FTM.
23) When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an ITC = RDI.
An ISDN BC-IE, as specified in ETR 018 and shown below, shall be taken to indicate that interworking with an indirectly connected restricted 64 kbit/s network is required:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110/X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 56 kbit/s
In this case the PLMN BC parameter Information Transfer Capability is set to „Other ITC" and Other ITC parameter is set to „restricted digital". If ISDN LLC exists, all the corresponding fields in the PLMN BC shall be derived from the ISDN LLC. Otherwise, the corresponding fields in the PLMN BC shall be derived from the ISDN BC. In the above both case, Connection element is set as follows.
Connection element: transparent
bothNT or bothT (If IWF supports FTM) and LLC does not indicate
User information layer 1 protocol = “X.31 flag stuffing”)
non-transparent (if IWF supports FTM and LLC indicates
User information layer 1 protocol = “X.31 flag stuffing”)
24) V.120 interworking is required if the ISDN LLC parameter User Information Layer 1 Protocol is set to „V.120". In this case the PLMN BC parameter Rate Adaptation is set to „Other rate adaptation" and Other Rate Adaptation parameter is set to „V.120". All the corresponding fields in the PLMN BC shall be derived from the ISDN LLC.
25) This parameter is only included for non-transparent multislot connections.
26) This value was used by services defined for former PLMN releases and does not need to be supported.
27) Following BC parameters in SETUP message shall be set to:
Fixed network user rate 32 kbit/s
Connection element transparent (for multimedia)
bothNT or bothT (If IWF supports PIAFS, UTRAN Iu mode only)
28) UIL1P is set to "H.221 & H.242" or "H.223 & H.245" by H.324/I. If UIL1P is set to "H.221 and H.242", this should be mapped to "H.223 & H.245".
29) In Iu mode, if the User Rate of the ISDN BC is less than 9,6 kbit/s and the Connection Element is mapped to "NT", then FNUR is fixed to 9,6 kbit/s.
10.2.2.7 Creation of Backup Bearer Capability Information Element
If the VMSC is not able to send a PLMN BC to the MS/UE for mobile terminated calls, it may include all available information in the Backup BC information element (Backup BC IE) of the call set-up message.
In the following table 7C the comparison is drawn between parameters in the ISDN call set up request message and that of the PLMN call set up request message. In some cases no comparable values are available and these will be marked as such. In some cases it is not necessary to support a particular option, and in this case those parameters will be annotated appropriately.
The PLMN parameters and values shall as in 3GPP TS 24.008 in combination as in 3GPP TS 27.001. The ISDN parameters and values are as in Q.931 (05/98).
Table 7C: Setting of parameters in Backup BC IE
|
Octet |
ISDN BC / LLC parameter value |
Octet |
BACKUP BC parameter value |
|---|---|---|---|
|
1 |
Bearer Capability IEI |
1 |
Bearer Capability IEI |
|
2 |
Length of BC contents |
2 |
Length of BC contents |
|
no comparable field |
3 |
Radio channel requirement |
|
|
3 |
Coding standard |
3 |
Coding standard |
|
3 |
Information transfer capability |
3 |
Information transfer capability |
|
(note 23) |
5a |
Other ITC |
|
|
4 |
Transfer mode |
3 |
Transfer mode |
|
no comparable field |
4 |
Compression (note 18) |
|
|
4a #7..5 |
no comparable field (note 4) |
(4) 4 |
Structure (note 9) |
|
4a |
no comparable field (note 4) |
4 |
Configuration |
|
no comparable field |
4 |
NIRR (note 17) |
|
|
4a |
no comparable field (note 4) |
4 |
Establishment |
|
5 |
User information layer 1 protocol |
5 |
Rate adaption |
|
H.221 & H.242 (note 28) |
5a |
Other rate adaptation |
|
|
no comparable field |
5 |
Signalling access protocol |
|
|
any of the above values |
6 |
User information layer 1 protocol |
|
|
5a |
Synchronous / asynchronous (note 30) |
6 |
Synchronous/asynchronous |
|
5a |
Negotiation |
6a |
Negotiation |
|
5a |
User rate no comparable value |
6a |
User rate (note 29) not supported unknown |
|
5b |
Intermediate rate |
6b |
Intermediate rate (note 6) |
|
5b |
NIC on Tx (note 14) |
6b |
NIC on Tx |
|
5b |
NIC on Rx (note 14) |
6b |
NIC on Rx |
|
5c |
Number of stop bits |
6a |
Number of stop bits |
|
5c |
Number of data bits |
6a |
Number of data bits |
|
5c |
Parity information |
6b |
Parity information |
|
no comparable field |
6c |
Connection element (note 1) |
|
|
5d |
Duplex mode |
4 |
Duplex mode |
|
5d |
Modem type |
6c |
Modem type (note 12) autobauding type 1 (note 16) |
|
5a |
User rate no comparable value |
6d |
Fixed network user rate (note 20) FNUR not applicable / unknown |
|
Modem type no comparable value (note 21) |
6d |
Other modem type No other modem type |
|
|
no comparable field |
6e |
Acceptable channel codings spare |
|
|
no comparable field |
6e |
Maximum number of traffic channels spare |
|
|
No comparable field |
6f |
User initiated modification indicator (note 1) (note 25) User initiated modification not |
|
|
no comparable field |
6f |
Wanted air interface user rate spare |
|
|
no comparable field |
6g |
Acceptable channel codings extended spare |
|
|
no comparable field |
6g |
Asymmetry indications spare |
|
|
6 #5..1 |
User information layer 2 protocol no comparable value |
7 |
User information layer 2 protocol (note 8) unknown |
General notes:
1) Only the PLMN BC parameter values listed in the table may be generated (comparable values) during a mobile‑terminated call by mapping the ISDN BC parameter values, exception see (10).
2) According to Q.931 (05/98) and 3GPP TS 24.008, respectively, the octets are counted from 1 to n onwards; the bit position in a particular octet is indicated by #x..y, with {x,y} = 1..8 (bit 1 is the least and bit 8 the most significant bit).
3) If octets of the ISDN BC are absent but present in the LLC, the LLC octets should apply for the mapping.
4) The number of octets which shall be encoded for the Backup BC‑IE must comply to encoding rules in 3GPP TS 24.008 and the combination of the different parameter values shall be in accordance to 3GPP TS 27.001 with the modification that some parameters may be absent, if a whole octet is absent, and some parameters may get values defined for the Backup BC only. However, parameter values that are valid for both the PLMN BC and the Backup BC shall not be in contradiction to 3GPP TS 27.001.
Notes regarding particular entries in table 7C:
1) This PLMN parameter value is inserted according to user rate requirements and network capabilities / preferences.
2) This PLMN parameter value is inserted, if the information transfer capability in ISDN BC is "3,1kHz audio" and a comparable modem type is specified.
3) This PLMN parameter value is inserted, if the information transfer capability is "3,1 kHz audio" and the content of the HLC‑IE, if any, indicates "facsimile group 2/3", (for details refer to subclause 10.2.2.3 case 3 for HLR action and subclause 10.2.2.4 case 5 for VMSC action).
4) When interworking with an ISDN according to ETS 300 102-1, octets 4a and 4b may be present. The values are ignored and PLMN values are set according to notes 5 and 9.
5) This PLMN parameter value is inserted if the comparable ISDN parameter value is missing.
6) The value of the Intermediate Rate field of the PLMN Bearer Capability information element shall only depend on the value of the user rate in the same information element. If the connection element is "transparent", the value is 16 kbit/s, if the user rate is 9.6 or 12 kbit/s, and 8 kbit/s otherwise. For any other connection element setting the value is 16 kbit/s. If the user rate value is "unknown" any value can be used, it has to be ignored by the UE
7) This PLMN BC parameter value is inserted, if the PLMN BC parameter "Information Transfer Capability" indicates "Unrestricted digital information "or "facsimile group 3".
8) Where the network indicates "asynchronous" and connection elements "non‑transparent", "both, transparent preferred" or "both, non‑transparent preferred" , then the PLMN BC should be forwarded without parameter user information layer 2 protocol, see also (10).
9) The PLMN parameter value shall be set to "unstructured" where the network indicates connection element "transparent". Where the network indicates connection elements "non transparent" "both, transparent preferred" or "both, non transparent preferred" the value of the parameter structure shall be set to "SDU Integrity".
10) Mapping of parameter values of this octet to PLMN BC parameters and values are subject to specific application rules, i.e. unless otherwise explicitly stated in an appropriate TS mapping to PLMN BC parameters shall not take place.
11) This value shall be used when the value of the PLMN BC parameter "Information Transfer Capability" indicates the value "3,1 kHz audio ex PLMN" or "facsimile group 3".
12) The modem encoding of both Q.931 (05/98) and ETS 300 102‑1 version 1 shall be accepted and mapped according to 3GPP TS 24.008.
13) Value not used for currently defined bearer services and Teleservices.
14) NIC is only supported in A/Gb mode for "3,1 kHz Ex PLMN audio" interworking with synchronous data transmission.
15) void.
16) If 3,1 kHz audio interworking "inband negotiation possible" is indicated and the parameter user rate is set to "rate is indicated by E bits specified in Recommendation I.460 or may be negotiated inband" the user rate in the PLMN BC‑IE shall be set according to a network preferred value. If ISDN‑BC parameter modem type is present, its value shall be ignored. The PLMN‑BC parameter modem type shall be set according to the user rate for connection element "transparent" and to "autobauding type 1" for connection element "non transparent", "both, transparent preferred" or "both, non transparent preferred". If data compression is used, high speed modems, like V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may also be used to support user rates less than 9.6 kbit/s towards the PSTN.
For unrestricted digital interworking the call shall be rejected if these values are indicated.
If the PLMN-BC parameter modem type indicates "autobauding type 1" or "none", then the PLMN-BC parameter other modem type shall be set to "no other modem type".
17) An indication of NIRR is not possible in the Backup BC because it has to be negotiated by parameter values in the PLMN BC.
18) An indication of compression is not possible in the Backup BC because it has to be negotiated by parameter values in the PLMN BC.
19) void.
20) The user rate of the PLMN BC is set to the value for the fall-back bearer service. If the user equipment does not support the fixed network user rate (i.e. the call confirmation message does not contain the fixed network user rate parameter), the network may release the call for a transparent connection element.
21) The modem type parameter of the PLMN -BC is taken into account, only.
22) If no LLC is received and the ISDN-BC received consists of octets 1 to 4 only, coded:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64kbit/s
the following PLMN -BC parameters, shall be set to:
fixed network user rate: 64 kbit/s
connection element: transparent
bothNT or bothT (If IWF supports FTM)
The other parameters of the PLMN -BC shall be set to values indicating a fall-back service.
23) When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an ITC = RDI.
An ISDN BC-IE, as specified in ETR 018 and shown below, shall be taken to indicate that interworking with an indirectly connected restricted 64 kbit/s network is required:
Coding standard: CCITT
Information Transfer capability: UDI
Transfer mode: circuit
Information transfer rate: 64 kbit/s
User information layer 1 protocol: V.110/X.30
Synchronous/Asynchronous: synchronous
Negotiation: In-band negotiation not possible
User rate: 56 kbit/s
In this case the PLMN BC parameter Information Transfer Capability is set to „Other ITC" and Other ITC parameter is set to „restricted digital". If ISDN LLC exists, all the corresponding fields in the PLMN BC shall be derived from the ISDN LLC. Otherwise, the corresponding fields in the PLMN BC shall be derived from the ISDN BC. In the above both case, Connection element is set as follows.
Connection element: transparent
bothNT or bothT (If IWF supports FTM)
24) Void.
25) This parameter is only included for non-transparent multislot connections.
26) This value was used by services defined for former PLMN releases and does not need to be supported.
27) Following BC parameters in SETUP message shall be set to:
Fixed network user rate 32 kbit/s
Connection element transparent (for multimedia)
28) UIL1P is set to "H.221 & H.242" or "H.223 & H.245" by H.324/I. If UIL1P is set to "H.221 and H.242", this should be mapped to "H.223 & H.245".
29) In Iu mode, if the User Rate of the ISDN BC is less than 9,6 kbit/s and the Connection Element is mapped to "NT", then FNUR is fixed to 9,6 kbit/s.
30) If this parameter value is missing, the Backup BC shall not contain parameter octets 6 and higher.
10.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 identifies 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 ‑ MSC/IWF will utilize the same rate adaptation scheme as that indicated in 3GPP TS 48.020, i.e. adapted to 64 kbit/s.
10.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 10: Structure of the MSC/IWF (transparent)
10.2.3.2 Structure of the MSC/IWF for A/Gb mode
When interworking to the unrestricted digital bearer service rate adaptation according to ITU-T Recommendation V.110 will be necessary within the MSC/IWF. For multislot, TCH/F14.4 or EDGE operations MSC/IWF shall adapt the data stream as defined in 3GPP TS 44.021 and 3GPP TS 48.020.
NOTE: From the perspective of MSC/IWF, a TCH/F28.8 EDGE configuration is identical to a multislot 2TCH/F14.4 configuration.
When interworking to the 3,1 kHz audio service, then the same process as for the PSTN case is necessary (section 9.2.3.2).
Figure 11: Structure of the MSC/IWF (transparent)
10.2.3.3 Mapping of signalling UE/MSC/IWF to modem or ISDN (V.110) TA-function interface requirements
For the 3,1 kHz audio interworking case see subclause 9.2.3.3.
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 8 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 48.020 for A/Gb mode. For Iu mode refer to 3GPP Clause 11a.
NOTE Although the interface to the ISDN TA function is described in terms of V.24 interchange circuit functions, this does not imply that such circuits need to be physically realised.
Table 8: Mapping scheme at the IWF for the transparent mode
|
Mapping |
Mapping |
Signal at IWF ISDN TA 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 ISDN TA function 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 ISDN TA function 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. |
||
10.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 shall be treated individually related to the synchronizations process.
10.2.3.4.1 Terminating side (towards the UE)
10.2.3.4.1.1 Traffic channel types TCH/F4.8 and TCH/F9.6 in 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.
10.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.
10.2.3.4.1.3 User Plane for Iu mode
The procedures are the same as for the modem case, but, depending on implementation, the IWF may through connect before the fixed network leg has been synchronised.
10.2.3.4.2 Transit side (towards the fixed network).
In case of interworking to the ISDN "3,1 kHz audio" bearer service the synchronization process is as for the PSTN interworking case (see subclause 9.2.3.4.2).
In case of V.110 interworking to the ISDN unrestricted digital bearer service the following synchronization process shall be performed.
The interchange circuits towards the V.110 ISDN TA function 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 V.110 ISDN TA function are directly mapped to the X and SB bits, respectively, towards the UE. For TCH/F14.4 the X and SB bits are mapped to the M2 multiframe bits according to 3GPP TS 44.021. Circuit 108 to the selected V.110 ISDN TA function associated with the connection will be switched from the "OFF" to "ON" condition, thus initiating the synchronization process on the fixed network according to ITU-T Recommendation V.110. The IWF is allowed to map CT 104 to the data bits sent towards the UE and to map data bits received from the UE to CT 103.
10.2.3.5 Network independent Clocking (NIC)
Due to the incompatibility between the ISDN and the PLMN requirements for NIC interworking is not provided between these two formats. As such no NIC function is required in providing interworking to the ISDN. In this case, the IWF shall disregard the value of bits E4, E5, E6 and E7 in the data transmission phase.
10.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.
10.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 12: Structure of the MSC/IWF (non‑transparent)
10.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. , 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 3TCH/F14.4 configuration.
3GPP TS 43.010 identifies the protocol layer structure for the non-transparent case, the MSC/IWF provides the inverse of the action in the UE terminal adaptation function. For a multislot configuration refer to 3GPP TS 43.010.
The V.110, V.120 and PIAFS ISDN TA (terminal adapter) functions provide the same functionality and operational behaviour as fixed ISDN terminal adapters that conform to the corresponding ITU-T Recommendations (V.110 or V.120).
Figure 13: Structure of the MSC/IWF (non-transparent)
10.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 and 3GPP TS 23.202 [90]) contain the mechanism for packing and unpacking the user data into the L2R protocol data units.
10.2.4.4 Layer 2 relay functionality
Specific functionality is required on 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 the call set‑up request, or call confirmation message. The prime information element being transparent or non transparent service indication. In addition the particular L2R function ‑ type of protocol to be terminated and mode of flow control to be applied (see appropriate subclauses in 3GPP TS 27 series) ‑ will be selected on the basis of the user’s layer 2 indication.
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.
10.2.4.5 In band signalling mapping flow control
This entails the L2R function providing the means of controlling and responding to flow control function of the modem (or in the rate adapted frame) plus any synchronizations requirements related to flow control. For asynchronous services a specific rule applies for flow control (see 3GPP TS 27.001).
In case of interworking to the ISDN "3,1kHz audio" bearer service the flow control process is as for the PSTN interworking case (see subclause 9.2.4.5). In case of interworking to the ISDN unrestricted digital bearer service the following procedures apply:
The flow control function chosen will be dependent upon the availability of the "user information layer 2" information element of the PLMN BC and if available its value.
For V.110 interworking, outband flow control will be by means of the "X" bit in the V.110 frame to the ISDN.
For V.120 interworking, outband flow control shall be as follows. In Multiple frame acknowledged mode the functions of the data link control sublayer (send RNR or withhold update of the sequence state variable V(R)) shall be used. In Unacknowledged mode the RR bit in the Control State octet shall be used.
For PIAFS interworking, outband flow control shall be as follows. The functions of the data link control sublayer (withhold update of the frame number) shall be used.
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.
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 as stated below.
10.2.4.5.1 Conditions requiring flow control ‑ if flow control is provided ‑ towards the fixed network
The L2R function will initiate flow control in the following circumstances:
1) the transmit buffer to the radio side reaches a preset threshold (BACK PRESSURE);
2) the L2R function receives a "flow control active" indication.
On removal of buffer congestion or receipt of L2R "flow control inactive" the flow control will be removed.
No flow initiation/removal will take place at the L2R function and loss of data may occur, if no flow control is provided.
10.2.4.5.2 Conditions requiring flow control towards the UE
The L2R function will transmit to the UE a "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.
10.2.4.6 Data buffers
10.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 10.2.4.5.1.
10.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 10.2.4.5.2.
10.2.4.7 BREAK Indication
The BREAK indication is managed as detailed in subclause 9.2.4.7.
When V.120 rate adaptation is being used in protocol sensitive asynchronous mode on the ISDN, the L2R break condition shall map on to the BR bit of the V.120 header octet.
10.2.4.8 Signalling mapping of modem or ISDN (V.110, V.120 or PIAFS) TA-function status information
Status information is carried between the modem or ISDN (V.110, V.120or PIAFS) TA-function in the IWF and the terminal adaption 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 9 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 ISDN TA function is described in terms of V.24 interchange circuit functions, this does not imply that such circuits need to be physically realised.
Table 9: Mapping scheme at the IWF for the non-transparent mode
|
Mapping |
Mapping |
Signal at IWF ISDN TA 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 ISDN TA function in the IWF. However, CT 105 should always be ON at the mobile 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 ISDN TA function 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, 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 in the IWF (from the UE). 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 ISDN TA function. 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 ISDN TA function. CT 133 is always set to ON. |
||
10.2.4.9 Support of out‑band flow control
Out‑band flow control in the case of V.110 rate adaption requires V.110 TA to TA "end‑to‑end flow control" as defined therein. If this functionality is requested by UE but cannot be supported by the MSC/IWF for any reason (refer also to note 15 of table 7B) the call pending shall be released.
For V.120 interworking, outband flow control shall be as follows. In Multiple frame acknowledged mode the functions of the data link control sublayer (send RNR or withhold update of the sequence state variable V(R)) shall be used. In Unacknowledged mode the RR bit in the Control State octet shall be used.
10.2.4.10 Synchronizations
In case of interworking to the ISDN "3,1kHz audio" bearer service the synchronization process is as for the PSTN interworking case (see subclause 9.2.3.4). In case of interworking to the ISDN unrestricted digital bearer service the following synchronization process shall be performed:
10.2.4.10.1 V.110 and V.120 Frame synchronizations
The ISDN frame synchronizations will need to be mapped to the frame synchronizations utilized on the MSC/IWF to MSC link.
10.2.4.10.2 RLP Frame start indication
The frame start indication is defined in 3GPP TS 48.020. Link establishment and frame error recovery are defined in 3GPP TS 24.022.
10.2.4.10.3 L2R Frame synchronizations
The synchronizations of user data and its interaction between the L2R function and RLP function are defined in 3GPP TS 27 series.
10.2.4.10.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 synchronization process:
– starting on the indication of "physical connection established" resulting from the PLMN‑inherent outband signalling procedure This indication is :
– 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.
10.2.4.10.4.1 Terminating side (towards the UE)
The procedures are the same as for the modem case.
10.2.4.10.4.2 Transit side (towards the fixed network)
Depending upon implementation, the synchronization of the V.110 or V.120 rate adaptation protocol on the ISDN transit network may be performed either after RLP establishment or in parallel to the RLP establishment. In case of the parallel establishment, 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 and on recognizing frame alignment the information from/to the RLP is mapped by the L2R entity applicable to this particular bearer capability.
For V.110 rate adaptation on the ISDN, the synchronization process consists of sending the V.110 frame structure and looking for incoming frame synchronization according to the procedures in ITU-T Recommendation V.110.
For V.120 rate adaptation the following applies. In Multiple frame acknowledged mode, data (I frames) may be sent following an exchange of SABME and UA in the traffic channel. In Unacknowledged mode, data (UI frames) may be sent immediately after an ISUP CONNECT or CONNECT COMPLETE message has been received on the ISDN signalling channel. Optionally, an XID exchange may take place in the traffic channel to verify link integrity.
Note. V.120 allows UI frames to be sent in Multiple frame acknowledged mode at any time in addition to I frames. Whilst the IWF shall not follow this procedure when sending frames, such a sequence of I and UI frames may be received by the IWF. Although not specified in V.120, it is recommended that the IWF should deliver to the UE, the contents of the sequence of I and UI frames in the order in which they are received.
For PIAFS rate adaptation the following applies. Data frame is sent following an exchange of initial negotiation and control frame in the traffic channel.
10.2.4.11 Data compression
When data compression is invoked within a non‑transparent bearer service, interworking to the ISDN is realized by mapping the PLMN user rate to at least the same user rate in the ISDN. When the ISDN user rate is the same flow control will ensure data integrity, but the overall performance will be slow. When the ISDN user rate is higher the overall performance may be faster.
10.2.4.12 Additional aspects of V.120 Interworking
V.120 rate adaptation may be invoked with asynchronous services only. V.120 is applicable to both UDI and RDI connections.
10.2.4.12.1 V.120 Signalling parameters
The signalling parameters relevant to V.120 will be carried in the ISDN LLC and PLMN BC and PLMN LLC information elements. The mapping of the parameter values takes place in the MSC/IWF.
For mobile terminated calls both single-numbering and multi-numbering scenarios may apply, as defined in subclause 9.2.2. The HLR shall not store an ISDN LLC with the MSISDN.
10.2.4.12.2 V.120 Protocol parameters
The following restrictions apply for the parameters relevant for V.120:
– BS 20 NT will use the protocol sensitive asynchronous mode. As a consequence, the rate adaption header shall always be present.
– Only the default logical link will be established, i.e. the LLI negotiation value is "Default, LLI=256 only".
– V.120 recommends the use of the multiple frame acknowledged information transfer procedure for the protocol sensitive mode of operation.
– The IWF shall use the default value for the V.120 window size and the default value for the maximum transmit information field size. It shall be able to receive frames with the default maximum size.
NOTE: V.120 does not specify the values for these and other HDLC-related parameters directly. They are specified in Q.922 (1992) section 5.9. The information field includes the V.120 terminal adaption data field, the rate adaption header and the header extension (Control State octet), if present.
10.2.4.12.3 Data compression on the ISDN
Whilst V.110 rate adaptation does not support standardized data compression, V.42bis data compression may be used with V.120 protocol sensitive asynchronous mode. This is described in V.120 (10/96) annex C.
10.2.4.12.4 Use of the V.120 Control State (header extension) octet
The bits in the V.120 Control State octet are not used for the control of V.24 interface circuits. In unacknowledged mode the RR bit in the Control State octet is used to carry flow control information between the peer terminal adaption protocol entities. In acknowledged mode the Control State octet is not required.
10.2.4.13 Interworking with restricted 64 kbit/s networks
10.2.4.13.1 Rate adaptation
Both V.110 and V.120 rate adaption protocols may be used on a restricted 64 kbit/s network.
For V.110 rate adaption, the procedure is described in ITU-T Recommendation I.464. The RA2 function shall set the 8th bit of each octet in the 64 kbit/s stream to binary 1. A consequence of this is that the highest permitted intermediate rate is 32 kbit/s. At the receiver, the 8th bit shall be ignored.
Rec. V.120 states that the user data shall be rate adapted to 56 kbit/s by using only the first 7 bits of each octet in the 64 kbit/s stream. The 8th bit shall be set to binary 1. At the receiver, the 8th bit shall be ignored.
10.2.4.13.2 MSC – ISDN signalling
When interworking indirectly with restricted 64 kbit/s networks the ISDN BC information element shall be coded according to ETR 018 (as shown in the notes to tables 7A and 7B). The information corresponding to the PLMN BC-IE shall be communicated in the ISDN LLC-IE which shall be provided by the UE for mobile originated calls.
In the case of direct interworking, an ITC = RDI in the PLMN BC-IE maps on to an ITC = RDI in the ISDN BC-IE for both MO and MT calls.
10.2.4.14 Service level up and down grading
Text in 9.2.4.12 applies here as well.
10.2.4.15 Interworking in Frame Tunneling Mode
Figure 14 below shows the protocol stack used for FTM. The interface between the two asynchronous-synchronous conversion functions in the IWF and the remote terminal adapter (TA) is a 64 kbit/s UDI or a 56 kbit/s RDI connection. X.31 flag stuffing is used to adapt the rate between the two conversion functions. Data transparency is provided through bit stuffing.
Figure 14: The FTM protocol stack
Data compression between the TAF and the IWF is optionally applied. The asynchronous to synchronous HDLC conversion follows from ISO/IEC 3309[48].
A particular aspect of the asynchronous HDLC protocol is the provision of control character transparency. This means that flags (0x7E) and the control escape character (0x7D) are escaped, by insertion of the control escape character in front of the character to be escaped, and that the 6th bit of the escaped character is complemented (i.e., the escaped character is XOR’ed with 0x20). ISO/IEC 3309[48] allows additional control characters to be escaped by prior agreement or negotiation between the peer entities. For instance, in PPP [49], a negotiation procedure is defined using an Asynchronous Control Character Map (ACCM). By examining the contents of the HDLC frames that pass through it, the IWF shall identify whether the higher layer protocol is PPP, in which case, it shall detect and interpret the ACCM negotiation result. If PPP is used, the conversion function in the IWF shall apply a default ACCM until another is negotiated.
10.2.4.16 Additional aspects of PIAFS Interworking
PIAFS has several U-Plane protocol suites, but "Data Transmission Protocol (fixed rate)"[50] is only applied for UTRAN Iu mode in consideration of simplicity. Details of frame structure and retransmission procedure etc. conform to reference [50].
In case of 32kbit/s mode, IWF performs rate adaptation based on I.460 for fixed network.
In case of 64 kbit/s mode, restriction on throughput may be caused by (the maximum frame length of 572bits in RLP).
10.2.5 DTE/DCE interface (Filtering)
This is described in section 9.2.5.
10.3 Interworking Alternate speech facsimile group 3 calls
10.3.1 Alternate speech data bearer interworking
10.3.1.1 General
The procedure for the alternate speech/facsimile group 3 service is invoked at the 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" plus user rate etc., as for normal single calls. The bearer capability first indicated i.e. speech or facsimile 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 the 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 for mobile originated calls and optionally for mobile terminated calls (single numbering scheme) on both sets of capabilities as for normal data calls. If either the subscription check or the compatibility check fails then the call shall be rejected. The only exception to this is when TS61/TS62 negotiation takes place, see 3GPP TS 27.001.
As regards the supplementary services the application rules are laid down in 3GPP TS 22.004.
The speech phase of the call, when invoked, is handled by the transcoder and will utilize the normal telephony teleservice interworking requirements and mobile network capabilities. The Facsimile group 3 phase of the call, when invoked, shall utilize the appropriate data interworking capability (e.g. IWF) 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.
10.3.1.2 Mobile originated ISDN terminated
If one bearer capability information element indicates the ITC value "facsimile group 3", the call set up is as for the PSTN case. Interworking is provided to the ISDN bearer service 3,1 kHz audio for the whole connection, including the speech phase. The MODIFY message (see 3GPP TS 24.008) will be generated by the mobile subscriber. This message is not transmitted to the ISDN, i.e. no outband correlation between the user on the fixed network and the mobile user will be possible. In this instance it is necessary for change of network capabilities to be carried out in the mobile network.
10.3.1.3 ISDN originated mobile terminated
In principle this is handled as for a normal ISDN originated call.
However when the calling user indicates an ISDN BC‑IE with an ITC value "3,1 kHz audio" and an HLC "facsimile group 3", i.e. the call arrives at the PLMN with compatibility information allowing for deducing the Teleservice "Facsimile transmission", the call setup is as described in subclause 10.2.2.3 case 3 in the HLR, and subclause 10.2.2.4 case 5 in the VMSC.
In the information transfer phase the call is dealt with as indicated in the previous paragraph.
10.4 3G-H.324/M calls over UDI/RDI
3G-H.324/M calls provide UDI/RDI (e.g. 32 kbit/s transparent data, 56 kbit/s transparent data or 64 kbit/s transparent data). H.223 and H.245 flow is not terminated in the MSC.
3G-H.324 calls over 64 kbit/s transparent data and 56kbit/s transparent data can be connected to H.324/I calls over UDI/RDI. H.223 protocol is transparent to IWF.
In case of 3G-H.324M calls over 32 kbit/s, IWF which performs rate adaptation between 64kbit/s and 32kbit/s is used. Rate adaptation is based on ITU-T Recommendation I.460.
The Service Change and Fallback functionality for UDI/RDI multimedia calls is described in 3GPP TS 23.172 [83].
The support of IWF which transcodes the multiplexes and the content of control, audio, video and data in MSC is FFS.
10.4.1 Mobile originated multimedia call
10.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 / service change allowed) or both a speech BC-IE and a multimedia BC-IE to indicate the support of fallback and service change (see 3GPP TS 27.001 [43] and 3GPP TS 24.008 [40]).
The MSC shall not accept a requested service to which the user is not provisioned for. Provided that the user is provisioned for the BS30 bearer service – and/or speech the following applies :
– in case of a multimedia only BC-IE, the MSC shall either accept the setup as such or with modifications sent to the UE in the call proceeding message (see 3GPP TS 27.001 [43]) ;
– in case of both a speech BC-IE and a multimedia BC-IE in either order, the MSC shall either accept the possibility of fallback or service change by responding with the two BC-IEs in the same order as received, in the reverse order (relayed from terminating user), 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 the multimedia BC-IE in the call proceeding message (see 3GPP TS 27.001 [43]).
– in case of a multimedia BC-IE with FNUR = 32 kbit/s and a speech BC-IE, the MSC shall reply with only a multimedia BC-IE in the call proceeding message (see 3GPP TS 23.172 [83]).
10.4.1.2 Fallback after setup
If the MSC has accepted the possibility of a fallback and service change, and the transit network or the terminating side does not allow one of the bearers, the MSC shall initiate an In-Call Modification procedure (see 3GPP TS 24.008 [40]) in order to fallback to the allowed mode. As a result of the procedure, the radio and network resources are modified and the relevant channel is set up between the calling UE and the fixed network. If the fallback fails, e.g. due to an unsuccessful In-Call Modification procedure, the MSC shall clear the call.
10.4.1.3 User initiated service change after setup
If the MSC has accepted the possibility of a service change and the user initiates an In-Call Modification procedure (see 3GPP TS 24.008 [40]) in order to change the service either from speech to multimedia or vice-versa, the MSC shall invoke the service change as an In-Call Modification procedure. As a result of the procedure, the radio and core network resources are modified in order to comply with the requested service change.
10.4.2 Mobile terminated multimedia call
10.4.2.1 Call setup
If the user is provisioned to use both the transparent bearer service (for multimedia) and the speech teleservice, and if the network supports both services and the service change functionality, the MSC shall send both a multimedia BC-IE and a speech BC-IE in the setup message to the mobile station. In case the MSC receives a multimedia call, the multimedia BC-IE is prioritised (first BC). In case the MSC receives a speech call, the speech BC is prioritised.
If the user is provisioned to use only the transparent bearer service and if the network supports the multimedia service, the MSC shall only send a multimedia BC-IE, which results in a fallback to multimedia if the call was a speech call.
If the user is provisioned to use only the speech teleservice, the MSC shall only send a speech BC-IE, which results in a fallback to speech if the call was a multimedia call.
In case both a speech BC-IE and a multimedia BC-IE are included in the setup message, the mobile station shall either accept the service change capability by responding with two BC-IEs in the same or reversed order, 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 service change 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.
10.4.2.2 User initiated service change after setup
If the MSC supports the possibility of a service change and the user initiates an In-Call Modification procedure (see 3GPP TS 24.008 [40]) in order to change the service either from speech to multimedia or vice-versa, the MSC shall invoke the service change as an In-Call Modification procedure. As a result of the procedure, the radio and core network resources are modified in order to comply with the requested service change.