1 eHRPD Rev A PDN Connection ID discussion Contributors grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or.

1

eHRPD Rev A PDN Connection ID discussion

Contributors 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 Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors 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 Partner’s standard which incorporates this contribution.This document has been prepared by Contributors 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. Contributors 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.

ZTERajesh Bhalla [email protected]

Bi YiFeng [email protected]

ABSTRACT: ZTE proposed the use of PDN-ID as the PCID for distinguishing multiple PDN connections to the same APN in eHRPD system. Qualcomm proposal is to add another configuration option (User-Context-ID) in VSNCP message(s) for distinguishing multiple PDN Connections to the same APN. This ZTE contribution highlights deficiencies of Qualcomm proposal and reiterates ZTE proposal to use PDN-ID as the PCID.

Recommendation: Review and Approve

2

Background• This contribution relates to the support of MUPSAP Note 1 (Multiple PDN

Connections to the Same APN for PMIP-based Interfaces) in X.P0057-A• ZTE proposals (X50-20091207-20 & X50-20100301-038r1) recommend the use of

PDN-ID as the PCID for distinguishing multiple PDN connections to the same APN

• QC proposal (X50-20100301-18) proposes to use another VSNCP configuration option (User-Context-ID) to distinguish multiple PDN connections to the same APN identified by PDN-ID

• Another QC proposal (X50-20100426-012) analyzes how the use of User-Context-ID as PCID resolves functionality related to:

– Signaling for IP address allocation– Routing of Packets– QoS

• This contribution highlights significant functionality related to QoS that cannot be resolved by the use of QC proposed User-Context-ID; hence reiterates the use of PDN-ID as the PCID

• In fact, ZTE proposal to use PDN-ID as PCID addresses all functionality related to:– Signaling for IP address allocation– Routing of Packets– QoS

Note 1: The real short name of “Multiple PDN Connections to the Same APN for PMIP-based Interfaces” is MUPSAP but not MAPSUP. But during the R9 phase in 3GPP, the MAPSUP and MUPSAP were used in a confusion, because of that, in the first contribution of this feature in 3GPP2, the wrong name was copied. Now ZTE proposes to correct it as MUPSAP.

3

Some MUPSAP Aspects

• MUPSAP allows multiple PDN connections to an APN by the same UE

• Single Authentication based on MS-ID/NAI between the UE and the AAA is performed

• Multiple PDN Connection requests (to an APN) may be generated by different applications on the same UE or by different TEs that are connected to the UE– For the sake of clarity and discussions, QC proposal introduces the term

‘Ux’ to identify the PDN Connection for such an application(x) or TE(x): however there is no proposal to standardized the term Ux

• A separate VSNCP context is setup for each PDN connection for the allocation/deallocation of IP addresses for each Ux PDN Connection– The same NAI is used for all PDN connections for the UE

4

Highlights of QCOM Proposal

• Proposes a 4-bit VSNCP Configuration Option (User-Context-ID) to distinguish different PDN Connections for an APN identified by PDN-ID

– For VSNCP signaling (PDN-ID + User-Context-ID) together identify an PDN Connection for a Ux

– HSGW maps User-Context-ID to PCID to be used over S2a interface. Such PCID is also used for IP-CAN and Gateway Control sessions

• For the routing of packets between the UE and the HSGW: packets for a single APN (identified by PDN-ID) and multiple PDN Connections are routed over a service connection with the required QoS characteristics (hence the same air link flow/RLP) identified by PDN-ID

– Works for BE packet flows – for auxiliary connections for SO64 (HDLC based framing) SO72 (packet based framing) and the main service connection (SO59)

– Potential issue with non-BE packet flows: non-BE packet flows for all PDN Connections for an APN with similar QoS characteristics are routed over the same service connection (hence over the same air link flow/RLP between the UE and the eAN) !!

– Issue with VoIP calls (SO67). Further discussions in Slide #10-11.

• QCOM proposal has significant issues related to scalability of Flow-IDs/TFTs per PDN Connection as well. Further discussions in slide #10-11.

5

Highlights of ZTE Proposal• Proposes to use the 4-bit PDN-ID configuration option to distinguish different

PDN Connections for an APN– For VSNCP signaling PDN-IDx identifies a PDN Connection for a Ux– HSGW maps PDN-IDx to PCIDx to be used over S2a interface. Such PCID is also

used for IP-CAN and Gateway Control sessions

