Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 eHRPD Rev A PDN Connection ID discussion Contributors grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or."— Presentation transcript:

1 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. ZTE Rajesh Bi 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 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 (X & X r1) recommend the use of PDN-ID as the PCID for distinguishing multiple PDN connections to the same APN QC proposal (X ) 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 (X ) 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 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 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 # QCOM proposal has significant issues related to scalability of Flow- IDs/TFTs per PDN Connection as well. Further discussions in slide #10-11.

5 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 # ZTE proposal has no issues with the scalability of Flow-IDs/TFTs per PDN Connection. Further discussions in slide slide #10-11.

6 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 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 ; X.P 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 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 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 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 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 1 ZTE Proposal Figure 2 QCOM Proposal PMIP tunnel VoIP flow(SO67) Reservation A10

12 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 13 VSNCP Signaling Aspects VSNCP Signaling for IP Address Allocation/Deallocation

14 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 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 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 1 st PDN connection has been released. Rev A UERev 0 HSGW 1. The 1 st 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 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 18 Scenario #2: Rev 0 UE and Rev A HSGW Rev 0 UE Rev A HSGW 1. The 1 st 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 2 nd PDN connection to APN VSNCP configure request (NAI, APN-1, PDN-ID-2) 6. VSNCP configure Reject

19 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 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 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 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 23 Thanks!


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

Similar presentations


Ads by Google