NETLMM K. Nishida
Internet Draft NTT DoCoMo Inc.
Expires: May 2007 H. Yokota
KDDI Labs
November 7, 2006
NETLMM Protocol Applicability Analysis for 3GPP SAE Network
draft-nishida-netlmm-protocol-applicability-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 7, .
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
The protocol of NETLMM Design Team output, defined in draft-giaretta-
netlmm-dt-protocol-02.txt assumes non-NETLMM triggers, provided by
so-called MN_Access_Network API, to initiate NETLMM procedures such
as sending location registration to LMA. In this document, the NETLMM
application to a mobility scenario of the 3GPP network, so-called SAE
(system architecture evolution), is analyzed.
Nishida, et al. Expires May 7, 2007 [Page 1]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
Through the applicability study, it is clarified that what kind of
non-NETLMM network triggers and parameters for NETLMM procedures are
expected to be provided by 3GPP SAE network.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Overview of the 3GPP SAE/LTE network.........................4
3.1. Simplified SAE Network Architecture.....................5
3.2. Network Attachment......................................6
3.3. Inter MME/UPE Mobility within the LTE access system......8
4. NETLMM Application for SAE network with LTE access system....11
4.1. NETLMM function entity configuration...................11
4.2. Network Attachment with NETLMM signalings..............12
4.3. Inter UPE mobility with NETLMM signalings..............14
5. Security Considerations.....................................16
6. Normative References........................................16
Author's Addresses............................................17
Intellectual Property Statement................................17
Disclaimer of Validity........................................18
Copyright Statement...........................................18
Acknowledgment................................................18
1. Introduction
NETLMM protocol defined in [NETLMM], which is the output of NETLMM
Design Team, assumes non-NETLMM triggers, provided by so-called
MN_Access_Network API, to initiate NETLMM procedures such as routing
cache entry registration via location registration signaling exchange,
for instance.
This document presents NETLMM protocol applicability for a mobility
scenario of the future 3GPP network, which is so-called SAE (System
Architecture Evolution) [SAE]. The SAE is now under standardization
in 3GPP aiming to make the 3GPP network enable to accommodate various
access systems with the common IP-based core network.
The purpose of this document is to analyze how the NETLMM protocol
can be applied to the 3GPPP SAE and clarify how the non-NETLMM
standardized triggers/informations described in [NETLMM], e.g.
MN_Access_Network API event, needs to be provided or expected to be
triggered by SAE functions.
Although SAE is capable of accommodate various access systems and
provides mobility between them, this document assumes SAE network
Nishida, et al. Expires May 7, 2007 [Page 2]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
with single access system for simplicity reason. The access system is
called LTE (long term evolution) [LTE] and it is also under
standardization process in 3GPP as a new wireless access technology.
Note that this document does not intend to specify or standardize any
particular procedures/parameters for NETLMM protocol application in
SAE.
2. Terminology
In addition to the NETLMM terminologies specified in [NETLMM], this
document uses following SAE and LTE terminology, specified in [SAE]
and [LTE].
UE: User Equipment, which is a device allowing a user access to
network services. This is equivalent to mobile node (MN) often used
in IETF.
MME: Mobility Manage Entity, which manages and stores UE context
(for idle state: UE/user identities, UE mobility state, user
security parameters). It also authenticates the UE.
UPE: User Plan Entity, which terminates for idle state UEs the
downlink data path and triggers/initiates paging when downlink data
arrive for the UE.
eNB: E-UTRAN NodeB. This is the base station of the LTE access
system.
With above terminologies, following non-standardized terms are used
in this document for explanation purpose.
LTE anchor: This provides mobility anchor functionality when UE
moves from one UPE area to another. In [SAE], this is equivalent to
IASA (Inter Access System Anchor), though the anchoring function
for inter access system handover is not included as such mobility
is outside the scope of this document.
HSS: Home Subscriber Server, which manages user profile,
authentication and authentication information, and security
vectors/keys. The functionality of HSS is considered to include
that of AAA, thought the detail is under discussion in 3GPP.
Followings are generic 3GPP terminologies and the detail descriptions
can be found in [3GPP term].
Nishida, et al. Expires May 7, 2007 [Page 3]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
APN: Access Point Name, used as the reference to a GGSN, which is
the IP point of attachment, in the GPRS backbone. This information
is provided by UE and used also to identify which external network
to connect via GGSN. It is not yet detailed in SAE, but same kind
of identifier is used to determine the external network to connect
for a UE. In this document, this term is used as generic identifier
that can determine a specific LMA, and will be interpreted that of
to be decided in [SAE].
TMSI: Temporary Mobile Subscriber Identity, is the locally unique
UE identifier. This is negotiated between UE and network in the
initial network attachment phase and used for identification of UE
in latter signaling exchange for UE identity confidentiality. In
GPRS, P-TMSI (Packet TMSI) is used for the same purpose, and it is
allocated by SGSN allocates. In this document, this term is used as
generic temporary identifier, and will be interpreted that of to be
decided in [SAE].
IMSI: International Mobile Subscriber Identity, is a globally
unique UE identifier that is allocated by UE's subscribing operator.
In this document, this term is used as generic permanent identifier,
and will be interpreted that of to be decided in [SAE].
3. Overview of the 3GPP SAE/LTE network
In 3GPP, the evolution from the existing GPRS network architecture is
being studied under the name of System Architecture Evolution (SAE)
in order to enhance the capability of the 3GPP system to cope with
the rapid growth in IP data traffic.
SAE is envisioned to accommodate various types of access systems such
as 3GPP access systems and WLAN, and it provides the support of
seamless mobility within and across those access systems. As one of
he 3GPP access systems, new radio access system called Long Term
Evolution (LTE) is now under standardization in 3GPP. One of the
important goals of SAE standardization is to accommodate LTE access
and provide higher bit rate packet services with seamless mobility
capability.
In this section, the simplified SAE architecture focused on the LTE
access accommodation is explained from the mobility management
perspective. The signaling flows are also quoted from [SAE] in order
to help the understanding of basic mobility procedures in SAE.
Nishida, et al. Expires May 7, 2007 [Page 4]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
Note that the SAE signaling flows is yet to be decided, and the
signaling flow reference is one of the alternatives under discussion
in 3GPP.
3.1. Simplified SAE Network Architecture
The SAE architecture logically consists of two user date forwarding
entities, i.e. UPE (User Plane Entity) and LTE anchor, and network/UE
control entities, e.g. MME, HSS/AAA. Figure 1 shows the simplified
SAE network architecture with LTE access focusing on mobility
management related entities.
-----------
| HSS |
-----------
| S6
|-------------------------------
| ----------- |
| | MME | |
------ ----------- S1 | ----------- S5 ----------- | SGi
| UE |--+--| eNodeB |--+-|--| UPE |--+--|LTE Anchor|-|--+--
------ ----------- | ----------- ---------- |
| |
--------------------------------
Evolved Packet Core
Figure 1: Simplified SAE Network Architecture for LTE access
S1 IF provides the user date forwarding and bearer management
capability including mobility management between eNodeB and UPE. UPE
ciphers/deciphers the user date when sending/receiving user IP
packets to/from respectively. Therefore, information of S1 tunnel,
e.g. tunnel identifier, are exchanged over the S1 IF as the S1
routing is logically done below user IP layer.
S5 IF provides routing path establishment and mobility management
between UPE and LTE anchor. On contrary to S1, S5 does not contain
access specific functionalities such as handling of ciphered user IP
packets.
S6 IF provides the capability to exchange authentication and
authorization related information. Although currently it is not
defined to which entity S6 is connected, it is assumed MME/UPE has S6
IF to HHS in some specific purposes, e.g. idle mode location
management.
Nishida, et al. Expires May 7, 2007 [Page 5]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
SGi is the IF to connect external packet data networks such as
internet. It is generic user plane IF where user IP packets are
transferred.
Note that the detail SAE network architecture is under discussion, so
that the entity names and/or location of entities, e.g. collocation
or separation of entities, are subject to change. In this document,
MME and UPE are assumed to be physically collocated for simplicity
reason, but this assumption does not preclude the NETLMM application
possibility to the scenario where MME and UPE are physically
separated.
3.2. Network Attachment
When UE attaches to the network, network attachment procedure is
initiated by UE sending the attach request message including such as
user subscriber identifier. This procedure provides functions of
authentication/authorization, temporary identifier exchange, routing
path establishment from external network to MME/UPE and etc.
In SAE/LTE architecture, in order to minimize the connection setup
delay such as routing path setup, it is designed to maintain the IP
connectivity from external network to MME/UPE while UE is in the idle
state. UE establishes the connection of the air and S1 when it moves
to active state.
Figure 2 shows the signaling flow of network attachment currently
defined in [SAE].
UE eNB MME/UPE LTE Anchor HSS
| | | | |
1)Network Discovery | | |
(eNB Selection) | | | |
|<--------->| | | |
|2)Attach Request | | |
|---------------------->| | |
| | 3)authentication | |
|<--------------------->|<--------------------->|
| | | 4)Update Location |
| | |---------------------->|
| | | 5) Insert Subsc. Data |
| | |<----------------------|
| | | 6) Insert Subsc. Data Ack
Nishida, et al. Expires May 7, 2007 [Page 6]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
| | |---------------------->|
| | | 7)Update Location Ack |
| | |<----------------------|
| | | 8)Bearer Request |
| | |---------->| |
| | | 9)Bearer Response |
| | |<----------| |
| 10)Radio bearer Request | |
| |<--------->| | |
| 11)Radio bearer Request | |
|<--------->| | | |
| 12)Attach accept(IP configuration)| |
|<----------------------| | |
| 13Attach confirm | | |
|---------------------->| | |
| | | | |
Figure 2: Signaling Flow of Network Attachment
1) The UE discovers the SAE/LTE access system and performs eNB
selection by monitoring radio conditions.
2) The UE sends an attach request to the MME/UPE including its
permanent identity, e.g. IMSI. MME/UPE is selected by LTE systems,
e.g. eNB. Attach request message may also include APN information
indicating which network UE requests to connect.
3) The UE is authenticated in the MME/UPE interacting with HSS.
MME/UPE may inform APN information to HSS if it is provided by
attach request message.
4) The MME/UPE registers itself at HSS as serving entity for the UE
for location management.
5) HSS inserts subscriber related information to MME/UPE.
6) MME/UPE acknowledges by sending Insert Subscriber Data Ack message.
7) HSS sends Update Location Ack message to complete the location
registration procedure that records current MME/UPE serving to the
UE at HSS.
In either of procedure 3), 5) or 7), HSS or other resolver provides
the LTE anchor information, such as LTE IP address, to MME/UPE by
Nishida, et al. Expires May 7, 2007 [Page 7]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
referring subscriber information at HSS and/or APN information if
provided.
Subscriber data transactions with HSS can be combined with location
update messages in steps 4 and 7.
8) MME/UPE sends Bearer Request message to configure user plane route
between MME/UPE and LTE Anchor.
9) LTE Anchor configures the routing information for the UE and
acknowledge to MME/UPE.
The IP address for UE is allocated either from HSS or LTE Anchor. If
done by HSS, it will inform allocated IP address via either 5) or 7).
If LTE Anchor allocates, it will return allocated IP address via 9).
In both scenarios, HSS and LTE Anchor will interact with external
networks to negotiate address spaces for allocation. It could be
also configured manually.
10) The MME/UPE establishes the routing path over S1. S1 specific
tunnel information, such as tunnel identifier, will be exchanged.
11) eNB establish the LTE link layer path with UE.
12) The MME/UPE accepts the UE's network attachment and allocates a
temporary identity, e.g. TMSI, to the UE. Also the determined user
IP address is transferred.
13) The UE acknowledges the success of the network attachment.
3.3. Inter MME/UPE Mobility within the LTE access system
When UE moves within the LTE access system, there are two mobility
scenario; intra MME/UPE mobility and inter MME/UPE mobility.
Intra MME/UPE mobility happens when UE moves between eNBs connected
to the same MME/UPE, while inter MME/UPE mobility does when UE moves
to a different eNB connected to another MME/UPE.
This document takes the inter MME/UPE mobility scenario as an example
for NETLMM applicability analysis. This is because the S5 IF is
access system independent and easier to understand what functions and
Nishida, et al. Expires May 7, 2007 [Page 8]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
parameters needs to be provided outside the NETLMM mechanism to
switch the routing path using NETLMM signalings.
When UE detects new eNB, it monitors the radio conditions and link
layer mechanism initiates handover procedure, i.e. current connecting
eNB sends Handover Required signaling to currently serving MME/UPE.
The IP layer routing path update in the network is triggered by a
precedent signaling from eNB, and the UE does not aware of such
change, i.e. not direct routing path update signaling from MN.
Below is the figure of inter MME/UPE mobility scenario.
-----------
| HSS |
-----------
| S6
+---------------------------------+
| +------+ |
+--+ | |MME | |
| | +------+ S1 +------+\ |
+--+ -|EnodeB|--------|UPE | \ S5 |
UE +------+ | +------+ \ |
|| | \+------------+ |
|| | | LTE Anchor |-+----
\/ | +------+ /+------------+ |
+--+ | |MME | /S5 |
| | +------+ S1 +------+ / |
+--+ -|EnodeB|--------|UPE |/ |
UE +------+ | +------+ |
+---------------------------------+
Figure 3: Inter MME/UPE mobility
Figure 4 shows the signaling flow of inter MME/UPE mobility currently
defined in [SAE].
UE eNB1 eNB2 MME/UPE1 MME/UPE2 LTE Anchor
| | | | | |
| | Established IP connectivity | |
|<--------------------------------------------------------->|
| | | | | |
@ | | | | |
Nishida, et al. Expires May 7, 2007 [Page 9]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
1)Handover Initiation | | | |
| | | | | |
| | | | | |
| | 2) Handover Required | | |
| |---------------------->| | |
| | | | 3) Handover Required |
| | | |---------->| |
| | 4) Handover Request & Bearer path establishment
| | |<--------------------->| |
| | | | 5) Handover Response |
| | | |<----------| |
| | 6)Handover Command | | |
|<----------|<----------------------| | |
| 7)Radio Bearer Establishment | | |
|---------------------->| | | |
| | | 8)Handover Complete Detect |
| | |---------------------->| |
| | | | 9) Bearer Request|
| | | | |---------->|
| | | | 10) Bearer Response
| | | | |<----------|
| | | 11) Handover Complete |
| | | |<----------| |
| | 12) Handover Complete| | |
| |<----------------------| | |
| | 13) Established IP connectivity | |
|<--------------------------------------------------------->|
| | | | | |
Figure 4: Signaling Flow of Inter MME/UPE Mobility
1) While the IP connectivity is established between the UE and the
LTE Anchor, the eNB1 decides to initiate a handover to eNB2 by
receiving the radio condition reports from UE.
2) The eNB1 sends a Handover Required to the MME/UPE1.
3) The MME/UPE1 selects a MME/UPE2 serving the eNB2 that the UE is
going to use and sends it a Handover Required, including the UE
context information.
4) The MME/UPE2 creates a UE context and initiates S1 routing path
establishment with eNB2.
Nishida, et al. Expires May 7, 2007 [Page 10]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
5) The MME/UPE2 sends a Handover Response to inform the handover
preparation has completed, i.e. path establishment between eNB2 and
MME/UPE2.
6) The MME/UPE1 sends a Handover Command to the UE via eNB2. This
triggers UE to establish LTE link layer path.
7) The UE is detected at the eNB2, and it establishes LTE link layer
path.
8) eNB2 sends a Handover Complete Detect to the MME/UPE2 to update
the routing path between LTE Anchor and MME/UPE, i.e. from MME/UPE1
to MME/UPE2
9) The MME/UPE2 sends a Bearer Request to the LTE Anchor to update
the routing path for the UE
10) The LTE Anchor sends a Bearer Response to the MME/UPE2.
11) The MME/UPE2 informs MME/UPE1 of the Handover Complete and the
possibility to release resources in previous access.
12) The resource in the source system is released.
13) The IP connectivity is now established between the UE and the
LTE Anchor via MME/UPE2.
4. NETLMM Application for SAE network with LTE access system
In this section, NETLMM signaling application for network attachment
and inter MME/UPE handover is discussed. As discussed in the previous
section, the routing path management between MME/UPE and LTE Anchor,
i.e. S5, is targeted for application.
4.1. NETLMM function entity configuration
In order to apply NETLMM for routing path management between MME/UPE
and LTE Anchor, NETLMM functional entities, MAG and LMA, are located
at MME/UPE and LTE respectively.
Figure 5 shows the SAE architecture with NETLMM functional entities.
-----------
| HSS/AAA |
Nishida, et al. Expires May 7, 2007 [Page 11]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
-----------
| S6
|-------------------------------
| ----------- |
| | MME | |
------ ----------- S1 | ----------- S5 ----------- | SGi
| UE |--+--| eNodeB |--+-|--| UPE |--+--|LTE Anchor|-|--+--
------ ----------- | | (MAG) | | (LMA) | |
| ---------- ------------ |
| <----------------> |
| routing management by NETLMM |
--------------------------------
Evolved Packet Core
Figure 5: NETLMM Function Allocation to SAE/LTE Architecture
As specified in [NETLMM], MN ID, MAG handle and LMA handle must be
properly provided by SAE functionality to use Location Registration
and Location Deregistration.
MN ID must be unique within the NETLMM domain regardless of UE
mobility. Therefore, in this NETLMM application analysis, IMSI is
treated as MN ID for explanation. This does not increase
vulnerability as the MN ID is only exchanged between MME/UPE and IASA
of the same administrative domain.
For simplicity, it is also assumes MAG and LMA handles are their IP
addresses. MAG and LMA may have multiple IP addresses for some
reasons such as load balancing, but this document considered the
scenario where MME/UPE and LTE Anchor has single IP. It is outside
the scope of document how to handle multiple IP addresses.
In the following scenario, the LMA selection is assumed to be done by
the HSS.
This analysis assumes non roaming scenario, but the same mechanism is
expected to be applicable for roaming if the additional security
mechanism outside NETLMM protects malicious attacks such as signaling
spoofing or interpolation.
4.2. Network Attachment with NETLMM signalings
Figure 6 is the signaling flow of figure 2 with the use of NETLMM
signalings for routing path establishment between MME/UPE and LTE
Anchor. Parameters for NETLMM signaling exchange is also illustrated.
Nishida, et al. Expires May 7, 2007 [Page 12]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
The modified messages are highlighted with the asterisk in front of
the signaling number, and parameters related to NETLMM signaling
application are bracketed off after the name of message carrying them.
Parameters shown in the figure are not exhaustive, but only minimum
ones for application analysis.
UE eNB MME/UPE LTE Anchor HSS
| | | | |
1)Network Discovery | | |
(eNB Selection) | | | |
|<.........>| | | |
|2)Attach Request (IMSI,APN) | |
|......................>| | |
| | 3)authentication (IMSI,TMSI,APN) |
|<.....................>|<.....................>|
@ | @ | @
(store TMSI) | (store IMSI/TMSI) | (store IMSI,APN)
| | | | |
| | | 4)Update Location |
| | |......................>|
| 5)Insert Subsc. Data (UE address, LTE Anchor addr.)
| | |<......................|
| | | 6) Insert Subsc. Data Ack
| | |......................>|
| | | 7)Update Location Ack |
| | |<......................|
| *8)Location Reg. (IMSI, addr of MME/UPE, LTE Anchor and UE)
| | |---------->| |
*9)Location Reg Ack. (IMSI, addr of MME/UPE, LTE Anchor and UE, status)
| | |<----------| |
| 10)Radio bearer Request | |
| |<.........>| | |
| 11)Radio bearer Request | |
|<.........>| | | |
| 12)Attach accept(IP configuration)| |
|<......................| | |
| 13)Attach confirm | | |
|......................>| | |
| | | | |
Figure 6: Signaling Flow of Network Attachment with NETLMM
Signalings
Nishida, et al. Expires May 7, 2007 [Page 13]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
In application of NETLMM, it is important that the non-NETLMM
mechanisms/signalings can provide the parameters required by the MAG
to initiate NETLMM procedures. The non-NETLMM mechanism for parameter
provision is mentioned as MN_Access_Network API in [NETLMM], and it
is assumed to provide MN ID and LMA ID in the network attachment
scenario. This application example assumes UE address, corresponding
to MN prefix in [NETLMM], is provided by HSS via APN or pre-
registered subscription information.
During the authentication procedure in step 3), UE, MME/UPE and HSS
exchanges UE related identities, i.e. IMSI (MN ID) and TMSI. MME/UPE
stores both of them, while HSS stores IMSI (MN ID).
Then, at the step 5, the HSS provide UE address (MN prefix) and LTE
anchor address (LMA ID) to MME/UPE. These information depends on
which network the UE requests to connect or pre defined information
at HSS, thus this document assumes HSS can allocate them via
information at HSS.
As the Bearer Request and acknowledgement illustrated as step 8 and 9
in figure 2 are used to establish the routing path between MME/UPE
and LTE Anchor. NETLMM Location Registration and ack messages can be
used for this purpose.
With the above mentioned parameter provision by step 7, NETLMM
Location Registration can be sent to LTE anchor in step 8. Then, LTE
Anchor replies by sending NETLMM Location Registration ack with the
parameters copied from Location Registration and status information.
4.3. Inter UPE mobility with NETLMM signalings
Figure 7 is the modified signaling flow of figure 4 with the
application of the NETLMM signalings and related parameters that
needs to be notified to LMA and MAG.
The modified messages are highlighted with the asterisk in front of
the signaling number. Parameters related to NETLMM signaling
application are bracketed off after the name of message carrying them.
Parameters shown in the figure are not exhaustive, but only minimum
ones for application analysis.
UE eNB1 eNB2 MME/UPE1 MME/UPE2 LTE Anchor
| | | | | |
| | Established IP connectivity | |
|<--------------------------------------------------------->|
| | | | | |
Nishida, et al. Expires May 7, 2007 [Page 14]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
@ | | | | |
1)Handover Initiation | | | |
| | | | | |
| | | | | |
| | 2) Handover Required | | |
| |......................>| | |
| 3) Handover Required(IMSI, UE address, LTE Anchor addr)|
| | | |..........>| |
| | 4) Handover Request & Bearer path establishment
| | |<.....................>| |
| | | | 5) Handover Response |
| | | |<..........| |
| | 6)Handover Command | | |
|<..........|<......................| | |
| 7)Radio Bearer Establishment | | |
|......................>| | | |
| | | 8)Handover Complete Detect |
| | |......................>| |
| |*9)Location Reg. (IMSI, addr of MME/UPE, LTE Anchor)
| | | | |---------->|
*10)Location Reg Ack. (IMSI, addr of MME/UPE, LTE Anchor and UE, status)
| | | | |<----------|
| | | 11) Handover Complete |
| | | |<..........| |
| | 12) Handover Complete| | |
| |<......................| | |
| | | | | |
Figure 7: Signaling Flow of Inter MME/UPE Mobility with NETLMM
Signalings
When the MME/UPE1 receives the Handover Required message from the
eNB1 in step 3, the MME/UPE1 searches for the MN context that
includes the IMSI (MN ID). The MME/UPE1 then transfers to the
MME/UPE2 the information on the MN such as the IMSI (MN ID), the
MME/UPE2 address (MAG ID), the LTE Anchor address (LMA ID) and the MN
Address (MN Prefix). At this point, the MME/UPE2 is informed of the
LTE Anchor that accommodates the MN and when the MN's handover is
completed in step 8, the MME/UPE2 can send the NetLMM Location
Registration message to the correct LTE Anchor in step 9. The routing
cache entry for the IMSI (MN ID) on the LTE Anchor is updated to
forward packets designated to the MN Address (MN Prefix) to the
MME/UPE2 address. Then, the Location Registration Ack is returned to
the MME/UPE2 in step 10.
Nishida, et al. Expires May 7, 2007 [Page 15]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
While the old Routing Cache in the MME/UPE1 is deleted by the
MME/UPE2 with the Handover Complete message in step 11, such
information can alternatively be deleted by the LTE Anchor with the
NetLMM Location Deregistration message as shown in Figure 3 of
[NETLMM].
As illustrated in figure 7, if the new MME/UPE2 triggers the deletion
of the MN information on the old MME/UPE by step 11), it might be
necessary to indicate the LTE Anchor that the Location Deregistration
message is not required beforehand. This could be done by network
configuration phase with the Association Request/Ack exchange as
defined in [NETLMM]. Another alternative is to add an indication flag
in the Location Registration message to notify Location
Deregistration message is not required in handover procedure.
5. Security Considerations
This document analyzed the applicability of the NETLMM signaling in
the 3GPP SAE network and does not introduce or add new functionality
for NETLMM protocol. Therefore, the security threats in this document
is not any further than those described in the [NETLMM].
There needs some security mechanism for roaming network scenario as
MME/UPE and LTE Anchor could be located in the separate
administrative domain. In such a case, signaling protection between
MME/UPE and LTE would be required based on the trust relationship to
negotiate security association among them.
6. Normative References
[NETLMM] H. Levkowetz., "The NetLMM Protocol" draft-giaretta-netlmm-
dt-protocol-02 (work in progress), October 2006.
[SAE] 3GPP TR 23.882 V1.4.0, (work in progress), September 2006
[LTE] 3GPP TR 25.912 V7.0.0, (work in progress), June 2006
[3GPP Term] 3GPP TS 23.003 V7.0.0, June 2006
Nishida, et al. Expires May 7, 2007 [Page 16]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
Author's Addresses
Katsutoshi Nishida
NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi
Kanagawa,
Japan
Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp
Hidetoshi Yokota
KDDI R&D Laboratories, Inc.
2-1-15 Ohara, Fujimino
Saitama, 356-8502
Japan
Phone: +81 49 278 7894
Email: yokota@kddilabs.jp
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Nishida, et al. Expires May 7, 2007 [Page 17]
Internet-Draft NETLMM Protocol Applicability Analysis November 2006
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nishida, et al. Expires May 7, 2007 [Page 18]