NETLMM Applicability Draft (Summary)

1. NETLMM Applicability Draft(Summary) 28 Sep. 2006

2. Purpose of the Draft • General • The initial purpose is to provide the applicability analysis for WG which makes base protocol standardization be easier • Illustrate how NETLMM works under a MN-AR IF, i.e. LTE access • The draft aims to illustrate the NETLMM applicability to the “current” 3GPP SAE architecture • clarify what parameters are required to activate NETLMM routing path establishment/modify/delete • Notes • May need to update the detail when some key points for NETLMM applicability, e.g. detail handover signaling flow, has been fixed

3. Table of Contents • Introduction • Terminology • Overview of the 3GPP SAE/LTE network 3.1. Simplified SAE Network Architecture 3.2. Network Attachment 3.3. Inter MME/UPE Mobility within the LTE access system • NETLMM Application for SAE network with LTE access system 4.1. NETLMM function entity configuration 4.2. Network Attachment with NETLMM 4.3. Inter UPE mobility by NETLMM • Conclusion • Security Considerations • Acknowledgements • References *ID management would be described

4. 3.1. SAE Network Architecture for Mobility Management • Architecture figure is focused on LTE access accommodation • MME/UPE is assumed to be logically separated, but for now we regard they are physically collocated. • In the document, only single anchor will be illustrated in stead of 3GPP anchor and SAE anchor, i.e. LTE anchor • Note that LTE anchor is a non-standard term and used only for explanation purpose in this draft. Base Line Architecture Figure

5. GPRS ID management • At GGSN, • GGSN located at home network, except the case of local breakout • GGSN maintains IMSI as a key for PDP context at GGSN • At SGSN, • SGSN located at visited network • SGSN allocates TMSI created from IMSI • TMSI needs to be updated every time SGSN changes (P‑TMSI Reallocation Procedure between SGSN and MN) • SGSN maintains IMSI as the main reference key for PDP context at SGSN IMSI is used as the main key for PDP context at both GSGN and SGSN

6. SAE ID management (under discussion) • At MME, • Authentication, authorization (PLMN, TA) and key management; • Working With HSS • Ciphering/integrity termination for signaling; • S1 C-Plan termination • S1 U-Plan tunnel termination • (L2 tunnel  L3 tunnel) • Management and allocation of temporary user identities; • TMSI like identifier allocation, similar to SGSN IMSI would be necessary to handle the mobility between MME/UPEs  IMSI seems to be a appropriate identifier for NETLMM used for S5 IF

7. Figure in TR23.882 Network Attachment Application of NETLMM signaling (Location Reg/Ack) • This procedure is under discussion (one of the alternatives) • But step 7 and 9, target of NETLMM, exists for every alternatives • Subscriber data transactions with HSS (step4,5) can be combined with steps 3,6

8. Figure in TR23.882 Inter MME/UPE Mobility within the LTE access system Application of NETLMM signaling (Location Reg/Ack) • This procedure is under discussion (one of the alternatives) • But step 11, target of NETLMM, exists for every alternatives • It is not yet discussed how to handle temporary identifier when MME/UPE changes

9. Parameters Exchange(Network Attachment) NM ID for NETLMM (IMSI, TMSI) Could be in step 4 (APN, IASA address, MN prefix) (IMSI, MME/UPE address, IASA address, MN prefix) (IMSI, MME/UPE address, IASA address) • IMSI is assumed to be MN ID for NETLMM • In above, MN prefix is provided by HSS • IASA may provide MN prefix, but then APN info shall be sent in NETLMM message

10. Parameters Exchange(Inter MME/UPE Mobility within the LTE access system) MME/UPE can find MN context including MN ID (IMSI) by info in step3 (IMSI, IASA address, MN Prefix) (IMSI, MME/UPE address, IASA address, MN Prefix) (IMSI, MME/UPE address, IASA address) • This procedure is under discussion (one of the alternatives) • But step 11, target of NETLMM, exists for every alternatives • Location Deregistration is not required in this signaling flow • Not decided yet. Detail is under discussion in 3GPP • The function to delete old MME/UPE info is provided by context transfer IF • Should be say the use of Location Deregistration is optional ? • Depends on the target system can do it by its specific system or not.

11. Bearer Management in 3G(discussion for multiple Prefix to a MN ID) 28 Sep. 2006

12. What is done in GPRS • MS can initiate the activation, modification, and deactivation functions at any time for a PDP context • MN can have multiple PDP contexts, for instance, • Register IMS for VoIP (the bearer for VoIP call with IP-1) • MN starts web access (establish new bearer to access PDN-A with IP-2) • Connects to corporate network (establish new bearer to access PDN-B, corporate network, with IP-3) It is possible MN to establish PDP context, similar to NETLMM tunnel, upon necessary

13. Bearer Management in SAE • SAE is working on multiple PDN access • Same as what can be done in GPRS • The solution is under discussion • IASA may connect to multiple PDN • For NETLMM, it means different prefixes are allocated to a single MN • Similar to GPRS, it would be required to activate, modify, and deactivate a connection to PDN for efficient network resource usage • Some connection, such as default bearer, would be kept as long as the MN is attached to the network. Considering the applicability, it is necessary function to establish, modity, and delete one NETLMM tunnel form multiple ones