• For the routing of packets between the UE and the HSGW: packets for a PDN Connection (identified by PDN-IDx) are routed over a service connection (hence an air link flow/RLP) with the required QoS characteristics

– Works for BE packet flows - for auxiliary connections for SO64 (HDLC based framing) SO72 (packet based framing) and the main service connection (SO 59)

– Works for non-BE packet flows as well as per QoS characteristics: Each non-BE packet flow for each PDN Connection for an APN receives the required QoS between the UE and the HSGW. Depending on the QoS characteristics for a packet flow:

• The packet flow can be routed together with the packet flow(s) for other PDN Connections with similar QoS characteristics over PDN-Mux service connection

• OR the packet flow can be routed over an individual/dedicated service connection (hence an individual air link flow between the UE and the eAN).

– Such capability is important for VoIP calls (SO67). Further discussion in Slide #10-11.

• ZTE proposal has no issues with the scalability of Flow-IDs/TFTs per PDN Connection. Further discussions in slide slide #10-11.

6

QoS Aspects

• MUPSAP solution needs to minimally address the following QoS related functionality:– Procedures for add/delete of TFTs between the UE and

the HSGW for each Ux• A scalable RSVP solution between the UE and HSGW for

each Ux

– QoS characteristics based routing of packets between the UE and the HSGW for each PDN Connection (Ux)

– Differentiation of multiple PDN Connections for an APN for the same UE for IP-CAN and Gateway Control session procedures

7

Add/Delete of TFTs for Each Ux

• RSVP signaling for add/delete of TFTs uses Packet Filter List and QoS List

• TFTs in the Packet Filter List and the QoS List are identified by Flow Identifier(x)– Flow Identifier is an 8-bit field– The Flow Identifier in the packet filter list is set as

follows (ref. section 10.1.6.7.1; X.P0057-0 v2.0)• The upper 4 bits of Flow Identifier include the PDN-ID. • The lower 4 bits of Flow Identifier identify each reservation

(packet flow) that is requested to be added or deleted.

8

RSVP Signaling in QCOM Proposal

• Upper 4-bits of Flow Identifier (Flow-ID) identifies an APN (PDN-ID)• For each APN (PDN-ID) the lower 4-bits identify individual

flows/TFTs• 16 (sixteen) flows/TFTs per APN (PDN-ID) are supported

– For Rev-0: only single PDN Connection per APN • Hence 16 flows (TFTs) for a single PDN Connection are deemed to be meet

operator requirements– For Rev-A: SA2 recommends the use of LBI (4-bits /max:11) to distinguish

multiple PDN connections to the same APN• Per QCOM proposal, all such PDN-Connections (up to max:11) use the same PDN-ID• Hence a max. of 16 flows (TFTs) can be supported for ALL PDN Connections to an

APN (identified by PDN-ID)• Works out to be approx. one TFT for each PDN Connection/IP Address allocated

• Conclusion:– QCOM proposal is NOT scalable for supporting a reasonable number of TFTs for

each PDN Connection • Rev-0: determined up to 16 TFTs for each PDN connection deemed to meet operator

requirements• Is it reasonable to have only one TFT or each PDN Connection for Rev:A• WILL IT WORK !!

9

RSVP Signaling in ZTE Proposal

• Upper 4-bits in Flow Identifier (Flow-ID) identifies a PDN Connection• For each PDN Connection the lower 4-bits identify individual

flows/TFTs• 16 (sixteen) flows/TFTs per PDN Connection (PDN-IDx) are

supported– For Rev-0: only single PDN Connection per APN

• Hence 16 flows (TFTs) for a single PDN Connection are deemed to be meet operator requirements

– For Rev-A: SA2 recommends the use of LBI (4-bits /max:11) to distinguish multiple PDN connections to the same APN

• Per ZTE proposal: all such PDN-Connections (up to max:11) use the different PDN-IDx• Hence a max. of 16 flows (TFTs) can be supported for each PDN Connection to an

APN

• Conclusion:– ZTE proposal IS scalable for supporting a reasonable number of TFTs for each

PDN Connection • Rev-0: determined up to 16 TFTs for each PDN connection deemed to meet operator

requirements• Rev-A: ZTE proposal allows similar number of TFTs per PDN Connection as those

allowed for Rev-0

10

Routing of Packets Between UE and HSGW for each Ux

• QCOM Proposal– For the routing of packets between the UE and the HSGW: packets for a single

