Content for TS 23.207 Word version: 17.0.0
6 End-to-End QoS Procedures
6.1 QoS Procedures in Functional Elements
6.2 IP Bearer Level / Application Level Binding Mechanism
6.3 Session Flow: QoS Interaction Procedures
6.4 PDP Context Used for Application Level Signalling Transport
...
...
6 End-to-End QoS Procedures p. 15
6.1 QoS Procedures in Functional Elements p. 15
This clause describes the main procedures that are used for the end-to-end QoS management. These procedures are described in text description for each involved network elements. The procedures described in this document are meant to provide a high level description for further Stage 3 work and are not intended to be exhaustive.
6.1.1 Procedures in the GGSN p. 15
The QoS procedures in the GGSN are triggered by the QoS signalling messages from the UE or unsolicited provisioning of PCC rules from the PCRF. The exact QoS procedures in the GGSN depend on the GGSN and UE QoS capabilities. The GGSN is required to support DiffServ edge function. Other QoS capabilities that may be supported at the GGSN are RSVP functions and policy enforcement functions.
For UEs that do not support RSVP, the GGSN may use the PDP context level information to configure the DiffServ edge functionality and provide internetworking between PDP context and backbone IP network. The authorization token is included in the PDP context activation/modification messages.
For UEs that support RSVP, the GGSN may also support RSVP and use RSVP rather than the PDP context to control the QoS through the backbone IP network. The authorization token may be included in the RSVP signalling and the PDP context activation/modification messages. Alternatively, the RSVP messages may pass transparently through the GGSN.
For details on PCC functionality in GGSN, see TS 23.203.
6.1.2 Procedures in the UE p. 15
The QoS procedures in the UE are triggered by the application layer (e.g., SIP/SDP) QoS requirements or initiated by the network. The exact QoS procedures in the UE depend on the UE QoS capabilities.
For UEs that support only UMTS QoS mechanism, the network or the application QoS requirements will trigger a PDP Context Activation procedure with the corresponding UMTS QoS parameters. For UEs that support both IP (e.g., IP BS Manager) and UMTS QoS mechanism, the application QoS requirements are mapped down to the IP layer QoS parameters. The IP layer parameters are further mapped down to the PDP context parameters in the UE. For UEs that support RSVP, the application QoS requirements are mapped down to create an RSVP session. The UE shall establish a PDP context suitable for support of the RSVP session.
At the AF session release, the UE shall release all QoS resources allocated for the AF session.
For details on PCC functionality in the UE, see TS 23.203.
6.1.3 Void
6.1.3a Procedures in the PCRF p. 16
The QoS procedures at the PCRF are triggered by the IP-CAN session establishment as reported from a PCEF and, for an active IP-CAN session, IP-CAN session modification or service information from an AF.
When the PCRF receives service information from the AF, the PCRF authorizes the QoS resources or rejects the service information received from the AF. If the PCRF rejects the authorization request, the PCRF may indicate in the response to the AF the service information that could be accepted by the PCRF.
As part of the authorization, the PCRF shall perform the mapping from the service information conveyed over the Rx interface to the Authorized QoS sent over the Gx interface.
The authorized QoS is either pushed to or requested by the GGSN via the Gx interface.
The PCRF makes a final decision to enable the allocated QoS resource for the authorized IP flows. This may be triggered by an instruction from the AF. QoS resources may also be enabled at the time they are authorized by the PCRF.
When the AF receives updated session description information, the AF may send an update for service information to the PCRF. The PCRF decides if a new QoS authorization is needed and updates the authorization for the session accordingly. If the PCRF does not accept the service information received from the AF, the PCRF rejects the update for service information. The PCRF may indicate in the response to the AF the service information that could be accepted by the PCRF.
The PCRF revokes the resource authorization based on request from the AF.
For details on the PCC functionality in the PCRF, see TS 23.203.
6.1.4 Procedures in the AF p. 16
The AF communicates with the PCRF to transfer dynamic session information, required for PCRF decisions as well as to receive information and notifications about IP transmission resource level events.
The AF contacts the PCRF when it receives an AF session signalling message initiating a new AF session:
- The AF contacts the PCRF that is responsible for the UE.
- The AF generates the information (e.g. service information) conveyed over the Rx interface from the application specific media description (e.g. SDP media description).
- The PCRF uses the service information for the QoS policy set up for the AF session. During an AF session change, the AF sends an update for service information to the PCRF based on the new session description information exchanged within AF session signalling.
6.2 IP Bearer Level / Application Level Binding Mechanism p. 17
See TS 23.203.
6.3 Session Flow: QoS Interaction Procedures p. 17
This clause highlights possible additions to the GPRS bearer establishment procedures specified in TS 23.060 for support of Policy and Charging Control (PCC). These additional procedures are utilized to provide Policy and Charging Control for session-based services, e.g. for IMS as described in clause 5 of TS 23.228.
For IMS where PCC is not used, the related procedures defined in TS 23.228 are not applied.
Detailed specification of the additional procedures are given in TS 23.203.
It shall be possible according to operator choice to use solely the GPRS bearer establishment procedures specified in TS 23.060 without these additions.
6.3.1 Void
6.3.2 Resource Reservation Message Flows p. 17
6.3.2.1 Void
6.3.2.2 Resource Reservation with IP QoS signalling p. 17
6.3.2.3 Resource Reservation with IP QoS reservation signalling and Service-based Local Policy p. 17
6.3.2.4 Void
6.3.3 Void
6.3.4 Void
6.3.5 Void
6.3.6 Void
6.3.6a Void
6.3.7 Void
6.3.8 Void
6.4 PDP Context Used for Application Level Signalling Transport p. 18
To establish a PDP context for application level signalling, the UE shall be able to include a signalling flag in PDP context activation procedure. This indicates to the network the intention of using the PDP context for application level signalling. The only defined application level signalling flag in this release is the IM CN subsystem signalling flag. However, the network may also support other mechanisms that cater for identifying application level signalling flows within a PDP context, as described in clause 4.2.6 of TS 23.228.
To establish a PDP context for application level signalling with prioritised handling over the radio interface, the UE shall be able to set the Signalling Indication in the QoS IE in the PDP context activation procedure. The Signalling indication in the QoS IE indicates to the radio and core networks the requirement for enhanced handling over the radio interface, once it has been negotiated with the networks.
A request for a general purpose PDP context having the "signalling indication" within the QoS IE may be accepted or downgraded according to operator policy configured at the GGSN using the usual QoS negotiation mechanisms described in TS 23.060.
In the case of IMS, the IM CN Signalling Flag in the PCO IE is used to reference rules and restrictions on the PDP context used for application level signalling, as described in clause 4.2.6 of TS 23.228.
The IM CN Signalling Flag and the Signalling indication in the QoS profile detailed in TS 23.107 may be used independently of each other.
Based on operator policy the "Signalling Indication" in the QoS IE may be allowed only if the "IM CN Subsystem Signalling" flag is present in the PCO IE.
