Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.207  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   5…   6…   A…   C   D…

 

A  QoS Conceptual ModelsWord‑p. 19

A.1  Introduction

There are many different end-to-end scenarios that may occur from a UE connected to a UTMS network. The following examples depict how end-to-end QoS will be delivered for a number of scenarios that are considered to be significant.
In all the scenarios presented below, the network architecture is as shown in Figure A.1 below.
(not reproduced yet)
Figure A.1: Network Architecture for QoS Conceptual Models
Up
Notes:
  • Although the backbone IP network is shown as a single domain, it may consist of a number of separate domains.
  • The structure of the Local UE is not specified. It includes cases from a simple host, to a gateway to a network such as a LAN. If the UE is acting as a gateway, it is responsible for providing the IP BS Management towards the extended network.
  • The remote side is shown as a simple host. Other more complex cases on the remote side such as a private LAN with over-provisioning, or possibly LAN priority marking, and DiffServ and/or RSVP capable routing elements is not depicted. It is envisaged however that interworking between the QoS mechanisms in a more complex remote user side could also be performed with some similarities to the mechanisms shown at the local side.
The reference point shown at the UE is at the interface to the UE. Within the UE, the QoS control could be derived from any of the mechanisms that occur across that reference point, or it could use a different mechanism internally.
Although the scenarios currently identified are mainly using DiffServ in the backbone IP network (RSVP is indicated as an alternative in scenario 4), it is not mandated that DiffServ must be used in the backbone IP network. Other mechanisms, for example, over-provisioning and aggregated RSVP may be used.
Up

A.2  ScenariosWord‑p. 20
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.
Up

A.2.1  Scenario 1

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.
(not reproduced yet)
Figure A.2: Local UE does not provide IP BS Manager
Up
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.
No solid vertical line is shown from DiffServ to PDP flow on the downlink at the GGSN. The TFT determines the QoS applicable over the UMTS access. However, the configuration of the TFT may use the DiffServ to select the PDP context to be applied, so there may be interworking between DiffServ and the PDP Flow via the TFT filters.
Up

A.2.2  Scenario 2Word‑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.
(not reproduced yet)
Figure A.3: Local UE supports DiffServ
Up

A.2.3  Scenario 3Word‑p. 22
The UE performs an IP BS function which enables end-to-end QoS using IP layer signalling towards the remote end. There is no IP layer signalling between the IP BS Managers in the UE and the GGSN. However, the GGSN may make use of information regarding the PDP context which is signalled between the UMTS BS managers and provided through the translation/mapping function.
This scenario assumes that the UE and GGSN support DiffServ edge functions, and that the backbone IP network is DiffServ enabled. In addition, the UE supports RSVP signalling which interworks within the UE to control the DiffServ.
The application layer (e.g. SIP/SDP) between the end hosts identifies the QoS requirements. The QoS requirements from application layer (e.g. TS 23.228 describes interworking from SIP/SDP to QoS requirements) are mapped down to create an RSVP session. The UE shall establish the PDP context suitable for support of the RSVP session. The authorisation token from the application layer when included shall be mapped to the PDP context parameters, and may also be mapped to the RSVP signalling.
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 signalling via the RSVP protocol to control the QoS at the local and remote accesses, and DiffServ to control the IP QoS through the backbone IP network. The RSVP signalling protocol may be used for different services. It is expected that only RSVP using the Integrated Services (IntServ) semantics would be supported, although in the future, new service definitions and semantics may be introduced. The entities that are supporting the RSVP signalling should act according to the IETF specifications for IntServ and IntServ/DiffServ interwork.
The QoS for the wireless access is provided by the PDP context. The UE may control the wireless QoS through signalling for the PDP context. The characteristics for the PDP context may be derived from the RSVP signalling information, or may use other information.
QoS for the IP layer is performed at two levels. The end-to-end QoS is controlled by the RSVP signalling. Although RSVP signalling can be used end-to-end in the QoS model, it is not necessarily supported by all intermediate nodes. Instead, DiffServ is used to provide the QoS throughout the backbone IP network.
At the UE, the data is also classified for DiffServ. Intermediate QoS domains may apply QoS according to either the RSVP signalling information or DiffServ mechanisms. In this scenario, the UE is providing interworking between the RSVP and DiffServ domains. The GGSN may override the DiffServ setting from the UE. This GGSN may use information regarding the PDP context in order to select the appropriate DiffServ setting to apply, as shown in the figure below.
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 RSVP signalling may control the QoS at both the local and remote accesses. This function may be used to determine the characteristics for the PDP context, so the UE may perform the interwork between the RSVP signalling and PDP context.
The UE provides control of the DiffServ (although this may be overwritten by the GGSN), and in effect, determines the appropriate interworking between the PDP context and DiffServ.
(not reproduced yet)
Figure A.4: Local UE supports RSVP signalling with IntServ semantics, and DiffServ;
Up
without service based policy
The GGSN provides the interworking between the PDP context and the DiffServ function. The application layer signalling may be processed in the local network at an application server such as the P-CSCF in the case of SIP signalling. Interworking between the GGSN and the application layer is shown as a vertical line where applicable. This interworking is for policy control and is between the GGSN and the PDF policy function co-located in the P-CSCF, as shown in the figure below.
(not reproduced yet)
Figure A.5: Local UE supports RSVP signalling with IntServ semantics, and DiffServ;
Up
where service based policy is applied