APN (identified by PDN-ID) and multiple PDN Connections are routed over a service connection with the required QoS characteristics (hence the same air link flow/RLP) identified by PDN-ID

• Works for BE packet flows – for auxiliary connections for SO64 (HDLC based framing) SO72 (packet based framing) and the main service connection (SO59)

• Potential issue with non-BE packet flows: non-BE packet flows for all PDN Connections for an APN with similar QoS characteristics are routed over the same service connection (hence over the same air link flow/RLP between the UE and the eAN) !!

• ZTE Proposal– For the routing of packets between the UE and the HSGW: packets for a PDN

Connection (identified by PDN-IDx) are routed over a service connection (hence an air link flow/RLP) with the required QoS characteristics

– Works for BE packet flows - for auxiliary connections for SO64 (HDLC based framing) SO72 (packet based framing) and the main service connection (SO 59)

– Works for non-BE packet flows as well as per QoS characteristics: Each non-BE packet flow for each PDN Connection for an APN receives the required QoS between the UE and the HSGW. Depending on the QoS characteristics for a packet flow:

• The packet flow can be routed together with the packet flow(s) for other PDN Connections with similar QoS characteristics over PDN-Mux service connection

• OR the packet flow can be routed over an individual/dedicated service connection (hence an individual air link flow between the UE and the eAN).

11

Problem Illustration for VoIP Calls with QCOM Proposal

HSGW

UE

P-GW

eAN/ePCF

HSGW

UE

P-GW

eAN/ePCF

ZTE Proposal: For different PDN-IDs for the multiple PDN connections to the same APN, VoIP flows with the similar QoS characteristics for different PDN connections use different Reservations/Service Connections (Figure 1) – per SO67 requirements.

QCOM Proposal: For the same PDN-ID for multiple PDN connections to an APN, VoIP flows with similar QoS characteristics from different PDN connections for an APN are routed over the same Reservation/Service connection (Figure 2) – does not meet SO67 requirements.

Figure 1ZTE Proposal

Figure 2QCOM Proposal

PMIP tunnelVoIP flow(SO67)

ReservationA10

12

Conclusion on QoS Aspects

• RSVP signaling for add/delete of TFTs uses Packet Filter List and QoS List– QCOM proposal for Rev-A is not scalable

• Does not support enough TFTs for each PDN Connection for an APN(on average: only one TFT per PDN Connection supported)

– ZTE proposal for Rev-A is scalable• Supports as many TFTs per PDN connection for an APN as are

supported for Rev-0

• Routing of packet flows between UE and HSGW– QCOM proposal has issues with non-BE packet flows for PDN

Connections for an APN that require separate service connections even for similar QoS characteristics (viz. SO67 flows)

– ZTE proposal handles non-BE packet flows for different PDN Connections for an APN as per service requirements

13

VSNCP Signaling Aspects

• VSNCP Signaling for IP Address Allocation/Deallocation

14

VSNCP Signaling for Address Allocation/Deallocation

• Highlights of QCOM Proposal:– Proposes a 4-bit VSNCP Configuration Option (User-Context-ID)

to distinguish different PDN Connections for an APN identified by PDN-ID

• For VSNCP signaling (PDN-ID + User-Context-ID) together identify an PDN Connection for a Ux

• HSGW maps User-Context-ID to PCID to be used over S2a interface. Such PCID is also used for IP-CAN and Gateway Control sessions

• Highlights of ZTE Proposal:– Proposes to use the 4-bit PDN-ID configuration option to

distinguish different PDN Connections for an APN• For VSNCP signaling PDN-IDx identifies a PDN Connection for a Ux• HSGW maps PDN-IDx to PCIDx to be used over S2a interface.

Such PCID is also used for IP-CAN and Gateway Control sessions

15

ZTE Proposal for VSNCP Signaling

• Need to ensure compatibility between any mix of Rev-0 and Rev-A UEs and HSGWs

• Minimizes changes at the UE for supporting MUPSAP

• Illustration for the following scenarios:– Scenario #1: Rev A UE and Rev 0 HSGW– Scenario #2: Rev 0 UE and Rev A HSGW

16

Scenario #1: Rev A UE and Rev 0 HSGW

1. Rev A UE(NAI) has established 1st PDN connection to APN-1, which uses PDN-ID-1 in VSNCP/VSNP messages.

2. Rev A UE(NAI) sends a VSNCP configure request (NAI, APN-1, PDN-ID-2) to HSGW(Rev 0) to initiate 2nd PDN connection to APN-1 since the UE does not know whether the HSGW supports MUPSAP or not, and UE assumes that the HSGW does.

