Network Working Group T. Melia
Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Informational C. Bernardos
Expires: January 6, 2010 Universidad Carlos III de Madrid
JC. Zuniga
InterDigital Communications, LLC
July 5, 2009
3GPP MN-AR interface
draft-melia-netext-3gpp-mn-ar-if-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Melia, et al. Expires January 6, 2010 [Page 1]
Internet-Draft 3GPP MN-AR interface July 2009
Abstract
This ID documents the interface between the Mobile Node and the
Mobility Access Gateway in the context of 3GPP Evolved Packet Core
networks. The main goal is to support the Netext working group in
the discussions on the MN to AR interface showing how RFC 5213 has
been deployed by other SDOs. This document has been inspired by
considerations expressed in
[I-D.gundavelli-netext-extensions-motivation].
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Differences between 3GPP and IETF specifications . . . . . . . 5
4. Reference point S5 . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Network attachment . . . . . . . . . . . . . . . . . . . . 5
4.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 6
5. Reference point S2a . . . . . . . . . . . . . . . . . . . . . 7
5.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 7
5.2. Network detachment . . . . . . . . . . . . . . . . . . . . 8
6. Reference point S2b . . . . . . . . . . . . . . . . . . . . . 9
6.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 9
6.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 10
7. Common aspects in Handover Management procedures . . . . . . . 10
8. Multiple Interfaces support . . . . . . . . . . . . . . . . . 11
9. General Considerations . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Melia, et al. Expires January 6, 2010 [Page 2]
Internet-Draft 3GPP MN-AR interface July 2009
1. Terminology
This document uses the following terminology:
PDN Packet Data Network
EPS Evolved Packet System
EPC Evolved Packet Core
S-GW Serving Gateway
P-GW PDN Gateway
UE User Equipment
GTP GPRS Tunneling Protocol
APN Access Point Name
2. Introduction
The 3GPP standardization body specified the Evolved Packet System
(EPS) architecture (release 8). EPS relies on a fully IP-based core
network, the Evolved Packet Core (EPC), and provides heterogeneous
wireless access to multi mode mobile devices. EPC supports different
type of wireless access networks, namely the evolved UTRAN (i.e.
LTE), a trusted non-3GPP access (i.e. WIMAX) and a non-trusted and
non-3GPP access (i.e. WIFI).
Melia, et al. Expires January 6, 2010 [Page 3]
Internet-Draft 3GPP MN-AR interface July 2009
_.----------.
,-'' `--.
/ +-------+
( EUTRAN | S-GW |\\
\ ACCESS +-------+ \\
`--. _.-' \\ S5 interface
`----------'' \\
\\
_.----------. \\
,-'' `--. \\
/ +-------+ S2a interface \\+-------+
( WIMAX | S-GW |======================| P-GW |
\ ACCESS +-------+ //+-------+
`--. _.-'ASN-GW //
`----------'' //
//
_.----------. //
,-'' `--. //
/ +-------+ // S2b interface
( WIFI | S-GW |//
\ ACCESS +-------+
`--. _.-'ePDG
`----------''
Figure 1: 3GPP Evolved Packet Core
Figure 1 shows a simplified overview of the EPS architecture (please
note that only the key components relevant for the understanding of
this document are highlighted). The Serving GW (S-GW) is the first
layer three hop in the network and is the default router for the
mobile node (i.e. Recipient of Router Solicitation and sender of
Router Advertisement messages). It provides layer three
configuration parameters. In case of non- 3GPP trusted access the
S-GW is implemented by the ASN-GW standardized by the Wimax Forum.
In case of non-3GPP, non-trusted access (e.g. WIFI) the S-GW is
implemented by the evolved Packet Data Gateway (ePDG). The P-GW is
the anchor point for all the uplink and downlink traffic to/from the
mobile node. The Home Address assigned to the mobile node is
anchored at the P-GW who is in charge of tunneling management towards
the S-GW. The reference point between S-GW and P-GW in the context
of LTE access is S5/S8, between the P-GW and the ASN-GW in the
context of WiMAX access is S2a and between the ePDG and the P-GW in
the context of WIFI interworking is S2b. S5, S2a and S2b interfaces
support mobility management of mobile devices and they can be
implemented, among others, via the Proxy Mobile IPv6
protocol[RFC5213]. In this case the P-GW integrates the LMA
functionality and the S-GW the MAG functionality. In the remainder
of this document we assume PMIPv6 is the selected mobility management
Melia, et al. Expires January 6, 2010 [Page 4]
Internet-Draft 3GPP MN-AR interface July 2009
protocol.
3. Differences between 3GPP and IETF specifications
The EPC architecture is specified in [3GPP.23.401]. Non-3GPP access
is detailed in [3GPP.23.402] The PMIPv6 protocol is specified in
[3GPP.29.275] (stage 3) and additional parameters in [3GPP.29.282]
and [3GPP.24.008]. The main difference between the PMIPv6 protocol
specified in [RFC5213] and the PMIPv6 protocol specified by 3GPP is
the introduction of the Access Point Name. The APN is introduced as
parameter in the PBU signaling and is used by the P-GW to allocate
the right Home Address (PDN selection).
To support Multiple PDNs the MAG and LMA perform lookups on the
extended data structure compared to the standard PMIPv6 as defined in
[RFC5213]. In standard PMIPv6 as defined in [RFC5213], a PMIPv6 BCE
is looked up based on the Mobile Node Identifier (MN_ID), the access
technology types (ATT) and if it exist the MN's link-layer identifier
(MN_LL_ID). In EPC the MN_LL_ID is not used and the EPC supports
handover between non-3GPP and 3GPP accesses. Since a distinct PMIPv6
BCE exists for each of the PDN connections of an UE, and since
multiple PDN connections of a UE can be distinguished based on an
APN, there is a one-to-one mapping between a PMIPv6 BCE, a PDN
connection, and the (MN_ID, APN) tuple. Thus, an UE PDN connection
can be uniquely identified by a (MN_ID, APN) tuple and the BC/BUL are
accordingly looked up on a per (MN_ID, APN) tuple basis.
It should be noted that the APN parameter is conveyed by the MN to
the access network during the access authentication procedure.
4. Reference point S5
Reference point S5 can be implemented via the GTP protocol or via
PMIP protocol. As stated before we focus here on the use of PMIPv6.
We summarize in the following attachment procedures and detachment
procedures focusing on the parameters required by the MAG to
correctly form a PBU.
4.1. Network attachment
When the MN initiates an attachment procedure it sends to the access
network among others the following parameters: PDN type, Protocol
Configuration Options (PCO), Attach type. PDN type indicates the
requested IP version (IPv4, IPv6, IPv4/IPv6). PCO is used to
transfer additional parameters between the MN and the LMA (P-GW).
Parameters are sent transparently through the MAG (S-GW). Attach
Melia, et al. Expires January 6, 2010 [Page 5]
Internet-Draft 3GPP MN-AR interface July 2009
type indicates "Handover" when the MN has already a mobility session
registered at the LMA due to mobility from non-3GPP access. To
handle situation where the MN might have multiple PDN connections
with the LMA the MN should also send the APN.
For default bearer creation the MAG (S-GW) sends a Proxy Binding
Update to the LMA (P-GW) including the following parameters: MN NAI,
Lifetime, Access Technology Type, Handover Indicator, APN, GRE key
for downlink traffic, MN Address Info Additional Parameters. The MN
NAI identifies the user equipment for whom the message is being sent.
The Lifetime field must be set to a nonzero value in the case of a
registration. Access Technology Type is set to indicate the Radio
Access Technology type (E-UTRAN). Handover Indication option is set
to indicate attachment over a new interface as no Handover indication
is indicated in the Attach type. The APN may be necessary to
differentiate the intended PDN from the other PDNs supported by the
same PDN GW. The optional Additional Parameters may contain
information, for example, Protocol Configuration Options. The UE
Address Info IE is used to request an IPv6 prefix, IPv4 address, or
both IPv4 address and IPv6 prefix. Based on PDN Type parameter
received the MAG (S-GW) includes request for IPv4 Home Address (PDN
Type set to IPv4), or IPv6 Home Network Prefix (PDN type set to IPv6)
or both IPv4 home address and IPv6 HNP (PDN type set to IPv4v6) in
the PBU as specified in PMIPv6 specification.
The PDN GW responds with a PMIPv6 Binding Acknowledgment message to
the S-GW including the following parameters: MN NAI, Lifetime, UE
Address Info, GRE key for uplink traffic, Additional Parameters. The
MN NAI is identical to the MN NAI sent in the Proxy Binding Update.
The Lifetime indicates the duration the binding will remain valid.
The PDN GW takes into account the request from S-GW and the
operator's policies when allocating the UE Address Info. It should
be noted that the S-GW learns from the PBA if the P-GW supports
multiple PDN connections to the same APN or not.
It should be noted that critical parameters to fill in mandatory
parameters in PBU/PBA messages are conveyed during network access.
4.2. Network Detachment
In case of network detachment all the bearers at the S-GW are
terminated. The S-GW sends a Proxy Binding Update message to the
P-GW including the following parameters: MN NAI, APN, and lifetime
set to value 0. The MN NAI and APN identify the PDN connection of
the UE. The lifetime field indicates that the message is used to
release the PDN connection of the UE at the PDN-GW.
The PDN GW responds to the S-GW with the result of the PDN connection
Melia, et al. Expires January 6, 2010 [Page 6]
Internet-Draft 3GPP MN-AR interface July 2009
release with Proxy Binding Update Acknowledgment
5. Reference point S2a
Reference point S2a may implement PMIPv6 to grant network access for
non-3GPP networks.
5.1. Network Attachment
Upon layer two access procedures (which are not in scope of 3GPP) the
MN performs EAP authentication with the AAA infrastructure. Among
other parameters, the 3GPP AAA server return to the S-GW the MN NAI
to be used to identify the UE in the PBU message. If this is
supported by the non-3GPP access network the Attach Type is indicated
to the S-GW by the UE. The support for attach type indication is
access technology specific and not in scope of 3GPP specifications.
An Attach Type set to value "handover" indicates that the UE has
already an active mobility session at the P-GW due to mobility from
3GPP to non-3GPP access.
After successful authentication and authorization, the non-3GPP
access specific L3 attach procedure is triggered. The UE may send
requested APN to the Non-3GPP IP access in this step (note that
Attach Type and APN can be sent as part of L3 signaling as suggested
in [I-D.patil-dhc-apn-attachtype-options]). If the UE sends a
requested APN in this step, the Trusted non-3GPP Access verifies that
it is allowed by subscription. If the UE does not send a requested
APN the Trusted non-3GPP Access uses the default APN. The PDN
Gateway selection takes place. If the PDN subscription profile
returned by the 3GPP AAA Server contains a PDN GW identity for the
selected APN and the Attach Type does not indicate "Handover", the
Non-3GPP access GW may request a new PDN GW to allocate a PDN GW that
allows for more efficient routing. The UE may request the type of
address (IPv4 address or IPv6 prefix or both) during this step. If
supported by the non-3GPP access, the UE may send Protocol
Configuration Options in this step using access specific mechanisms
(note that other IP based mechanisms have been proposed
[I-D.melia-dhc-pco]). The Protocol Configuration Options provided by
the UE may include the user credentials for PDN access authorization.
In that case, in order to handle situations where the UE may have
subscriptions to multiple PDNs, the UE should also send a requested
APN to the non-3GPP IP access.
The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding
Update to the P-GW including the following parameters: MN-NAI,
Lifetime, Access Technology Type, Handover Indicator, APN, GRE key
for downlink traffic, Additional Parameters. The MN NAI identifies
Melia, et al. Expires January 6, 2010 [Page 7]
Internet-Draft 3GPP MN-AR interface July 2009
the UE. The Lifetime field must be set to a nonzero value. Access
Technology Type is set to a value matching the characteristics of the
non-3GPP access. Handover Indicator is set to "initial" attach as
the UE has provided Attach Type indicating "Initial" attach or as the
Attach Type indicates "Handover" and the PDN subscription profile
contains no PDN GW. The Additional Parameters include the Protocol
Configuration Options provided by the UE and may also include other
information. The MAG requests the IP address types (IPv4 address
and/or IPv6 Home Network Prefix) based on requested IP address types
and subscription profile in the same way as the PDN type is selected
during the E UTRAN Initial Attach in [3GPP.23.401]. If the PDN
requires an additional authentication and authorization with an
external AAA Server, the P-GW performs such an additional
authentication and authorization at the reception of the Proxy
Binding Update.
The P-GW processes the proxy binding update and creates a binding
cache entry for the UE. The P-GW allocates IP address(es) for the
UE. The P-GW then sends a Proxy Binding Acknowledgment message to
the MAG including the following parameters: MN NAI, Lifetime, UE
Address Info, GRE key for uplink traffic, Additional Parameters and
the IP address(es) allocated for the UE. The UE Address Info
includes one or more IP addresses. The Lifetime indicates the
duration of the binding. The Additional Parameters may include
Protocol Configuration Options and other information.If UE requests
for both IPv4 and IPv6 addresses, both are allocated. If the P-GW
operator dictates the use of IPv4 addressing only or IPv6 addressing
only for this APN, the P-GW shall allocate only IPv4 address or only
IPv6 prefix to the UE. If the UE requests for only IPv4 or IPv6
address only one address is allocated accordingly.
5.2. Network detachment
If the UE in the trusted non-3GPP access triggers either detach or
disconnection of a PDN connection by means of access specific
procedures the MAG (S-GW) sends a Proxy Binding Update message to the
P-GW with the following parameters: MN NAI, APN, lifetime value set
to 0. The MN NAI identifies the UE to deregister from the PDN GW.
When only one PDN connection to the given APN is allowed the APN is
needed in order to determine which PDN to deregister the UE from, as
some PDN GWs may support multiple PDNs. When multiple PDN
connections to the given APN are supported the APN and the PDN
connection identity are needed in order to determine which PDN to
deregister the UE from.
The P-GW deletes existing entries implied in the Proxy Binding Update
message from its Binding Cache and sends a Proxy Binding
Acknowledgment message to the MAG.
Melia, et al. Expires January 6, 2010 [Page 8]
Internet-Draft 3GPP MN-AR interface July 2009
6. Reference point S2b
Reference point S2b is used to grant network access to MN in the
context of non-trusted non-3GPP networks (e.g. WLAN access). As
shown in Figure 1 it is assumed that the MAG functionality is co-
located with the ePDG. Between the MN and the ePDG an IPsec tunnel
is used to convey the required parameters for PMIPv6 operation
between the MAG and the LMA (P-GW).
6.1. Network Attachment
Prior to IKEv2 tunnel establishment the MN configures an IP address
from the local non-trusted non-3GPP access network. The ePDG IP
address to which the UE needs to form IPsec tunnel is discovered via
DNS. The UE may request connectivity to a specific PDN providing an
APN, that is conveyed with IKEv2. For networks supporting multiple
mobility protocols, if there was any dynamic IP mobility selection
decision involved in this step, the decision is stored in the 3GPP
AAA Server. The P-GW information is returned as part of the reply
from the 3GPP AAA Server to the ePDG. If the UE has provided an APN
the ePDG verifies that it is allowed by subscription. If the UE has
not provided an APN the ePDG uses the default APN. The P-GW
selection takes place at this point. The UE indicates the type of
address(es) (IPv4 address or IPv6 prefix /address or both) in the
CFG_Request sent to the ePDG during IKEv2 message exchange.
The ePDG sends the Proxy Binding Update message to the P-GW including
the following parameters: MN-NAI, Lifetime, APN, Access Technology
Type, Handover Indicator, GRE key for downlink traffic, UE Address
Info, Charging Characteristics , Additional Parameter. Access
Technology Type option is set to a value matching the characteristics
of the non-3GPP IP access. Handover Indicator is set to indicate
attachment over a new interface. The MN NAI identifies the UE. The
Lifetime field must be set to a nonzero value in the case of a
registration and a zero value in the case of a de-registration. The
APN is used by the P-GW to determine which PDN to establish
connectivity for, in the case that the P-GW supports multiple PDN
connectivity. The ePDG creates and includes a PDN connection
identity if the ePDG supports multiple PDN connections to a single
APN.
The P-GW processes the Proxy Binding Update and creates a binding
cache entry for the UE. The P-GW allocates an IP address for the UE.
The P-GW then sends a Proxy Binding Ack message to the S-GW including
the following parameters: MN NAI, UE Address Info, GRE Key for uplink
traffic, Charging ID and the IP address(es) allocated for the UE
(identified by the MN NAI). If the corresponding Proxy Binding
Update contains the PDN connection identity, the P-GW shall
Melia, et al. Expires January 6, 2010 [Page 9]
Internet-Draft 3GPP MN-AR interface July 2009
acknowledge if multiple PDN connections to the given APN are
supported.
6.2. Network Detachment
The release of the IKEv2 tunnel triggers PMIPv6 disconnection.
The MAG in the ePDG sends a Proxy Binding Update (MN NAI, APN,
lifetime=0) message to the PDN GW. The MN NAI identifies the UE.
When only one PDN connection to the given APN is allowed the APN is
needed in order to determine which PDN to deregister the UE from, as
some PDN GWs may support multiple PDNs. When multiple PDN
connections to the given APN are supported, the APN and the PDN
connection identity are needed in order to determine which PDN to
deregister the UE from. The lifetime value set to zero, indicates
this is a PMIP de-registration.
The P-GW deletes all existing entries for the indicated HoA from its
Binding Cache and sends a Proxy Binding Ack (MN NAI, lifetime=0)
message to the MAG in the ePDG. The P-GW sends a Proxy Binding Ack
message to the ePDG. The MN NAI value and the lifetime=0 values
indicate that the UE has been successfully deregistered.
7. Common aspects in Handover Management procedures
Generally when the UE, upon handover trigger, attaches to the target
access network it sends the Attach Type field set to value
"Handover". This is an explicit indication from the UE willing to
perform handover.
In case the MN performs handover from non-3GPP trusted access to
EUTRAN access the MAG sets the Handover Indicator in the PBU
according to the Attach Type field received during the attach
procedure.
In case the MN performs handover from 3GPP access to non-3GPP trusted
access the MN needs to provide at the latest during layer three
attachment the required parameters (e.g. handover indication, APN).
How the MN delivers such parameters to the access network is however
not in scope of 3GPP specifications.
In case the MN performs handover from 3GPP to non-3GPP non-trusted
access network the MN should provide during the IKEv2 tunnel
establishment an indication of address preservation during handover.
The ePDG upon reception of the IKEv2 signaling will form a PBU
setting the Handover Indicator field accordingly to the address
preservation indication. The APN is used to determine which PDN
Melia, et al. Expires January 6, 2010 [Page 10]
Internet-Draft 3GPP MN-AR interface July 2009
connectivity is updated.
8. Multiple Interfaces support
[3GPP.23.861] explores the possibility to use simultaneous PDN
connections across different access networks. [3GPP.23.861] further
specifies that a MN is able to connect at the same time two and only
two wireless devices. That is, possible scenarios are a MN being
connected to the LTE network and further enjoying services provided
either through the non-3GPP trusted network or trough the non-3GPP
non-trusted network. In this context multiple interface support can
be provided by means of routing filters based solutions or by means
of the PCC framework.
Routing filters based solutions are described for both Dual Stack
Mobile IPv6 (note that EPC also supports DSMIPv6 on reference point
S2c) and Proxy Mobile IPv6. While for the S2c interface
[I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding]
completely design the solution, it is left for further study if
PMIPv6 should be enhanced to convey routing filters between the MAG
and the LMA as part of the PBU/PBA exchange or if PCO could be used
instead.
If the PCC framework is used for network based mobility management
(e.g. PMIPv6) filters are installed as part of the interactions
between P-GW and PCC framework during network attachment/handover.
In general the MN still has to provide indication to the access
network that it intends to add an additional PDN connection to the
already existing mobility session at the P-GW. This is achieved
transferring a "MAPIM" indicator as part of the attach procedure in
the PCO field. Note that PCO is transferred at layer two during
EUTRAN access, and it is not described how it is transferred in the
case of non-3GPP access (trusted or not-trusted).
9. General Considerations
We can safely summarize that during EUTRAN network attachment the
paramters required for PMIPv6 operation (i.e. MN_ID, APN, Attach
type) are transferred as part of the layer two signaling. In case of
handover from a non-3GPP system to a 3GPP system the Attach Type
indicates "handover". Attach type is specified by the UE and used by
the MAG to fill the Handover Indicator option. In case the UE
intends to enable multiple interface support and the P-GW has an
already existing session the UE may include a MAPIM indicator to
update the existing mobility session.
Melia, et al. Expires January 6, 2010 [Page 11]
Internet-Draft 3GPP MN-AR interface July 2009
During attachment to a non-3GPP trusted system the network attachment
procedures are not in scope of 3GPP. However, such procedures can be
part of layer three signaling (i.e. IP signaling). In case of
mobility to a non-3GPP trusted system the Attach Type (used to fill
in the Handover Indicator option) indicates handover (set by the UE).
Multiple interface usage may be achieved by means of the MAPIM
indicator transferred as part of PCO.
During attachment to a non-trusted non-3GPP system the required
parameters for PMIPv6 operation are transferred to the ePDG as part
of the IKEv2 signaling.
10. IANA Considerations
This document makes no request of IANA.
11. Security Considerations
This document summarizes deployment choices for PMIPv6 specified in
other SDOs. There are no security issues to be dealt with.
12. Acknowledgements
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
13.2. Informative References
[3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 8.6.0, June 2009.
[3GPP.23.402]
3GPP, "Architecture enhancements for non-3GPP accesses",
3GPP TS 23.402 8.6.0, June 2009.
Melia, et al. Expires January 6, 2010 [Page 12]
Internet-Draft 3GPP MN-AR interface July 2009
[3GPP.23.861]
3GPP, "Multi Access PDN connectivity and IP flow
mobility", 3GPP TR 23.861 1.1.1, May 2009.
[3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005.
[3GPP.29.275]
3GPP, "Proxy Mobile IPv6 (PMIPv6) based Mobility and
Tunneling protocols; Stage 3", 3GPP TS 29.275 8.2.1,
April 2009.
[3GPP.29.282]
3GPP, "Mobile IPv6 vendor specific option format and usage
within 3GPP", 3GPP TS 29.282 8.1.0, June 2009.
[I-D.gundavelli-netext-extensions-motivation]
Gundavelli, S., "Extensions to Proxy Mobile IPv6 -
Motivation",
draft-gundavelli-netext-extensions-motivation-00 (work in
progress), May 2009.
[I-D.ietf-mext-flow-binding]
Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo
Basic Support", draft-ietf-mext-flow-binding-02 (work in
progress), April 2009.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-14 (work in progress),
May 2009.
[I-D.melia-dhc-pco]
Melia, T. and Y. Mghazli, "DHCP option to transport
Protocol Configuration Options", draft-melia-dhc-pco-00
(work in progress), February 2009.
[I-D.patil-dhc-apn-attachtype-options]
Patil, B., Chowdhury, K., and D. Premec, "DHCP options for
Access Point Name and attach type indication",
draft-patil-dhc-apn-attachtype-options-01 (work in
progress), March 2009.
Melia, et al. Expires January 6, 2010 [Page 13]
Internet-Draft 3GPP MN-AR interface July 2009
Authors' Addresses
Telemaco Melia
Alcatel-Lucent Bell Labs
Email: telemaco.melia@alcatel-lucent.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Fax:
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: JuanCarlos.Zuniga@InterDigital.com
Melia, et al. Expires January 6, 2010 [Page 14]