Title:

PCC for cdma2000 1x and HRPD - NW Init Simple IP Call Flow

Abstract:

This contribution proposes Network Initiated Call Flow for Simple IP

Operation

Source:

Rajesh Bhalla / Mao Yuxin

ZTE Corporation
rabhalla@zteusa.com/mao.yuxin@zte.com,cn

Date:

November 02, 2009

Recommendation:

Review and adopt it.

Notice
ZTE Corporation grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other
copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2
publications; to copyright and sell in Organizational Partners name any Organizational Partners standards
publication even though it may include portions of the contribution; and at the Organization Partners sole discretion
to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partners standards
publication. ZTE Corporation is also willing to grant licenses under such contributor copyrights to third parties on
reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partners standard
which incorporates this contribution.
This document has been prepared by ZTE Corporation to assist the development of specifications by 3GPP2. It is
proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the
contributor. ZTE Corporation specifically reserves the right to amend or modify the material contained herein and
nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property
of the contributor other than provided in the copyright statement above.

00 7

Call Flows7

Call Flows

00 7

Call Flows7

Call Flows

00 7.5

Network Initiated QoS Setup for Simple

IP Operation With PCC

Call Flows

7.1

MS Initiated QoS Setup for Simple IP Operation With PCC

7.5 Network Initiated QoS Setup for Simple IP Operation With

PCC
Network initiated QoS setup for Simple IP operations is illustrated in Figure x2 below. QoS
setup is triggered by the PCRF. The PCRF requests QoS resources based on the application
requirements or other policy considerations. Such requests may be granted and established by
the network or modified and deleted depending on the nature of the PCRF request. The
procedures shown include PCRF interactions as described in TS 23.402 [x] and cdma2000 1x
or HRPD specific procedures.
On receiving the PCC Rules Provision message from the PCRF, the PDSN decides that a new
bearer needs to be activated. The PDSN uses the QoS in the PCC Rules Provision message to
assign the bearer QoS, (i.e., it maps PCC QoS parameters to a set of cdma200 1x/HRPD
FlowProfileIDs). The PDSN follows this with the procedure shown in Figure x2 by sending
an RSVP Resv message to the UE.
Once the IP flow(s) with the requested QoS is not needed, the efficiencies at the HRPD air
interface allow that the IP flow(s) associated with the allocated resources may be stopped.
However the allocated resources are not torn down in anticipation of being used again. If the
resources allocated for the IP flow(s) are no longer needed the network may trigger a
complete release of the HRPD resources associated with the flow (e.g., RLP and auxiliary
A10).

00 7

Call Flows7

Call Flows

00 7

Call Flows7

Call Flows

00 7.5

Network Initiated QoS Setup for Simple

IP Operation With PCC

00 7

Call Flows7

Call Flows

Figure 1

Network Initiated QoS Setup for Simple IP Operation with PCC

Both roaming and non-roaming scenarios are depicted in Figure x2. In the roaming case, the
vPCRF acts as an intermediary, sending the PCC Rules Provision from the hPCRF in the home
domain to the PDSN in the visited domain. The vPCRF receives the Acknowledgment from the
PDSN and forwards it to the hPCRF. In the non-roaming case, the vPCRF is not involved.
1.

The Main Service Connection is setup.

2.

PPP LCP negotiation occurs and authentication protocol is selected.

3.

User authentication and authorization is performed using the selected authentication

protocol. The MS exchanges authentication related messages with the PDSN. In turn, the
PDSN performs user authentication and authorization with the AAA using RADIUS
Access Request/Accept messages. On successful authorization, information such as
Subscriber QoS Profile and Subscriber IP-CAN Bearer Mode is returned to the PDSN in
RADIUS Access Accept message.

4.

The PDSN passes the relevant attributes received in Subscriber QoS Profile to the RAN.

5.

The MS and the PDSN perform IPCP procedures for the allocation on an IP address. An
IP address is assigned to the MS as per Simple IP address assignment procedures.

