Content for TS 23.207 Word version: 18.0.0
A.2 Scenarios p. 19
These scenarios give examples of concatenating QoS mechanisms in different parts of the network which together can deliver an end-to-end QoS. These scenarios are not intended to describe the details of the interworking between the QoS mechanisms.
The different scenarios involve cases with and without service based local policy. Each scenario describes the applicable cases, possibly by referencing another scenario. In some scenarios, only one of the cases may be valid (e.g. scenario 5). Where both cases are covered, they may be described together identifying the optionality, or separately for clarity of the individual cases.
The optional authorisation token is associated with the cases involving service based local policy, and is applicable for IM services. It is an operator decision whether or not to support service based local policy for IM services. If service based local policy is not supported, or not applicable (i.e. not IM service), then the optional authorisation token and application server at the P-CSCF are not used.
IM services not using service based local policy will typically follow scenarios 1 to 4. IM services using service based local policy will typically follow scenarios 3 to 5.
A.2.1 Scenario 1 p. 20
The UE does not provide an IP BS Manager. The end-to-end IP QoS bearer service towards the remote terminal is controlled from the GGSN.
The scenario assumes that the GGSN supports DiffServ edge functions, and the backbone IP network is DiffServ enabled.
The application layer (e.g. SIP/SDP) between the end hosts identifies the QoS requirements. The QoS requirements determined from the application layer (e.g. TS 23.228 describes interworking from SIP/SDP to QoS requirements) are mapped down to PDP context parameters in the UE.
In this scenario, the control of the QoS over the UMTS access network (from the UE to the GGSN) may be performed either from the terminal using the PDP context signalling, or from the SGSN by subscription data.
The IP QoS for the downlink direction is controlled by the remote terminal up to the GGSN. The GGSN will apply receiver control DiffServ edge functions and can reclassify the data (remarking the DiffServ Code Point (DSCP)). This may affect the QoS applied to the data over the UMTS access (the TFT may use the DSCP to identify the data to be allocated to the PDP context).
The end-to-end QoS is provided by a local mechanism in the UE, the PDP context over the UMTS access network, DiffServ through the backbone IP network, and DiffServ in the remote access network in the scenario shown in the Figure below. The GGSN provides the interworking between the PDP context and the DiffServ function. However, the interworking may use information about the PDP context which is established, or be controlled from static profiles, or dynamically through other means such as proprietary HTTP based mechanisms. The UE is expected to be responsible for the control of the PDP context, but this may instead be controlled from the SGSN by subscription.
Notes:
- The solid horizontal lines indicate the mechanism that is providing QoS for the flow of data in the direction indicated.
- The dashed horizontal lines indicate where QoS control information is passed that is not directly controlling the QoS in that link/domain.
- The arrows on the horizontal lines indicate nodes that receive information about QoS from that mechanism, even if that mechanism is not used to control the QoS over that link/domain.
- The solid vertical lines indicate interworking between the different mechanisms.
- In the Figure, the term RAP refers to the Remote Access Point, and RUE is the Remote UE.
A.2.2 Scenario 2 p. 21
The UE performs an IP BS function which enables end-to-end QoS without IP layer signalling towards the IP BS function in the GGSN, or the remote terminal.
The scenario assumes that the UE and GGSN support DiffServ edge functions, and that the backbone IP network is DiffServ enabled.
The application layer (e.g. SIP/SDP) between the end hosts identifies the QoS needs. The QoS requirements from application layer (e.g. TS 23.228 describes interworking from SIP/SDP to QoS requirements) are mapped down to the IP layer. The IP layer service requirements are further mapped down to the PDP context parameters in the UE.
In this scenario, the control of the QoS over the UMTS access network (from the UE to the GGSN) may be performed either from the terminal using the PDP context signalling. Alternatively, subscription data accessed by the SGSN may override the QoS requested via signalling from the UE (according to the procedures specified in TS 23.060).
In this scenario, the terminal supports DiffServ to control the IP QoS through the backbone IP network.
The IP QoS for the downlink direction is controlled by the remote terminal up to the GGSN. The PDP context controls the QoS between the GGSN and the UE. The UE may apply DiffServ edge functions to provide the DiffServ receiver control. Otherwise, the DiffServ marking from the GGSN will determine the IP QoS applicable at the UE.
The end-to-end QoS is provided by a local mechanism in the UE, the PDP context over the UMTS access network, DiffServ through the backbone IP network, and DiffServ in the remote access network in the scenario shown in the Figure below. The UE provides control of the DiffServ, and therefore determines the appropriate interworking between the PDP context and DiffServ.
The GGSN DiffServ edge function may overwrite the DSCP received from the UE, possibly using information regarding the PDP context which is signalled between the UMTS BS managers and provided through the translation/mapping function to the IP BS Manager.
Note that DiffServ control at the Remote Host is shown in this example. However, other mechanisms may be used at the remote end, as demonstrated in the other scenarios.
