D.1 Resource reservation with end-to-end RSVP

23.2073GPPEnd-to-end Quality of Service (QoS) concept and architectureRelease 17TS

For this case, RSVP is added to the GPRS bearer establishment procedures specified in TS 23.060 [19], with no Service-based local policy.

NOTE 1: The diagrams in this clause depict one possible signalling sequence, however, the alternative signalling sequences below are possible:

– to trigger the Create PDP Context Request message after the PATH message.

– to trigger the Create PDP Context Request message after the RESV message.

– to trigger only one PDP context after all RSVP exchanges have completed.

NOTE 2: The diagrams in this clause depict the case when the GGSN is not RSVP aware, however, the alternative of GGSN being RSVP aware is also possible.

The following figure is applicable to the Mobile Originating (MO) side.

Figure D.1: MO Resource Reservation with End-to-End RSVP

NOTE 3: There is no timing relationship between the set of flows for the uplink (above the line) and the downlink (below the line).

1) The UE sends an Activate (Secondary) PDP Context message to the SGSN with the UMTS QoS parameters.

2) The SGSN sends the corresponding Create PDP Context message to the GGSN.

3) The GGSN authorizes the PDP context activation request according to the local operator’s IP bearer resource based policy, the local operator’s admission control function and the GPRS roaming agreements and sends a Create PDP Context Response message back to the SGSN.

4) RAB setup is done by the RAB Assignment procedure.

5) The SGSN sends an Activate (Secondary) PDP Context Accept message to UE.

6) UE sends an RSVP PATH message to the next hop, through the GGSN. The GGSN does not process the RSVP PATH message. Alternatively, the GGSN may process the RSVP PATH message and forward it to the next hop.

7) The UE receives the RSVP RESV message in the downlink direction, through the GGSN. The GGSN does not process the RSVP RESV message. Alternatively, the GGSN may process the RSVP RESV message and forward it to the UE.

8) The UE sends a RSVP RESV-CONF message to the next hop. The use of the RESV-CONF message is optional.

9) The UE receives a RSVP PATH message in the downlink direction, through the GGSN. The GGSN does not process the RSVP PATH message. Alternatively, the GGSN may process the incoming RSVP PATH message and forward it to the UE.

10) The UE may send a Modify PDP Context message to the SGSN with the necessary modification to UMTS QoS parameters according to the received RSVP PATH message.

11) The SGSN sends the corresponding Update PDP Context Request message to the GGSN.

12) The GGSN authorizes the PDP context modification according to the local operator’s IP bearer resource based policy, the local operator’s admission control function and the GPRS roaming agreements and sends an Update PDP Context Response message back to the SGSN.

13) The radio access bearer modification may be performed by the RAB Assignment procedure.

14) The SGSN sends a Modify PDP Context Accept message to UE.

15) UE sends the RSVP RESV message to the next hop, through the GGSN. The GGSN does not process the RSVP RESV message. Alternatively, the GGSN may process the RSVP RESV message and forward it to the next hop.

16) The UE receives the RSVP RESV-CONF message in the downlink direction. The use of the RESV-CONF message is optional.

The following figure is applicable to the Mobile Terminating (MT) side. As the flow is the mirror of the Mobile Originating (MO) side, the step-by-step description is omitted.

Figure D.2: MT Resource Reservation with End-to-End RSVP

NOTE 4: There is no timing relationship between the set of flows for the uplink (above the line) and the downlink (below the line).