Note: Based on Subscriber IP-CAN Bearer Mode received from the AAA, and the MS/PDSN
Bearer Mode capabilities determined by Version/Capability Packet exchange, the PDSN chooses
the IP-CAN Bearer Establishment Mode.
6.

The PDSN/PCEF determines that an IP-CAN session needs to be established for the MS
and initiates IP-CAN Bearer Session Establishment procedures with the PCRF. The
PDSN/PCEF includes the following information in the IP-CAN Bearer Establishment
message: UE Identity (e.g. MN NAI), PDN identifier (domain name or <tbd>), IP-CANType and the IP address(es), and if available, the default charging method and the chosen
IP-CAN Bearer Establishment Mode. Subscription related information received from the
AAA during authorization process is also passed to the PCRF. Information passed to the
PCRF includes: allowed service(s), PCC Rules info, subscribed QoS Profile etc - others
TBD).

7.

The PCRF establishes an IP-CAN session for the MS and the stores subscribers
subscription related information and chosen IP-CAN Bearer Establishment Mode
received from the PDSN/PCEF. The PDN identifier, IP address(es) and UE identity
enable identification of the IP-CAN session.

8.

The PCRF sends an Acknowledge of IP-CAN Session Establishment to the PDSN/PCEF.

The PCRF may provide the default charging method and may include the following
information: PCC Rules to activate and Event Triggers to report. Policy and Charging
Rules allow enforcement of the policy associated with the IP-CAN session. Event
Triggers indicate to the PCEF what events must be reported to the PCRF.

Note: In the PCC framework, the PCRF may interact with the SPR for subscriber subscription
related information. The PCRF provides the subscriber ID, and PDN-ID to the SPR. The PCRF
may also request notifications from the SPR on the changes in subscription information. Such
PCRFSPR interactions may be performed in addition to the PCRF receiving subscription related
information from the PDSN/PCRF. Support of such PCRF interactions with the SPR is <tbd>.
9.

As a result of interactions with the Application Function or otherwise, the PCRF becomes
aware of IP flow(s) that needs a specific QoS.

10. The PCRF sends Policy and Charging Rules Provision (PCC Rules, Event Triggers,
Event Report) to the PDSN/PCRF.

00 7

Call Flows7

Call Flows

00 7.5

Network Initiated QoS Setup for Simple

IP Operation With PCC

