eHRPD Rev A PDN Connection
ID discussion
ZTE
Rajesh Bhalla
rabhalla@zteusa.com
Bi YiFeng
Bi.yifeng@zte.com.cn
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
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.
1
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 UserContext-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.
2
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
3
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 FlowIDs/TFTs per PDN Connection as well. Further discussions in slide #10-11. 4
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.
5
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
6
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.
7
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 !!
8
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
9
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).
10
Problem Illustration for VoIP Calls
with QCOM Proposal
P-GW
P-GW
HSGW
HSGW
eAN/ePCF
eAN/ePCF
UE
Figure 1
ZTE Proposal
Reservation
A10
UE
Figure 2
QCOM Proposal
PMIP tunnel
VoIP
flow(SO67)
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 PDNID 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
11
meet SO67 requirements.
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
12
VSNCP Signaling Aspects
• VSNCP Signaling for IP Address Allocation/Deallocation
13
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
14
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
15
Scenario #1: Rev A UE and Rev 0 HSGW
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
1.
2.
3.
4.
Rev A UE(NAI) has established 1st PDN connection to APN-1, which uses PDN-ID-1 in
VSNCP/VSNP messages.
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.
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.
After the UE receives the error code=11, it knows that the HSGW does not support
16
MUPSAP, and will not request another PDN connection establishment to APN-1 until
the 1st PDN connection has been released.
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.
17
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)
2. UE initiates 2nd PDN
connection to APN-1.
3. VSNCP configure request (NAI, APN-1, PDN-ID-2)
4. VSNCP configure Ack
5. VSNCP configure request (NAI, APN-1, PDN-ID-2)
6. VSNCP configure Reject
7. HSGW gets to know that
the UE doesn’t support
MUPSAP
18
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.
If (just if) the Rev 0 UE sends another VSNCP configure request (NAI, APN-1, PDN-ID2) to HSGW(Rev A) to initiate 2nd PDN connection to APN-1:
2.
1.
2.
3.
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.
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.
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.
19
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
20
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
21
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
22
Thanks!
23