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]