A.2.4  Scenario 4Word‑p. 25
The UE performs an IP BS function which enables end-to-end QoS using IP layer signalling towards the remote end. However, the UE relies on this end-to-end communication being utilised by at least the access point (GGSN) in order to provide the end-to-end QoS.
This scenario assumes that the UE and GGSN support RSVP signalling which may control the QoS directly, or interwork with DiffServ. The backbone IP network is RSVP and/or DiffServ enabled.
The application layer (e.g. SIP/SDP) between the end hosts identifies the QoS requirements. The QoS requirements from application layer (e.g. TS 23.228 describes interworking from SIP/SDP to QoS requirements) are mapped down to create an RSVP session. The UE shall establish the PDP context suitable for support of the RSVP session. The authorisation token from the application layer shall be mapped to the PDP context parameters, and may also be mapped to the RSVP signalling.
In this scenario, the terminal supports signalling via the RSVP protocol to control the QoS across the end-to-end path. The GGSN also supports the RSVP signalling, and uses this information rather than the PDP context to control the QoS through the backbone IP network. The control of the QoS through the core is expected to be supported through interworking with DiffServ at the GGSN, although it may optionally be supported by per flow resource reservation. The RSVP signalling protocol may be used for different services. It is only expected that only RSVP using the Integrated Services (IntServ) semantics would be supported, although in the future, new service definitions and semantics may be introduced. The entities that are supporting the RSVP signalling may fully support the specifications for IntServ and IntServ/DiffServ interwork. If not, they are expected to set the break bit.
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).
QoS for the IP layer is performed at two levels. The end-to-end QoS is controlled by the RSVP signalling. Although RSVP signalling occurs end-to-end in the QoS model, it is not necessarily supported by all intermediate nodes. DiffServ is used to provide the QoS throughout the backbone IP network, although optionally each node may support RSVP signalling and allocation of resources per flow. An authorisation token may be included in the RSVP signalling and the PDP context establishment/modification. The GGSN may authorise the RSVP session and configure the Diffserv classifier functionality.
The GGSN supports the RSVP signalling and acts as the interworking point between RSVP and DiffServ. Intermediate QoS domains may apply QoS according to either the RSVP or DiffServ mechanisms.
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 RSVP in the remote access network in the scenario shown in the figure below. The RSVP signalling may control the QoS at the local access. This function may be used to determine the characteristics for the PDP context, so the UE may perform the interwork between RSVP and the PDP context.
(not reproduced yet)
Figure A.6: Local UE supports RSVP signalling using IntServ Semantics
Up

A.2.5  Scenario 5Word‑p. 26
The UE performs an IP BS function which enables end-to-end QoS without IP layer signalling and negotiation towards the IP BS function in the GGSN, or the remote host. The P-CSCF provides the authorization token to the UE during the SIP session setup process, and the UE provides the authorization token to the GGSN in the PDP context activation/modification message. The GGSN uses the authorization token to obtain a policy decision from the P-CSCF(PDF). This is done via the standardized interface between the PDF and GGSN. Even if the interface is an open interface where all information elements are standardized, the actual usage of the information is operator specific.
The scenario assumes that the 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 and further down to the PDP context parameters in the UE. The authorisation token from the application layer is included in the PDP context parameters by the UE.
In this scenario, the control of the QoS over the UMTS access network (from the UE to the GGSN) may be performed 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).
The QoS for the downlink direction is controlled by the remote host from the remote network to the GGSN. The PDP context controls the UMTS level QoS between the GGSN and the UE. The QoS in the uplink direction is controlled by the PDP context up to the GGSN. The GGSN configures the DiffServ Edge function to interwork with the backbone IP network and control the IP QoS bearer service towards the remote -host.
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. 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.
(not reproduced yet)
Figure A.7: Local UE provides authorization token in PDP context activation/modification message and GGSN provides interworking with DiffServ
Up

BVoid


Up   Top   ToC