9 Interworking
23.1073GPPQuality of Service (QoS) concept and architectureRelease 17TS
The model for the UMTS QoS classes and attributes may not be any existing network or QoS protocol/mechanisms as such. The main goal of the specification is not to copy existing QoS mechanisms but rather to create a future proof concept that will provide means to transport different types of data with different QoS requirements. Thus the interworking of UMTS and existing network technologies has to be ensured. This clause presents the most common technologies that UMTS shall be capable to interwork with.
9.1 UMTS-GSM CS/GPRS
9.1.1 UMTS-GSM CS
The mapping between UMTS-GSM CS is based on GSM CS mechanisms and CC parameters.
9.1.1.1 Handover from UMTS to GSM
In case a UMTS call is set up in the CN, the BC IEs are mapped into QoS RAB attributes at call setup.
If the CN has to perform a handover towards GSM, the non-anchor MSC needs to perform an assignment based on GSM specific traffic channel attributes.
As the BSSMAP protocol is used over the E-interface and as no appropriate procedure exists to map QoS attributes into BSSMAP parameters, the anchor MSC shall map BC IEs into GSM traffic channel parameters, according to existing GSM procedures for call setup.
This requires that the BC IE is coded according to GSM protocol requirements, i.e. all those parameters not applicable to UMTS should nevertheless be correctly specified by the UE in order to perform a handover to GSM according the above specified principles.
9.1.1.2 Handover from GSM to UMTS
In case a GSM call is set up in the CN, the BC IEs are mapped into channel type parameters at call setup.
If the CN has to perform a handover towards UMTS, the non-anchor MSC needs to perform an assignment based on UMTS specific radio access bearer attributes.
As the BSSMAP protocol is used over the E-interface, the non-anchor MSC shall use the received Channel Type parameter (e.g. ‘speech or data indicator’, the type of data service (transparent/non-transparent) and user rate) to derive the QoS RAB attributes.
9.1.2 UMTS-GPRS
This clause covers primarily the mapping of QoS attributes that are necessary across standardised interfaces. In addition to these, there are cases when mapping of QoS attributes are needed internal to a node.
GPRS Release 99 (R99) QoS attributes shall be equivalent to the UMTS QoS Attributes. For interworking purposes between different releases, mapping rules between GPRS Release 97/98 (R97/98) and GPRS Release 99 (R99) as well as UMTS are defined. Mapping shall occur whenever the UE, the SGSN, the GGSN and the HLR nodes are of different releases R97/98 or R99. The mapping is required in PDP context activation and modification procedures and when a R99 HLR Insert Subscriber Data towards a R97/98 SGSN.
It is not within the scope of the present document to determine if any value combinations of attribute values can not be supported. This means that complete mapping rules are defined here, and if the user requests a QoS profile which the network is not able to support (e.g. a low delay and a high reliability), the decision if such a attribute combination can be supported is left to admission control functionality within the PDP context activation procedure, and the QoS for such a profile may be renegotiated by the network based on the available resources.
The overall principle for the mapping between two profiles is that the two profiles, applied in their respective network releases, give the same or at least similar QoS. The GPRS R97/98 equipment will not be able to provide realtime service corresponding to the R99 conversational and streaming traffic classes. Therefore, the mapping is always to the non-realtime interactive and background traffic classes.
The R97/R98 QoS attributes are described in TS 03.60 Release 1998 [10].
9.1.2.1 General rules
Air interface Session Management and GTP messages of R99 shall contain the R99 attributes as an extension of the R97/98 QoS Information Element thus unnecessary mapping can be avoided. When a R97/98 MS is visiting a GPRS R99 or UMTS SGSN and the GGSN is of R97/98 or R99, the visited SGSN shall not perform any mapping of QoS attributes. In case of GGSN R99, the GTP version 1 (R99) QoS profile only contains the R97/98 QoS attributes. It can be noted that for this PDP Context a Traffic Flow Template (TFT) can not be requested.
When a R99 UE is visiting a GPRS R99 or UMTS SGSN (or serving PLMN) and the GGSN (or home PLMN) is of R97/98, the visited SGSN (or visited PLMN) shall be capable of providing bearers having QoS support according to R99. When a PDP Context is activated (mobile or network initiated) mapping takes place in the serving SGSN.
For MS initiated PDP Context Activations as well as network initiated PDP Context Activations, the home R97/98 GGSN will respond to the activation request by returning a the QoS Negotiated Profile, which contain the accepted and changed R97/98 attributes. A mapping of the changed attributes into R99 attributes will be done in serving SGSN and signalled to the UE in the Activate PDP Context Accept message.
It is a general mapping rule that returned and unchanged attributes during negotiation procedures shall not be mapped a second time by serving SGSN, i.e. the unchanged R99 attributes received in the Create PDP Context Response message will be sent to UE in QoS Negotiated Profile of the Activate PDP Context Accept message.
MAP message of R99 shall also contain the R99 attributes as an extension of the R97/98 QoS Information Element when Insert Subscriber Data message is sent to a R99 SGSN. In the case when a R99 HLR send a Insert Subscriber Data message to a R97/98 SGSN, the message shall contain the R97/98 QoS attributes. A R99 SGSN shall use the R99 attributes of subscribed QoS profile when a R99 UE requests to use subscription data in the PDP Context Activation. The R99 SGSN shall use the R97/98 attributes of subscribed QoS profile when a R97/98 MS requests to use subscription data in the PDP Context Activation.
9.1.2.2 Determining R99 attributes from R97/98 attributes
This mapping is applicable in the following cases:
– hand over of PDP Context from GPRS R97/98 SGSN to GPRS R99 or UMTS SGSN;
– PDP Context Activation in a serving R99 SGSN with a R97/98 GGSN. When GGSN respond to the PDP Context Activation, mapping of the changed R97/98 QoS attributes received from the GGSN to R99 QoS attributes is performed in the serving SGSN.
This mapping is also applicable if a R99 UE allows an application to request a PDP Context Activation with R97/98 QoS attributes, e.g. via AT command.
Table 6: Rules for determining R99 attributes from R97/98 attributes
|
Resulting R99 Attribute |
Derived from R97/98 Attribute |
||
|---|---|---|---|
|
Name |
Value |
Value |
Name |
|
Traffic class |
Interactive |
1, 2, 3 |
Delay class |
|
Background |
4 |
||
|
Traffic handling priority |
1 |
1 |
Delay class |
|
2 |
2 |
||
|
3 |
3 |
||
|
SDU error ratio |
10-6 |
2 |
Reliability class |
|
10-4 |
3 |
||
|
10-3 |
4, 5 |
||
|
Residual bit error ratio |
10-5 |
2, 3, 4 |
Reliability class |
|
4*10-3 |
5 |
||
|
Delivery of erroneous SDUs |
‘no’ |
2, 3, 4 |
Reliability class |
|
‘yes’ |
5 |
||
|
Maximum bitrate [kbps] |
8 |
1 |
Peak throughput class |
|
16 |
2 |
||
|
32 |
3 |
||
|
64 |
4 |
||
|
128 |
5 |
||
|
256 |
6 |
||
|
512 |
7 |
||
|
1024 |
8 |
||
|
2048 |
9 |
||
|
Allocation/Retention priority |
1 |
1 |
Precedence class |
|
2 |
2 |
||
|
3 |
3 |
||
|
Delivery order |
yes’ |
yes’ |
Reordering Required (Information in the SGSN and the GGSN PDP Contexts) |
|
‘no’ |
‘no’ |
||
|
Maximum SDU size |
1 500 octets |
(Fixed value) |
|
|
Priority Level of Evolved Allocation/Retention priority |
1 to H |
1 |
Precedence class |
|
H+1 to M |
2 |
||
|
M+1 to 15 |
3 |
||
NOTE 1: As the allocation/retention priority attribute is not available in the UE (see 6.4.4.1) the mapping of the allocation/retention priority attribute is not relevant for the UE.
NOTE 2: The values of H (high priority) and M (medium priority) can be set according to operator requirements to ensure proper treatment of users with higher priority level information. The minimum value of H is 1. The minimum value of M is H+1.
As the reordering required attribute is not available in the MS the MS should set the R99 delivery order attribute to the value "no" for PDP Type = "IPv4" or "IPv6", otherwise the MS shall set the delivery order attribute to the value "subscribed" (see TS 24.008 [6]).
9.1.2.3 Determining R97/98 attributes from R99 attributes
This mapping is applicable in the following cases:
– PDP Context is handed over from GPRS R99 or UMTS to GPRS R97/98;
– when a R99 UE perform a PDP Context Activation in a serving R99 SGSN while the GGSN is of R97/98. In this case the SGSN shall perform mapping of the R99 QoS attributes to the R97/98 QoS attributes;
– a R99 HLR may need to map the stored subscribed QoS attributes in the HLR subscriber data to R97/98 QoS attributes that are going to be sent in the Insert Subscriber Data message from the R99 HLR to the R97/98 and R99 SGSN. It is an implementation issue if the R97/98 QoS attributes are stored in the HLR in addition to the R99 QoS attributes;
NOTE 1: UE handling for the case that a R99 UE (except UMTS only UE) receives a request for a PDP Context Activation with R99 QoS attributes via AT command, is implementation dependent.
Table 7: Rules for determining R97/98 attributes from R99 attributes
|
Resulting R97/98 Attribute |
Derived from R99 Attribute |
||
|---|---|---|---|
|
Name |
Value |
Value |
Name |
|
Delay class |
1 |
conversational |
Traffic class |
|
1 |
streaming |
Traffic class |
|
|
1 |
Interactive |
Traffic class |
|
|
1 |
Traffic handling priority |
||
|
2 |
Interactive |
Traffic class |
|
|
2 |
Traffic handling priority |
||
|
3 |
Interactive |
Traffic class |
|
|
3 |
Traffic handling priority |
||
|
4 |
Background |
Traffic class |
|
|
Reliability class |
3 |
<= 10-5 |
SDU error ratio (NOTE 4) |
|
3 |
10-5 < x <= 5*10-4 |
SDU error ratio |
|
|
4 |
> 5*10-4 |
SDU error ratio |
|
|
<= 2*10-4 |
Residual bit error ratio |
||
|
5 |
> 5*10-4 |
SDU error ratio |
|
|
> 2*10-4 |
Residual bit error ratio |
||
|
Peak throughput class |
1 |
< 16 |
Maximum bitrate [kbps] |
|
2 |
16 <= x < 32 |
||
|
3 |
32 <= x < 64 |
||
|
4 |
64 <= x < 128 |
||
|
5 |
128 <= x < 256 |
||
|
6 |
256 <= x < 512 |
||
|
7 |
512 <= x < 1024 |
||
|
8 |
1024 <= x < 2048 |
||
|
9 |
>= 2048 |
||
|
Precedence class |
1 |
1 |
Allocation/retention priority |
|
2 |
2 |
||
|
3 |
3 |
||
|
Mean throughput class |
Always set to 31 |
– |
|
|
Reordering Required (Information in the SGSN and |
yes’ |
yes’ |
Delivery order |
|
the GGSN PDP Contexts) |
‘no’ |
‘no’ |
|
|
Precedence class |
1 |
1 |
Priority Level of the Evolved |
|
2 |
H+1 |
Allocation/retention priority |
|
|
3 |
M+1 |
||
As the allocation/retention priority attribute is not available in the UE (see 6.4.4.1) the UE shall set the R97/98 precedence class attribute to the value "subscribed" (see TS 24.008 [6]).
NOTE 2: For asymmetric bearers, the higher value of the maximum bitrate attributes for downlink and uplink is selected and used for the maximum bitrate value.
NOTE 3: The values of H (high priority) and M (medium priority) can be set according to operator requirements to ensure proper treatment of users with higher priority level information. The minimum value of H is 1. The minimum value of M is H+1.
NOTE 4: To avoid interoperability issues with LLC acknowledged mode the Reliability Class is set to "3" by the network in case the SDU error ratio is "<= 10‑5". The UE will receive both R97/98 and R99, or only R97/98 (when UE is a pre-R99 UE) QoS attributes from the network of this release.
9.2 UMTS-PSTN
PSTN does not have QoS mechanisms thus QoS attribute interworking/mapping is not needed.
NOTE: The details are to be solved by CN WG3.
9.3 UMTS-ISDN
ISDN does not have QoS mechanisms thus QoS attribute interworking/mapping is not needed. However, means for determining required bandwidth, delay and reliability has to be developed. It is simple in MO cases but in MT cases the mechanisms (or in worst case defaults) have to be developed.
NOTE: The details are to be solved by CN WG3.
9.4 UMTS-Internet
In the case of Internet applications, the selection of the class and appropriate traffic attribute values is made according to the Internet QoS attributes. Internet applications do not directly use the services of UMTS but they use Internet QoS definitions and attributes, which are mapped to UMTS QoS attributes at API. Currently there are two main Internet QoS concepts, namely Integrated Services and Differentiated Services. The mapping between Internet QoS and UMTS QoS is presented in following clause.
IP based QoS models shall be supported for PDP contexts, meaning both Integrated Services (IntServ) signalled by RSVP [RFC 2205] and Differentiated Services (6-bit QoS attribute on each IP packet, DiffServ). Both mechanisms are controlled by applications residing in the TE, allowing different application specific QoS levels for the same PDP context. The way application level QoS and UMTS level QoS interact is detailed in TS 23.207 [7].
Annex A (informative):
Error resilience in real-time packet multimedia payloads