11. The PDSN uses the received QoS policy information in the PCC Rules to determine the
bearer level QoS parameters required for the cdma2000 1x/HRPD bearer. The PDSN
maps these parameters to the appropriate FlowProfileID(s)
12. The PDSN/PCEF sends Acknowledge PCC Rules Provision (accept or reject of the PCC
rule operation(s) to the PCRF.
Note: Whether the PDSN/PCRF returns Ack PCC Rules Provision at this stage or waits till
the completion of the QoS bearer setup on the cdma2000 1x/HRPD (Step 19) is TDB.
13. The PDSN sends an RSVP Resv message transported over the main service connection to
the MS. The RSVP message includes the UL/DL packet filter(s), QoS list, and a
Transaction ID.
14. The MS performs standard QoS establishment procedures defined in C.S0024 [x] and in
C.S0063 [x]. There are two possible sequences that can occur at this step. If a new QoS
link flow connection is needed to carry the new flow over the air interface, then the RAN
will setup a new air interface link flow. If the RAN decides to carry the flow(s) on an
existing link flow, it then reconfigures the parameters of that link flow.
15. If a new link flow is needed, a new A10 connection is also established. The RAN/PCF
sends an A11-Registration Request message to the PDSN indicating the GRE key, the
Requested QoS information, and the Granted QoS information for the flow. The Granted
QoS information includes the FLOW_ID. If a new QoS link flow is not needed, the
RAN/PCF sends an A11-Registration Request message to the PDSN indicating the GRE
key, FLOW_ID, and the modified Granted QoS information for the existing connection
(if required).
16. The MS sends an RSVP Resv message to the PDSN. The message includes the Flow ID
for the bearer connection, and the same DL/UL TFT and Transaction ID received in step
13. This message can be sent in parallel with the start of the signaling in Step 14. The
Transaction ID is used to associate the returned Flow ID with the new bearer connection.
This message is also used as an acknowledgement to the RSVP Resv message in Step 13.
The PDSN examines the QoS granted to the UE and compares it to the QoS authorized
for the UE in Step 3. If there is a discrepancy, the PDSN applies operator policy, for
example remove the flow or shut off all activity for the MS.
17. The PDSN acknowledges the delivery of the RSVP Resv message it received in Step 16
by sending a ResvConf message to the MS.
18. Since by default the Reservation for the newly created bearer is in the Closed state, the
MS (or RAN) may trigger the transition to the Open state.
19. Once the air interface reservation is transitioned to the Open state, the RAN triggers an
A11-Registration Request (Active Start) message to initiate legacy accounting for this
bearer connection.
20. The PDSN sends an Accounting Request (Start) message to the RADIUS server.
Note: It may be noted that though PCC accounting procedures are used, such RADIUS
Accounting Start (Start/Stop) messages are needed to maintain the state information in the
RADIUS AAA servers.
21. At this stage the user/application IP packets flow between the MS and the peer node. The
bearers on the cdma2000 1x/HRPD network support flow of such packets per the
requested QoS.
22. As a result of interactions with the Application Function or otherwise, the PCRF becomes
aware that IP flow(s) with the specific QoS is not needed.
23. The PCRF sends Policy and Charging Rules Provision (PCC Rules, Event Triggers,
Event Report) to the PDSN/PCRF.

00 7

Call Flows7

Call Flows

24. The PDSN uses the received QoS Policy information in the PCC Rules to determine the
bearer level QoS parameters required for the cdma2000 1x/HRPD bearer. The PDSN
sends an RSVP Resv message to the MS with OpCode set to Initiate Delete Packet Filter
from Existing TFT indicating deletion of the QoS bearer.
25. The MS performs standard HRPD procedures to reconfigure the air interface in order to
remove or modify the requested Reservation(s). If the last Reservation(s) associated with
the link flow is removed, the link flow itself is also removed.
26. The RAN/PCF sends and A11-Registration Request message to the PDSN with Active
Stop indication to inform the PDSN of the idle state of the IP flow(s) associated with the
Flow-ID.
27. The PDSN sends an Accounting Request (Stop) message to the RADIUS server.
28. The PDSN acknowledges the A11-RRQ message with A11-RRP message.
29. The RAN/PCF and the PDSN maintain the A10 connection used for the QoS bearer. This
bearer may be reused later for the same IP flow, e.g., from another VoIP call to the same
IP address on the MS. Such reuse would involve only the setting of the radio reservation
state to the ON state, and the sending of the Active Start Airlink Records to the PDSN.
30. The MS sends a RSVP Resv message with OpCode set to Initiate Delete Packet Filter
from Existing TFT to indicate to the PDSN which flows have been removed. The TFT
IE contains the list of flow identifiers for which filters have been deleted. The
Transaction ID carried in this message shall be the same as the Transaction ID carried in
the Resv message in step 24. This message is also used as an acknowledgement to the
RSVP Resv message in Step 24. This message may be sent any time after Step 25.
31. The PDSN acknowledges a successful update of the IP flow mapping information by
sending a ResvConf message to the MS.
32. The PDSN/PCEF sends Acknowledge PCC Rules Provision (accept or reject of the PCC
rule operation(s) to the PCRF.
Note: Whether the PDSN/PCRF returns Ack PCC Rules Provision at this stage or sends it
anytime after Step 24 is TDB.

00 7

Call Flows7

Call Flows

00 7.5

Network Initiated QoS Setup for Simple

IP Operation With PCC