INTERNET-DRAFT J. Mueller
Intended Status: Informational AT&T Foundry
Expires: January 7, 2017 T. Herbert
Facebook
July 6, 2016
Mobility Management for 5G Network Architectures Using Identifier-locator Addressing
draft-mueller-ila-mobility-00
Abstract
This specification describes Mobility Management Architecture for 5G
Networks Using Identifier-Locator Addressing in IPv6 for virtualized
mobile telecommunication networks. Identifier-locator addressing
differentiates between location and identity of a network node. The
approach presented in this draft enables mobility management on Layer
3, and provides a simplified and more efficient architecture with
less core network utilization compared to traditional architecture.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mueller, Herbert Expires January 7. 2017 [Page 1]
INTERNET DRAFT <draft-mueller-ila-mobility>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction and Problem Statement . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Related Work, Protocols and Concepts . . . . . . . . . . . . . 5
3.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Proxy MobileIPv6 . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Host Identity Protocol (HIP) . . . . . . . . . . . . . . . . 6
3.4 Locator/ID Separation Protocol (LISP) . . . . . . . . . . . 7
3.5 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Identifier-Locator Addressing (ILA) . . . . . . . . . . . . 7
3.7 Comparison of ILA to alternative approaches . . . . . . . . 7
3.7.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7.2 LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Taxonomy & Summary . . . . . . . . . . . . . . . . . . . . . 9
4 Mobility Management Architectures for 5G Network Using ILA . . . 9
4.1 Address format for ILA mobile . . . . . . . . . . . . . . . 9
4.2 Architecture with functional elements and reference
points . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 Functional Elements . . . . . . . . . . . . . . . . . . . . 10
4.4 Signaling and data flow . . . . . . . . . . . . . . . . . . 12
4.5.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2 Attachment . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.3 Communication scenarios for data transport for an
End-to-End session . . . . . . . . . . . . . . . . . . . 13
4.5.4 Homogeneous Handover . . . . . . . . . . . . . . . . . . 15
4.5.5 Heterogeneous Handover . . . . . . . . . . . . . . . . . 16
4.5.6 Detachment . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 TODO: Other cases . . . . . . . . . . . . . . . . . . . . . 16
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 18
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1 Normative References . . . . . . . . . . . . . . . . . . . 18
5.2 Informative References . . . . . . . . . . . . . . . . . . 18
Mueller, Herbert Expires January 7. 2017 [Page 2]
INTERNET DRAFT <draft-mueller-ila-mobility>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Mueller, Herbert Expires January 7. 2017 [Page 3]
INTERNET DRAFT <draft-mueller-ila-mobility>
1 Introduction and Problem Statement
Mobility has been a challenge for IP based network since the area of
smartphones began. One challenge is to ensure seamless and
transparent mobility for mobile devices among different locations and
in between several Radio Access Technologies. More complexity has
been added through Cloud computing and virtualization in which
services might change their physical location within a virtualized
architecture, too. In regards of current research and develpment on
Mobile Edge Cloud and 5G, high availability, low delay and ultra high
bandwidth requirements are required for a massive amount of
communuicating instances ranging from cellulars, high-definition
multimedia streaming, Internet-of-Things (IoT), critical
infrastructures among others.
IP has been overloaded and used at teh same time for locator and
identifier. requirements: efficient routing, scalability, mobility,
security lead changesin the design principles on decoupling Locator-
Identifier wihtin IP.
This specification describes Mobility Management Architecture for 5G
Networks Using Identifier-Locator Addressing (ILA) ([nvo3]) in IPv6
for virtualized mobile telecommunication networks. Identifier-locator
([nvo3]) addressing differentiates between location and identity of a
network node. The approach presented in this draft enables mobility
management on Layer 3, provides a simplified and more efficient
architecture, less core network utilization.
The concept of ILA extends the Identifier-Locator Network Protocol
(ILNP) ([RFC6740], [RFC6741]) defines a protocol and operations model
for identifier-locator addressing in IPv6.
1.1 Terminology
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].
The following terminology will be referred to in the document.
* ILA ID or only ID: unique identifier in ILA terms - not used public
and only used for GUTI creation for each new attachment. The
International Mobile Subscriber Identity (IMSI) can be used for ID
generation.
* ILA host: An end host that is capable of performing ILA
translations for both sending and receiving. An ILA host uses the
Mueller, Herbert Expires January 7. 2017 [Page 4]
INTERNET DRAFT <draft-mueller-ila-mobility>
ILA resolver protocol to get identifier to locator mappings for
destinations in communication.
* ILA router: A network device that performs ILA translations. ILA
routers participate in a mapping distribution protocol.
* Globally Unique Temporary UE Identity (GUTI): temporary address
considered as a temporary ILA ID.
* ILA Locator (LOC): either International Mobile Equipment Identity
(IMEI) or an IP address that has been assigned to a single UE.
* User Equipment (UE): device with identifier such as a mobile phone
or IoT gateway.
* Access Point (AP): Base station, evolved-NodeB (eNB) in 4G.
* Gateway (GW): Gateway, e.g. Serving-Gateway (SWG) or Packet-Data-
Network-Gateway (PGW) in 4G.
* Application Function (AF): refers to the 3GPP terminology and
stands for any IP service.
2 Motivation There is increasing demand for improved connectivity for a
growing number of devices including IoT, mobile phones, cars, etc. 5G
networking is intended to address access and core bottlenecks to
provide for lower lower latency, higher throughput, and greater
number of connected devices. There are several challenges in
applying Mobile-Edge-Computing (MEC) concepts due to Layer 2
tunneling and signaling overhead. The following architecture is
based on a layer 3 design that obviates the need for layer 2
tunneling and signaling overhead. The design decisions and call flow
outline an approach using ILA for mobility management in 5G networks
that overcomes challenges of legacy networks. A flatter network
architecture as well as optimizations in the data and control path
are presented, which result in a shorter communication path and
therefore lower delay.
3 Related Work, Protocols and Concepts This section provides an
overview on of the state-of-the-art on related Work, protocols and
concepts for mobility management on mobile networks. In particular
the 4th Generation (4G) of mobile telecommunication networks has been
taken into comparison for this draft.
3.1 Mobile IPv6 The IETF specified Mobile IPv6 to ensure connectivity
and reachability in case of client mobilty within an IPv6 network.
Mueller, Herbert Expires January 7. 2017 [Page 5]
INTERNET DRAFT <draft-mueller-ila-mobility>
Mobility is solved by assigning an additional IPv6 address - the
Care-of-Address (CoA) - next to the current IPv6 address that as been
assigned in the home network. Therefore a UE is equipped with a home
address, plus primary CoA in case of foreign network attachment. IPv6
is classified as host-based mobility protocol, due to the fact, that
the UE is in charge of announcing its mobility to the network. In
particular it is the clientresponsibility for signalling binding
update signaling to HA. In order to ensure reachability, the UE
communicates its new assigned CoA to the Home Agent, which acts as a
router and registrar for UEs. Connection requests are intercepted and
re-routed in case CoA entries for a UE exists. A tunnel is
established between the UE at the CoA and the HA for securely
exchanging packets. Per default, the first packet is routed from the
correspondent UE towards CoA of the UE via the HA. All consecutive
packets will follow on the same path, which might include a detour,
but hides the new location of the UE for privacy reasons. The feature
of route optimization allows the UE to directly contact the
correspondent UE, therefore cuts out the HA from the communication
path and forwards packets on a shorter route. Security of the Mobile
IPv6 is enhanced through IPSec for binding updates to avoid spoofing
of CoA for a UE.
3.2 Proxy MobileIPv6 The IETF specified Proxy Mobile IPv6 provides
network-based mobility management for UE and extends the Mobile IPv6
in the way, that host-based mobility management functionalities in
Mobile IPv6 are excluded from the client into the network in Proxy
Mobile IPv6. The Local Mobility Anchor (LMA) acts as topological
anchor point and manages the UE's binding state. The Mobile Access
Gateway (MAG) manages the mobility-related signaling on behalf of a
UE at the access router. It is responsible for tracking the UE's
movements to and from the access link for signaling the UE's local
mobility anchor.
3.3 Host Identity Protocol (HIP) HIP ([hip]) is provising a secure
solution for identifier/locator-split by adding a new host identity
layer into protocol stack. A cryptographic namespace build upon a
host identity as public key allows scalability and multi-homing
within the network. An extensions of DNS supports rendezvous server
functioanlity for secure host identity lookup. A secure channel is
establishment over Diffie-Hellmann-key exchange between two
communicating entities. The communication setup is considered as
robust against DOS, due to a riddle solved at the requestor side. On
the other side a high overheaed for the secure communication
establishment due to key exchange has to be taken into
consideration.
Mueller, Herbert Expires January 7. 2017 [Page 6]
INTERNET DRAFT <draft-mueller-ila-mobility>
3.4 Locator/ID Separation Protocol (LISP)
https://tools.ietf.org/html/rfc6830 network-layer-based protocol that
enables separation of IP addresses into two new numbering spaces:
Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) tunnel
router encapsulates and decapsulates packets
3.5 ILNP
3.6 Identifier-Locator Addressing (ILA) * reduced header size * MN -
Network Virtualization Edge * NVE creates and maintains local state
about each Virtual Network for which it is providing service on
behalf of a Tenant System.
3.7 Comparison of ILA to alternative approaches
This section compares the ILA approach to some alternatives that have
been discussed in 5gangip list.
3.7.1 ILNP
Identifier Locator Network Protocol (ILNP [RFCXXXX]) is an
experimental protocol that splits and IPv6 address into a locator and
identfier. ILA is fundamentally based on ILNP.
The key differences between ILA and ILNP are:
* ILNP requires changes to the transport layer. This limits ILNP
to be used only on hosts and every transport protocol
implementation would need to be modified to use ILNP. Presumably
to overcome the limitation above, some sort of ILNP proxy could
be defined to perform ILNP in a middlebox.
* ILA does not require changes to the transport layer.
* Checksum neutral translation means that transport layer does not
need to be parsed to perform ILA. This also ensures that
existing device offloads (like checksum offload) work
seamlessly.
* ILNP employs IPv6 extension headers which are mostly considered
non-deployable. ILA does not use these.
* Core support for ILA is in upstream Linux, to date there is no
publically available source code for ILNP.
* ILNP involves DNS to distribute mapping information, ILA assumes
mapping information is not part of naming.
Mueller, Herbert Expires January 7. 2017 [Page 7]
INTERNET DRAFT <draft-mueller-ila-mobility>
3.7.2 LISP
Locator Identifier Separation Protocol (LISP [RFCXXXX) is an IP
encapsulation protocol where the destination address in the outer IP
header is a locator and the destination address in the inner header
is an idnetifier.
The key differences between ILA and LISP are:
* ILA is not encpasulation so there is not associate encapsulaiton
overhead. For instance IPv6/IPv6 in LISP would have 52 bytes of
overhead whereas ILA translation has zero.
* LISP may not work with some network device offloads whereas ILA
works with all stateless offloads (ILA is transparent to the
network so that it would just see TCP/IP packets for instance).
* ILA has been accpeted into Linux, LISP has not been accepted.
* ILA can run either on end hosts (ILA hosts) or in the network
(ILA routers). In ILA hosts the mapping database is a cache to
optimize communications.
* ILA defines locators and identifiers to be 64 bits whereas LISP
allows them to be full 128 bit address making for for memory
needed in mapping table.
* ILA is not encpasulation so there is not associate encapsulaiton
overhead. For instance IPv6/IPv6 in LISP would have fifty-six
bytes of overhead whereas ILA translation has zero.
* The process of ILA translation is much more efficient than
performing LISP. The translation path is:
1) Parse IP header and extract the destination address
2) Lookup destination in a hash table (obviated with cached
route for ILA hosts)
3) Write new destination address (16 byte copy)
4) Forward to new destination (or receive at final destination).
LISP processing is more involved. To do encapsulation an outer
IP header, UDP header and LISP header need to be inserted.
Tunnel fragmentation and MTU need to be considered [RFCXXXX]
(i.e. increasing the size of a packet may exceed tunnel MTU). At
the remote tunnel end point, the outer IP header must be
Mueller, Herbert Expires January 7. 2017 [Page 8]
INTERNET DRAFT <draft-mueller-ila-mobility>
validated and aa lookup done on the destination address to see
if it is a local address . A lookup must be done on the
destination UDP port to find that it is a LISP port. If the UDP
checksum is not zero that must also be validated. The LISP
header must also be processed. Once the encapsulation is
verfied, the headers are removed and the inner packet is either
forwarded or received.
3.8 Taxonomy & Summary Comparing solutions above in a taxonomy and
compare them using the following parameters:
* multi-homing? * multi-path? * IP-session continuity: all three
* seamless handover or transparent handover? Attached with same
or different interface * state - number and positions * overhead
through tunneling or header extension * client mobility support
and efficient update of location information in the network *
number of functional elements in the architecture
4 Mobility Management Architectures for 5G Network Using ILA This
section outlines the architecture supporting ILA in mobile
networks. The main functional blocks for connectivity, mobility
support, security and charging are presented. Message flows for
basic use cases executed by the mobile UE such as attachment,
data transport with session handover and detachment are
outlined.
4.1 Address format for ILA mobile
The address format is derived out of the ILA draft in ([nvo3]).
/* IPv6 canonical address format */ | 64
bits | 64 bits | +-------
-------------------------+-------------------------------+
| IPv6 Unicast Routing Prefix | Interface Identifier
| +--------------------------------+-----------------------
--------+
/* ILA for IPv6 */ | 64 bits
|3 bits| 61 bits | +------------------------
--------+-------------------------------+ |
Locator | Type | Identifier | +-----
-----------------------------------------------------------+
4.2 Architecture with functional elements and reference points
Mueller, Herbert Expires January 7. 2017 [Page 9]
INTERNET DRAFT <draft-mueller-ila-mobility>
The presented architecture is aligned on the 3GPP Evolved Packet
System ([23.401], [23.402]) following the separation of control
plane and data plane. Whereas 3GPP EPS addresses mobility
through Layer 2 tunneling with GTP, this approach provides a
Layer 3 mobility approach utilizing the ILA concepts for
mobility.
TODO: architecture bootstrapping: which entity assigns ILA
address space for LOC and ID?
4.3 Functional Elements
* The User Equipment (UE) is the mobile device (cellular or
laptop) executing services such as apps on the device, binding
apps to the ID as communication endpoints, handling the bindings
of all associated LOC/ID's and performing mobility as described
below. The UE performs security related functions via its
(Embedded) SIM handing at least one or multiple identifiers
provisioned by one or multiple network operators. Security
related functions include authentication of the UE towards the
network (more specifically the AP) and certificate management
for establishing secure transport connections. Either the UE
supports IPv6 or ILA for handling locator and ID bindings and
updates or the etwork is handling ILA functionality on behalf of
the UE. Storage and management of multiple locators for multi-
path and multi-homing is supported by the UE support.
* The Access Point (AP) is the first point of contact from the
UE when attaching over radio to the network. Its main purpose is
routing, gating and forwarding data and control packets. The
Radio Access Technology (RAT) is independent of the proposed
concept and therefore out of scope of this document. 3G, 4G, 5G
or WiFi are applicable RATs. The AP is also capable of caching
for Content-Centric-Networks (CCN) TODO:LINK like apps, in order
to store content or host service instances close to the user at
the edge of the network. Another aspect of the cache is to
support transparent handovers, during which buffering of packets
at the target AP is required. Therefore a X2-like connection
between APs is required. The AP supports a support a policy
enforcement function (PEF) as well as a Event Reporting Function
(ERF) aligned on the 3GPP defined Policy Control and Charging
(PCC) functionality for the EPS in ([23.203], [29.212]). Uplink
QoS management is handled by the AP, too. In order to
differentiate between multiple types of data traffic, signaling,
high-priority, real-time and non-real-time connections can be
Mueller, Herbert Expires January 7. 2017 [Page 10]
INTERNET DRAFT <draft-mueller-ila-mobility>
distinguished and the order of packet processing in the AP can
be influenced for uplink. The same concept applies for downlink
in the GW. Forward Error Correction (FEC), IP header
compression, encryption of user data stream are supported by the
AP, too.
* The Gateway (GW) encompasses management and policy enforcement
functions as well. Its main purpose is routing, gating and
forwarding data and control packets. Therefore functionalities
such as downlink QoS enforcement, APN management and charging is
performed by each GW.
* The Mobility Management Entity (MME) handles the initial
authentication, authorization and mobility management of UE's
over the control plane. The MME is responsible for tracking the
UE's mobility and is in charge for updating the registries with
near real-time status updates for LOC/ID mapping. ID and LOC
assignment are performed by the MME.
* The Home Subscriber Server (HSS) stores and manages user
profile information. These include the static information such
as the assigned ID, security credentials as well as dynamic
information LOC and the current Tracking Area.
* The Policy Charging Rules Function (PCRF) controls data flows
in the network architecture according to pre-defined rules. Such
rules can be created by the network operator such as an upper
limited for the data rate or total bytes transferred given a
time interval (e.g. 2GB per month data plane with unlimited
speed and a reduction of bandwidth after reaching the limit of
2G). Other rules differentiate between class of services for
various traffic flow types identified on their Traffic Flow
Template (TFT) characteristics such as source, destination, port
and protocol information. The PCRF is handling charging for
traffic flows using online (pre-paid) and offline (post-paid)
charging. Both charging modes include a charging based on
metrics such as service invocations, online time, data
transferred, or no-charging. Out of credit events may influence
the current connectivity for online charging, whereas offline
charging is accumulating charging records which are usually
processed in a monthly period.
* The Access Network Discovery and Selection Function (ANDSF) is
Mueller, Herbert Expires January 7. 2017 [Page 11]
INTERNET DRAFT <draft-mueller-ila-mobility>
a database used for mapping the user location with available
access networks. With this information, the ANDSF is capable of
signaling suggestions for handovers to UE's. A UE is therefore
able to operate only on one interface at a time to save
resources. In case of the availability of adjacent RAT and after
reception of a handover suggestion from the ANDSF, the UE is
able to enable the suggested interface, perform a scan and
finally decide whether or not to attach to the new targeted RAT.
The database can be filled using device monitoring/telemetry
statistics signaled from the UE to the network or by active
measurements of the environment.
TODO: OPEN - assignment to Functional Elements needed *
filtering * gating * legal interception on the AP, to include
the case, in which traffic re-routed only by the AP and is not
traversing the GW.
4.4 Signaling and data flow
4.5.1 Provisioning A Subscriber Identity Module (SIM)-card is
provisioned by the network operator with a unique ID, that is
comparable to the IMSI in 3GPP telco architectures (2G, 3G and
4G). This draft is no differentiating between a physical or an
embedded SIM. The ID unambiguous identifies the UE within the
global network, is used for identification, authentication,
authorization and charging purposes. In addition, security
credentials and preferred network identifier are provisioned for
authentication as well as network selection are provisioned. The
matching information to the SIM card is stored in the HSS.
4.5.2 Attachment After powering on the device, a scan for available
networks is performed on the device, which selects the network
with the strongest signal and performs a network attachment
procedure aligned with ([23.401], [23.401]) towards the Access
Point (AP) using security parameters, ID, last MME associated
with (GUMMEI) and last GUTI assigned by MME with ID GUMMEI - the
Packet Temporary International Mobile Subscriber Identity (M-
TSMI).
For each network attachment and due to privacy concerns for not
revealing the identify of the UE towards the public, a creation
of a Globally Unique Temporary UE Identity (GUTI) is performed.
The AP derives the last MME association out of the network
attachment request sent by the UE and queries the last or a new
Mueller, Herbert Expires January 7. 2017 [Page 12]
INTERNET DRAFT <draft-mueller-ila-mobility>
MME based on availability of information for UE authentication.
The MME performs a lookup in the user database of the network
operator, which is the Home Subscriber Server (HSS) and/or Home
Location Register (HLR) and receives a profile in return.
In the following, the MME selects and configures the AP and GW
according to the profile received and signals the profile
including the GUTI towards the AP and GW.
The AP allocates a LOC for the UE, binds the GUTI-LOC
combination locally in a cache, publishes its binding in the MME
and signals the GUTI-LOC towards the client.
Quality of Service (QoS) and charging related policies are
installed in the AP and GW. The AP handled uplink and the GW
downlink related traffic shaping functions. Charging can be
performed in both functional elements (AP or GW), whereas a
centralized charging in case of multi-path streaming is
preferred.
4.5.3 Communication scenarios for data transport for an End-to-End
session After the successful attachment, a service can be
invoked. There are three main data path to be considered, to
address all use cases. The use cases can be distinguished
between a UE accessing a service in the AF. A UE is
communicating with another UE. The example use cases below
outline the details and point out the differences compared to
today's networks.
TODO: Include schema as in nvo3 - 5.3 Reference network for
scenarios
1) UE to AF through the complete network
Considering a communication scenario in which a UE queries a
website ("http://about.att.com/innovation/foundry") in a
browser. An ID is retrieved in return from the DNS.
UE[Task UE_T1] -> DNS // request ID for URL DNS -> UE[Task
UE_T1] // ID for URI
The sequence for traversing the network looks as follows.
UE(GUTI/LOC):[Task UE_T1] <-> AP <-> GW <-> AF[Task AF_T1]
Mueller, Herbert Expires January 7. 2017 [Page 13]
INTERNET DRAFT <draft-mueller-ila-mobility>
The request is forwards to the AP, which performs ILA router
functionality and a lookup in a local lookup table. Depending on
finding an entry in the local lookup table, the routing is
influenced and the packet is redirected. Otherwise routing on
the initial destination LOC/ID is fulfilled.
2) UE_1 to UE_2 attached to distinct APs
UE1[Task UE1_T1] <-> AP_1 <-> GW <-> AP_2 <-> UE2[Task UE2_T1]
Considering a communication scenario in which one mobile device
(UE1) is contacting a second mobile device (UE2). ILA routing is
done in the AP. TODO: Classic signaling and data flow similar to
legacy networks.
3) UE_1 to UE_2 attached to the same AP
UE_1[Task UE1_Tx] <-> AP <-> UE_2[Task UE2_Ty]
Considering a communication scenario in which two communicating
entities are attached to the same AP and therefore are in close
proximity. The solution for routing traffic in todays network is
the establishment of the datapath from the UE over the access
network (e.g. eNB) into the core network (e.g. EPC) and back to
the access network and finally to the UE. Charging needs to be
performed in the AP for this data flow. This communication
pattern creates a delay caused by the bearer concept of 3GPP
network, which encapsulate and de-apsulate data in Layer 2
tunnels between the eNB and the PGW.
4) UE to Mobile Edge Cloud (MEC) UE[Task UE_T1] <-> DNS
Considering a communication scenario in which a Virtual Reality
(VR) application on a smartphone is accessing a low-delay
service in the network e.g. an image recognition service. In
order to provide a high quality of experience for the user, the
delay between the mobile device and the service should be
reduced.
Firstly, a DNS lookup resolves the URL into a ID to identify the
closest service instance. The lookup process may be resolve to a
service co-located at the AP or trigger the deployment of that
service instance within a datacenter co-located or attached to
the AP.
A request is created and addressed with the source LOC/ID and
Mueller, Herbert Expires January 7. 2017 [Page 14]
INTERNET DRAFT <draft-mueller-ila-mobility>
targeted towards the destination LOC/ID.
The sequence for traversing the network looks as follows.
UE[Task UE_T1] <-> AP <-> AF[Task AF_T1]
5) Summarizing, the use of ILA for mobile reduces allows
multiple improvements compared to legacy telecommunication
networks. Firstly, the improved datapath has less hops to
traverse between UE and AF or UE_1 and UE_2 due to the flatter
architecture. Secondly, the less overhead is created due to the
reduction of GTP tunnels between network elements. Thirdly, the
more efficient routing reduces the core network traffic by
routing traffic particularly locally and avoiding re-routing and
traffic forwarding through the complete core network, even in
scenarios, in which the communication partner are in close
proximity and attached to the same AP. lower delay, which is one
critical requirement for 5G networks.
4.5.4 Homogeneous Handover Client mobility using the same access network
technology due to location changes is referred to as homogeneous
handover. Triggers for homogeneous handover may be changes in
signal strength at the UE or network based handover due to
network policies such as load balancing.
The status information (the list of signals received from
adjacent APs including their signal strength) signaled from the
UE towards the AP indicates its position via triangulation as
well as the alternative AP's to which the UE may connect to.
Reasons for handovers may be evacuation/preemption of resources
on the AP due to emergency scenarios or higher priority calls,
UE/AP/service load balancing or physical mobility of the UE
among the network. The current resource utilization (e.g. data
rates) of the UE or historical traffic pattern may influence the
handover and the AP selection process.
The MME selects a new AP (AP_new) as target for the handover of
the UE away from the current AP (AP_current). The decision is
signaled to related AP's and the UE. AP_current starts de-
allocating resource blocked by the UE and AP_new blocks
resources required by the UE. Since most UE's are considered to
have only a single RAT of each type (one WLAN or one LTE
interface) an interruption in the connection while handover is
to be expected. In order to avoid packet loss at the UE,
buffering at the AP_new as well as packet forwarding from
AP_current to AP_new are supported. Only after UE successfully
Mueller, Herbert Expires January 7. 2017 [Page 15]
INTERNET DRAFT <draft-mueller-ila-mobility>
establishes connectivity at the AP_new, previously blocked
resources at AP_current are freed up, which are used as handover
role-back in case of failure. Finally the MME announces the new
LOC(AP_new)/ID for the UE as an update at GW and in the DNS.
New incoming connections are forwards directly towards the UE
over AP_new using the proclaimed LOC/ID.
4.5.5 Heterogeneous Handover Client mobility may involve various Radio
Access Technologies (RAT), in which the client is handed off
from RAT_1 to RAT_2. The client is not required to move
physically for heterogeneous mobility. Instead measurements on
the UE or suggestion from the network over the ANDSF may trigger
handovers even when the UE is physically not moving.
Heterogeneous handover may be motivated for optimizing
connectivity between UE and a service to move a multimedia
connection with high bandwidth requirements from cellular
towards WLAN or a security sensitive bank transaction from WLAN
towards cellular.
Heterogeneous (compared to homogenous) handovers may be
performed seamless with establishing a second alternative
connection in parallel to the existing and tearing down the old
connection, after successfully establishing the new connection.
In order to provide higher bandwidth over multi-path, both
connections may be kept open in parallel. In this regard, the
MME adds another LOC'/ID as update to the existing entry LOC/ID
in the registry on the gateways and DNS.
4.5.6 Detachment A detachment from the network can happen gracefully by
shutting down the phone and de-registering it from the AP or
suddenly due to a loss of connection. In both situations, a de-
registration from the UE out of the list of active users
attached to the AP is done directly or indirectly (after
inactivity for a predefined timeframe). Resource reservations
are freed up again after detachment.
4.6 TODO: Other cases idle mode, paging
Emergency call support
Connectivity between UE and AF
Connectivity between UE and other UE
Mueller, Herbert Expires January 7. 2017 [Page 16]
INTERNET DRAFT <draft-mueller-ila-mobility>
Similar AP or TA
Distinct AP or TA
5. Discussion Backwards compatibility
IP address allocation split into locator and identifier part
loc at attachment via MME/GW
id at attachment via AP/MME
<Document text>
Definitions and code {
line 1
line 2
}
Special characters examples:
The characters , , ,
However, the characters \0, \&, \%, \" are displayed.
.ti 0 is displayed in text instead of used as a directive.
.\" is displayed in document instead of being treated as a comment
C:\dir\subdir\file.ext Shows inclusion of backslash "\".
Mueller, Herbert Expires January 7. 2017 [Page 17]
INTERNET DRAFT <draft-mueller-ila-mobility>
3 Security Considerations
<Security considerations text>
4 IANA Considerations
<IANA considerations text>
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI
10.17487/RFC1776, April 1 1995, <http://www.rfc-
editor.org/info/rfc1776>.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI
10.17487/RFC1925, April 1 1996, <http://www.rfc-
editor.org/info/rfc1925>.
5.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, DOI 10.17487/RFC3514, April 1 2003,
<http://www.rfc-editor.org/info/rfc3514>.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009,
<http://www.rfc-editor.org/info/rfc5513>.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI
10.17487/RFC5514, April 1 2009, <http://www.rfc-
editor.org/info/rfc5514>.
Authors' Addresses
Dr.-Ing. Julius Mueller
260 Homer Ave
Mueller, Herbert Expires January 7. 2017 [Page 18]
INTERNET DRAFT <draft-mueller-ila-mobility>
Palo Alto, CA 94301
US
EMail: jmu@att.com
and
Tom Herbert
Facebook
1 Hacker Way
Menlo Park, CA 94052
US
Email: tom@herbertland.com
Mueller, Herbert Expires January 7. 2017 [Page 19]