D.2 Resource Reservation with End-to-End RSVP and Service-based Local Policy

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

For this case, Service-based Local Policy and RSVP are added to the GPRS bearer establishment procedures specified in TS 23.060 [19].

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 RSVP aware, however, the alternative of GGSN not being RSVP aware is also possible.

This clause provides the flows for bearer establishment, resource reservation and policy control with RSVP.

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

Figure D.3: MO Resource Reservation with End-to-End RSVP and Service-based Local Policy

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. The UE includes the Binding Information in the Activate PDP Context message.

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

3) The GGSN sends a COPS REQ message with the Binding Information to the PDF in order to obtain relevant policy information.

4) The PDF sends a COPS DEC message back to the GGSN.

5) The GGSN sends a COPS RPT message back to the PDF.

6) The GGSN maps IP flow based policy information into PDP context based policy information and uses the PDP context based policy information to accept the PDP activation request, and sends a Create PDP Context Response message back to SGSN. The GGSN may cache the policy information.

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

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

9) UE sends a RSVP PATH message to GGSN. The UE includes the Binding Information.

NOTE 4: If the decision was previously cached locally at the GGSN, it may not be necessary to query the PDF again. Otherwise the GGSN may have to query the PDF.

10) The GGSN uses the policy information to accept the RSVP PATH message, and forwards the RSVP PATH message to the next hop.

11) The GGSN receives the RSVP RESV message in the downlink direction.

NOTE 5: If the decision was previously cached locally at the GGSN, it may not be necessary to query the PDF again. Otherwise the GGSN may have to query the PDF.

12) The GGSN uses the policy information to accept the RSVP RESV message, and forwards the RSVP RESV message to the UE.

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

14) The GGSN receives a RSVP PATH message in the downlink direction.

15) The GGSN forwards the RSVP PATH message to the UE.

16) 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. The UE includes the Binding Information in the Modify PDP Context message.

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

NOTE 6: If the decision was previously cached locally at the GGSN, it may not be necessary to query the PDF again. Otherwise the GGSN may have to query the PDF.

18) The GGSN uses the policy information to accept the PDP modification request, and sends a Update PDP Context Response message back to SGSN.

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

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

NOTE 7: Steps 16 to 20 are optional if the existing PDP context already satisfies the QoS requirements.

21) The UE sends a RSVP RESV message to the GGSN. The UE includes the Binding Information in the RSVP RESV message.

NOTE 8: If the decision was previously cached locally at the GGSN, it may not be necessary to query the PDF again. Otherwise the GGSN may have to query the PDF.

22) The GGSN uses the policy information to accept the RSVP RESV message, and forwards the RSVP RESV message to the next hop.

23) 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.4: MT Resource Reservation with End-to-End RSVP and Service-based Local Policy

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

Annex E (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Cat

Subject/Comment

Old

New

2003-09

SP-21

SP-030378

0060

1

B

Functional additions for the Gq interface

5.8.0

6.0.0

2003-12

SP-22

SP-030656

0061

3

B

Procedures in the AF

6.0.0

6.1.0

2003-12

SP-22

SP-030656

0062

1

B

Information exchanged via Gq interface

6.0.0

6.1.0

2003-12

SP-22

SP-030656

0063

1

B

Procedures in the PDF

6.0.0

6.1.0

2003-12

SP-22

SP-030656

0064

D

Editorial corrections to TS 23.207

6.0.0

6.1.0

2004-01

SP-22

SP-030656

0065

2

B

Gq-related updates to the signalling flows

6.0.0

6.1.0

2004-01

SP-22

SP-030656

0066

3

B

Requirements for IM CN Subsystem signalling flag

6.0.0

6.1.0

2004-01

SP-22

SP-030656

0067

F

Definition of the Application Function

6.0.0

6.1.0

2004-03

SP-23

SP-040035

0074

1

B

Update of Authorization on Gq

6.1.1

6.2.0

2004-03

SP-23

SP-040035

0068

1

B

Mapping amendment to PDF procedures

6.1.1

6.2.0

2004-03

SP-23

SP-040035

0069

2

B

Mapping amendment to AF procedures

6.1.1

6.2.0

2004-03

SP-23

SP-040035

0073

1

B

SBLP implications of bundling different IMS sessions to the same PDP Context

6.1.1

6.2.0

2004-03

SP-23

SP-040035

0075

1

B

Service information

6.1.1

6.2.0

2004-06

SP-24

SP-040317

0077

3

B

Authorisation Reject Procedure by the PDF

6.2.0

6.3.0

2004-06

SP-24

SP-040317

0079

1

F

AF capabilities

6.2.0

6.3.0

2004-06

SP-24

SP-040317

0080

2

B

General corrections

6.2.0

6.3.0

2004-06

SP-24

SP-040317

0081

1

F

Intra-domain Gq for IMS

6.2.0

6.3.0

2004-06

SP-24

SP-040317

0083

B

Condition for update authorization procedure

6.2.0

6.3.0

2004-09

SP-25

SP-040521

0084

1

F

SBLP and non-realtime PDP Contexts

6.3.0

6.4.0

2004-09

SP-25

SP-040521

0085

F

Generation of multiple tokens

6.3.0

6.4.0

2005-06

SP-28

SP-050337

0087

F

Update of binding information handling

6.4.0

6.5.0

2005-09

SP-29

SP-050337

0088

1

A

Correction of reference to non-existent/obsolete document

6.5.0

6.6.0

2007-06

SP-36

SP-070392

0092

5

B

Rel-7 version of TS 23.207 main body

6.6.0

7.0.0

2008-12

SP-42

Update to Rel-8 version (MCC)

7.0.0

8.0.0

2009-12

SP-46

Update to Rel-9 version (MCC)

8.0.0

9.0.0

2011-03

SP-51

Update to Rel-10 version (MCC)

9.0.0

10.0.0

2012-09

SP-57

SP-120627

0093

1

F

Reference list correction to align with the corrected TS 29.212 title

10.0.0

11.0.0

2014-09

SP-65

Update to Rel-12 version (MCC)

11.0.0

12.0.0

2015-12

Update to Rel-13 version (MCC)

12.0.0

13.0.0

2017-03

Update to Rel-14 version (MCC)

13.0.0

14.0.0

2018-06

SP-80

Update to Rel-15 version (MCC)

14.0.0

15.0.0

2020-07

SP-88E

Update to Rel-16 version (MCC)

15.0.0

16.0.0

2022-03

SP-95E

Update to Rel-17 version (MCC)

16.0.0

17.0.0