3. After the HSGW receives the “VSNCP configure request” from the UE, it rejects this request with “error code=11: PDN connection already exists for this APN” to the UE since the HSGW does not support MUPSAP.

4. After the UE receives the error code=11, it knows that the HSGW does not support MUPSAP, and will not request another PDN connection establishment to APN-1 until the 1st PDN connection has been released.

Rev A UE Rev 0 HSGW

1. The 1st PDN connection to APN-1(PDN-ID-1)

2. VSNCP configure request (NAI, APN-1, PDN-ID-2)

3. VSNCP configure Reject (error code=11)

4. UE gets to know that the HSGW doesn’t support MUPSAP

17

Conclusion for Scenario #1

• Even though a Rev-A UE can send “multiple PDN connection requests for the same APN” to a Rev-0 HSGW, Rev-0 HSGW can reject such requests by using existing messages and error-codes

• So this is not an issue.

18

Scenario #2: Rev 0 UE and Rev A HSGW

Rev 0 UE Rev A HSGW

1. The 1st PDN connection to APN-1(PDN-ID-1)

3. VSNCP configure request (NAI, APN-1, PDN-ID-2)

4. VSNCP configure Ack

7. HSGW gets to know that the UE doesn’t support MUPSAP

2. UE initiates 2nd PDN connection to APN-1.

5. VSNCP configure request (NAI, APN-1, PDN-ID-2)

6. VSNCP configure Reject

19

Procedure Description for Scenario #2

1. The Rev 0 UE(NAI) has established 1st PDN connection to APN-1, which uses PDN-ID-1 in VSNCP/VSNP messages.

2. If (just if) the Rev 0 UE sends another VSNCP configure request (NAI, APN-1, PDN-ID-2) to HSGW(Rev A) to initiate 2nd PDN connection to APN-1:

1. On receiving second “VSNCP configure request” from the UE, the HSGW will execute normal procedures for the MUPSAP case, viz. return “VSNCP configure ack” and perform PMIP binding, PCC session setup etc.

2. The HSGW will also a send “VSNCP configure request” message to the UE to complete VSNCP negotiations. On receiving such “VSNCP configure request” message for a second PDN connection to the same APN, the UE will reject the request.

3. After the HSGW receives the reject message, it will get to know that the UE does not support MUPSAP, and will tear down all the session related to the second PDN connection (if such connection exist).

Conclusion:

Even though a Rev 0 UE can send “multiple PDN connection requests to the same APN” to a Rev-A HSGW, such anomalies are corrected via the existing VSNCP negotiation procedures.

20

Possible Enhancement to ZTE Proposal

• ZTE proposal for Rev-A MUPSAP VSNCP procedures is based on the overloading of VSNCP Error Code: 11 (PDN connection already exists for this APN)

• In case the operator requirements are to preserve backward compatibility of the Error Code:11 functionality in Rev-A as well: – That can be accomplished by the use of

Version/Capability IP Packet exchanged between the UE and the HSGW for communicating their respective version support

21

Routing Requirements• Routing of Packets

– Routing between HSGW and P-GW– Routing between UE and HSGW– Routing between UE and Ux– Routing over S-103 interface

• Highlights of QCOM Proposal:– Proposes a 4-bit VSNCP Configuration Option (User-Context-ID) to

distinguish different PDN Connections for an APN identified by PDN-ID• HSGW maps User-Context-ID to PCID to be used over S2a interface. Such

PCID is also used for IP-CAN and Gateway Control sessions• Highlights of ZTE Proposal:

– Proposes to use the 4-bit PDN-ID configuration option to distinguish different PDN Connections for an APN

• HSGW maps PDN-IDx to PCIDx to be used over S2a interface. Such PCID is also used for IP-CAN and Gateway Control sessions

• Both proposals are similar for routing aspects

22

Conclusion and Recommendations

• Two proposals under consideration:– QCOM: User-Context-ID configuration based– ZTE: PDN-IDx for each PDN Connection for an APN

• Both proposals meet VSNCP signaling and Routing requirements

• QCOM proposal has limitations in meeting QoS requirements similar to Rev-0

• ZTE proposal meets QoS requirements similar to Rev-0• Recommendations:

– Adopt ZTE solution for using PDN-ID as the PCID when MUPSAP is used

23

Thanks!