Handover with no or limited MME involvement

Field of t e invention

The present invention relates to an apparatus, a method, and a computer program product related to handover. More particularly, the present invention relates to an apparatus, a method, and a computer program product related to a simple handover, e.g. in sliced networks and/or 5G networks.

Abbreviations

3G 3 ^rd Generation

3GPP 3 ^rd Generation Partnership Project

4G 4 ^th Generation

5G 5 ^th Generation

Ack Acknowledgment

AM Access Mediator

AM-C Access Mediator - Control plane

AM-U Access Mediator - User plane

ARP Address Resolution Protocol

auth Authentification

BFNMN Brute Force No Mobility Network

CAPEX Capital Expenditure

CLR Client Location Register

DB Database

DF Discrimination Function

DHCP Dynamic Host Configuration Protocol

DL Downlink

DNA Dynamic Network Access

eNB evolved NodeB

EPC Evolved Packet Core

E-RAB E-UTRAN RAB

ETH Ethernet

E-UTRAN Evolved UMTS Terrestrial RAN GLAN Global LAN

GPRS Generic Packet Radio Service

GTP GPRS Tunneling Protocol

HD/4k High Definition/4k

HO Handover

HOO HO optimization

ID Identifier / Identification

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IMSI International Mobile Subscriber Identity

IP Internet Protocol

IT Information Technology

L2 Layer 2 (of OSI layer model)

L3 Layer 3 (of OSI layer model)

LAN Local Area Network

LTE Long Term Evolution

LTE-A LTE Advanced

MAC Medium Access Control

M-Ctrl Mobility Control

MME Mobility Management Entity

MUX Multiplexer

NAS Non-access stratum

NAT Network Address Translation

OAM Operation and Maintenance

OF Open Flow

OPEX Operational Expenditure

OSI Open Systems Interconnection

OTT Over-the-top

PDCP Packet Data Convergence Protocol

PGW Packet Gateway

PLMN Public Land Mobile Network

QoE Quality of Experience

RAB Radio Access Bearer

RAN Radio Access Network

Rep Reply

Req Request RLC Radio Link Control

RTB Radio-Terrestrial Binding

SA System Architecture

SDN Software defined Network

SGW Serving Gateway

S-MME Slice MME

TCO Total Cost of Ownership

TCP Transmission Control Protocol

TIMSI Temporary IMSI

TRA Transport (network)

TS Technical Specification

UE User Equipment

UL Uplink

U-MME Umbrella MME

UMTS Universal Mobile Telecommunications System

VNF Virtual Network Function

Background of the invention

5G networks provide new network services, most prominently additional bandwidth allowing for HD/4K videos and low latency services allowing for car-to-car communication and industrial applications.

However, low latency services are not limited to those domains. Likely, new consumer services requiring both, high bandwidth and low latency are dooming up. Thus, future networks will be confronted with massive demands for bandwidth and low latency at the same time. Today's 4G core / packet core network architecture does not allow for low latency end-to-end data transmission since it is built on a gateway philosophy where all traffic has to be conveyed through few points in a network leading to expensive deployments and leading to tromboning effects that exclude low latency services.

There is a variety of approaches discussed in standardization and there also exist approaches for IT centric approaches outside 3GPP how to address this issue. However, besides all technical problems there still is a very stringent factor which is often not taken into consideration in all technical discussions which is the fact of costs or total cost of ownership (TCO), respectively. Future solutions for conveying traffic through 5G [packet] core networks must also be economically viable, especially in mass market solutions.

Two approaches (BFNMN and GLAN) are described further, both aiming to provide low latency and high bandwidth end to end connectivity through a mobile network at lowest possible costs by reducing the efforts spent on mobility management.

Brute Force No Mobility network (BFNMN)

This approach simply provides no mobility in cellular networks. Ever when devices change the point of attachment (e.g. at handover), ongoing sessions will not only suffer packet loss but also lose their IP address: Devices will be assigned a local IP address from the eNodeB or an MME each time a terminal connects.

The philosophy relies on that many popular WEB applications such as YouTube, WhatsApp, FaceBook and more can overcome changes of IP addresses in running sessions (see Fig. 1 ). As may be seen in Fig. 1 , a UE (e.g. with MAC address 00:80:42:ee:fd:76d) may roam through different IP networks, each with an own DHCP server. Accordingly, the UE has a different IP address (e.g.192.168.1 .4, or 1 1 .13.25.12, or 10.1 .23.45, or 53.88.17.3) in each of the IP networks.

To a certain extent, mobility is carved out towards the application. The disadvantages of this approach are, of course, that it is restricted to specific applications only and not generally suitable, and the session cannot continue prior to assignment and advertising of the new IP address to peers - which, following the dynamics of cellular networks (attach) and IT networks (DHCP, DNA) may take several hundred milliseconds. The benefit of this approach is indeed that direct (or almost direct) peer-to-peer connections can be established based on pure IP routing, avoiding delays by not conveying traffic through distinct gateways.

Mobility Aware Transport Network (GLAN: Global LAN)

The basic principle of this approach is that the transport network has a basic awareness of the connected nodes devices (see Fig. 2). Since more and more software defined network nodes (SDN) are used in the transport domain, the pure data forwarding can be decoupled from the control plane which may run in data centres. This way the transport plane can be realized on any layer since what makes a node appear as a switch or a router is given by the according control software (app) in the cloud. Most preferably, a transport network is appearing as a layer 2 network since packet forwarding in most IT domains (home, enterprise) world is done on layer 2 (LAN, MAC address).

However, GLAN does not mandate an end-to-end layer 2 network and it does not demand for any forwarding node being based on SDN. Rather selected access mediator nodes (AM-U, hashed in Fig. 2 and corresponding figures) will offer specific packet header modification capabilities (as SDN allows for). However, those nodes are standard SDN forwarding nodes which forward the payload (U-plane) based on rules for header modification provided by a corresponding control application (AM-C) in a data centre via an SDN controller. Those rules are stored in local forwarding tables at said AM-Us.

Mobility awareness is then provided with the granularity of the existence of such nodes in a network. Most beneficially, the granularity level is following the size of local L2 domains, e.g. one AM-U LAN network, i.e. AM-Us can be co-located or may replace existing access routers e.g. in enterprise networks - by this, the full L2 spanning tree of existing LANs can be used to forward packets. AM-U/AM-C will detect whether attaching hosts are changing their point of attachment within the boundaries of an AM-U/AM-C controlled domain (LAN) or not. In the first case, AM-U/AM-C will report the host's IP address and the affected (target) AM-U MAC address to a client location register (CLR): This data base will store host-IP/connected AM-U MAC address contexts of all hosts that are part of the GLAN controlled network. Ever when a host (UE, device) attaches to a network, it will send a "gratuitous ARP" message allowing AM- U/AM-C to detect whether or not a host has changed the AM-U controlled domain. When hosts communicate with other GLAN-hosts at other AM-Us from which they did not know the IP address the hosts will send data packets to the connected AM-Us MAC address (which they received via ARP-request). The AM-U/AM-C will interrogate the CLR about the peering AM-U the peer host is connected to and perform according packet header modifications (replacing the MAC address of packets sent by the host to the peer host with the MAC address of the peer AM-U). Those packet modification rules are stored in the AM-U's forwarding table configured by an SDN controller steered by the AM-C. Additionally, the SDN controller can modify the forwarding tables of all SDN transport nodes that are/should be involved in the end- to-end data forwarding chain and thus provide shortest path connections.

A major difference to the BFNMN approach described above is that all nodes can keep their IP addresses regardless of where in the global network they attach to. All connected hosts consider the complete end-to-end network appear as on single LAN or as a global LAN (GLAN). This is shown in Fig. 2, wherein the UE moving along the same path as in Fig. 1 , keeps its IP address 192.168.1 .4 at all locations, irrespective of the different DHCP servers.

Network Slicing

Network slicing (in particular: 5G network slicing) is an important method allowing operators to tailor their network deployments according to various different criteria. It allows to run 3G/4G/5G networks in parallel without impacting the performance of the respective other networks, it also enables deployments based on different architectural principles so they can best match requirements for given services. Fig. 3 shows a possible scenario based on network slicing: based on requests from the service logic (service orchestrator), a network orchestrator may setup or modify a specific slice with its own resources (servers, virtual network functions VNF). In the example, there are specific slices for smartphones, loT devices and mission critical services. The assignment of a service to a specific network slice is done via an umbrella MME (U-MME) to which a device will connect upon [initial] attach. The U-MME will detect the service type (e.g. based on identifiers, in simplest case based on IMSI) and then redirect to an MME of the according slice (S-MME) in which it remains until the session is finished.

The methodology of network slicing also allows for running new, disruptive architectural deployments outside 3GPP for given use cases (as e.g. the two examples shown above) without impacting the rest of the network.

In order to reduce TCO significantly even if services requiring low latency and high bandwidth come up, it is required that existing networks can be used unmodified (transparency) and that specific mobility related signalling is avoided (NAS, EPC-control plane). On the other hand, the same devices that are used in mobile networks must be served unmodified. This requires that UE - eNodeB signalling is not effected - which to some extent means squaring the circle.

A balanced mobility support may be required. Simple approaches are based on a pure break- before-make philosophy (such as BFNMN), assuming that packet loss during handover is fine for most applications since those can recover end-to-end on TCP layer. However, this might reduce the applicability to a few use cases only and may make it difficult to harvest the full potential of these approaches (like shortest path to allow for low latency). A balanced mobility support, ranging from full break-before-make to [almost] no packet loss during handover would allow to toggle service demands vs. TCO in future networks. 5G services demand for function splits that significantly differ from those of a 4G network - technical solutions are addressed in 3GPP standardization. However, TCO aspects may motivate network operators to include also networking principles that are coming from the IT domain rather than from 3GPP. If high bandwidth services with low latency demands appear as a mass user service (which sooner or later may happen, likely as over-the-top [OTT] service), there will be the need to handle certain traffic/service types without significant signalling or network control in order to reduce costs. Since control plane functions, especially mobility related control plane functions, make up a significant part of CAPEX and OPEX (servers, data centre resources, maintenance), simple approaches avoiding mobility related control may come into focus. In this context, the two examples of BFNMN and GLAN are to be seen as possible implementation options allowing to implement a far more cost effective network for selected services.

Since these simple approaches somewhat exist between pure IT networks and 3GPP networks it is unlikely that those are fully standardized in one of the according standardization bodies (3GPP, IEEE, IETF) since there is a strong "inside the box" thinking in any of these - but this does not mean that these approaches won't happen. Therefore, it seems appropriate to take care that related standards do not exclude such approaches and care should be taken to work on the hooks/switches, e.g. at 3GPP SA 2.

Fig. 4 shows conventional RTE for e.g. a 3GPP LTE eNodeB (only U-plane). Each PDCP context UEs may have with an eNodeB represents a radio bearer or radio link, respectively which, within the PDCP context, is referenced by an E-RAB-ID. Uplink IP packets, that are conveyed from the UE towards the network, are put into a GTP tunnel which itself is on top of a UDP/IP connection. Vice versa, downlink IP packets are put out of the GTP tunnel and send via the according PDCP context to the UE. Note that GTP tunnel setup/tear down is done by a C-plane protocol stack which is not shown in Fig. 4. These C-plane dialogs interact with entities deep in the network (NAS-signalling with MME, P-Gw, ...). One UE may have several bearers that are connected via different PDCP contexts.

Summary of the invention

It is an object of the present invention to improve the prior art. According to a first aspect of t e invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform retrieving a target address of an internet protocol from a header of a first downlink packet of the internet protocol received by a source cell, wherein the first downlink packet is addressed to the target address, and the first downlink packet comprises the header and a payload; determining a radio access bearer identifier associated to the target address; identifying a terminal address of the internet protocol based on the target address; instructing to forward the terminal address and the payload of the first downlink packet in a packet data convergence protocol context on a radio bearer identified by the radio access bearer identifier.

The identifying may comprise identifying the terminal address based on a port number, wherein the target address may comprise the port number; and the determining may comprise determining the radio access bearer identifier based on the port number.

The terminal address may be the target address.

According to a second aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform retrieving a terminal address of an internet protocol and a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer; forming an internet protocol packet comprising a header and the payload, wherein the header comprises an origin address of the internet protocol as an origin; instructing to transmit the internet protocol packet, wherein the origin address is the terminal address.

According to a third aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform retrieving a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer, wherein the uplink packet comprises the payload and a terminal address of an internet protocol; identifying an origin address of the internet protocol based on an identifier of the radio access bearer; forming an internet protocol packet of the internet protocol comprising a header and the payload, wherein the header comprises the origin address as an origin; instructing to transmit the internet protocol packet.

The identifying may comprise identifying a port number based on the identifier of the radio access bearer; and the origin address may comprise a predetermined cell address of the internet protocol and the port number.

Plural radio access bearers with different identifiers may be configured in the source cell, and the cell address is independent from the respective identifier of the radio access bearer.

The origin address may be the terminal address.

According to the first to third aspects, the at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform monitoring if a request to handover a terminal to a target cell is received in the packet data convergence protocol context, wherein the target cell is identified by a target cell identifier and the terminal is identified by a radio identifier, and the target cell identifier and the radio identifier do not belong to the internet protocol; requesting a target cell address of the target cell from a data repository based on the target cell identifier, wherein the target cell address is of the internet protocol; forming a handover preparation packet of the internet protocol directed to the target cell address, wherein a payload of the handover preparation packet comprises the terminal address and the identifier of the radio access bearer; instructing to transmit the handover preparation packet to the target cell address.

According to the first to third aspects, the at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform inhibiting the source cell to instruct the terminal to handover to the target cell; checking if an acknowledgment of the handover preparation packet is received from the target cell; cancelling the inhibiting of the source cell to instruct the terminal to handover to the target cell if the acknowledgement is received.

According to the first to third aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform monitoring if an second downlink packet of the internet protocol addressed to the target address is received by the source cell after the terminal was instructed to handover and before the handover is completed; instructing to forward the second downlink packet to the target cell address if the second downlink packet is received by t e source cell after the terminal was instructed to handover and before the handover is completed.

According to the first to third aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform providing a handover preparation indication to a controller, wherein the handover preparation message comprises the target address, an internet protocol address of the source cell, the target cell address, and an ingress point address of an ingress point of a traffic to the terminal, wherein the ingress point address is of the internet protocol.

According to the first to third aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform monitoring if a target cell receives a handover preparation packet of the internet protocol for preparing a handover of a terminal from a source cell to the target cell, wherein the handover preparation packet comprises the terminal address and the identifier of the radio access bearer; checking if the handover of the terminal to the target cell is initiated; attaching the terminal to the target cell using the terminal address if the target cell received the handover preparation packet and the handover is initiated.

According to the first to third aspects, the at least one memory and the computer program code, is arranged to cause the apparatus to further perform prohibiting the target cell to involve a mobility management entity for the preparing of the handover.

According to the first to third aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform requesting a mobility management entity to validate the terminal address after the terminal has been attached to the target cell.

According to the first to third aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform checking if the uplink packet fulfills a predefined criterion; inhibiting the forming of the internet protocol packet and conveying the uplink packet to a packet core network if the uplink packet fulfills the predefined criterion.

According to a fourth aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform retrieving a target address of a layer 2 protocol from a header of a first downlink packet of the layer 2 protocol received by a source cell, wherein the first downlink packet is addressed to the target address, and the first downlink packet comprises the header and a payload; determining a radio access bearer identifier associated to the target address; instructing to forward the payload of the first downlink packet in a packet data convergence protocol context on a radio bearer identified by the radio access bearer identifier.

According to a fifth aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform retrieving a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer; identifying an origin address based on an identifier of the radio access bearer; forming a layer 2 packet comprising a header and the payload, wherein the header comprises the origin address as an origin; instructing to transmit the layer 2 packet.

The at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform retrieving a destination internet protocol address of an internet protocol for the uplink packet; requesting a destination layer 2 address of the layer 2 protocol based on the destination internet protocol address; monitoring if the destination layer 2 address is received in response to the request; wherein the instructing comprising instructing to transmit the layer 2 packet to the destination layer 2 address.

According to any of the fourth and fifth aspects, the at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform monitoring if a request to handover a terminal to a target cell is received in the packet data convergence protocol context, wherein the target cell is identified by a target cell identifier and the terminal is identified by a radio identifier, and the target cell identifier and the radio identifier do not belong to the layer 2 protocol; requesting a target cell address of the target cell from a data repository based on the target cell identifier, wherein the target cell address is of the layer 2 protocol; forming a handover preparation packet of the layer 2 protocol directed to the target cell address, wherein a payload of the handover preparation packet may comprise the terminal address and the identifier of the radio access bearer.

According to any of the fourth and fifth aspects, the at least one processor, with the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform inhibiting the source cell to instruct the terminal to handover to the target cell; checking if an acknowledgment of the handover preparation packet is received from the target cell; cancelling the inhibiting of the source cell to instruct the terminal to handover to the target cell if the acknowledgement is received.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform monitoring if a second downlink packet of the layer 2 protocol addressed to the target address is received by the source cell after the terminal was instructed to handover and before the handover is completed; instructing to forward the second downlink packet to the target cell address if the second downlink packet is received by the source cell after the terminal was instructed to handover and before the handover is completed.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform providing a handover preparation indication to a controller, wherein the handover preparation message comprises the target address, an layer 2 protocol address of the source cell, the target cell address, and an ingress point address of an ingress point of a traffic to the terminal, wherein the ingress point address is of the layer 2 protocol.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code, may be arranged to cause the apparatus to further perform monitoring if a target cell receives a handover preparation packet of the layer 2 protocol for preparing a handover of a terminal from a source cell to the target cell, wherein the handover preparation packet comprises the terminal address and a radio identifier of the terminal associated to the terminal address; checking if the handover of the terminal to the target cell is initiated; attaching the terminal to the target cell using the terminal address if the target cell received the handover preparation packet and the handover is initiated.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform prohibiting the target cell to involve a mobility management entity for the preparing of the handover.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform requesting a mobility management entity to validate the terminal address after the terminal has been attached to the target cell.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform assigning a layer 2 address associated to the terminal when the terminal attaches to the source cell; informing that the layer 2 address and an internet protocol address of an internet protocol assigned to the terminal are related to the terminal.

According to any of the fourth and fifth aspects, the at least one memory and the computer program code may be arranged to cause the apparatus to further perform checking if the uplink packet fulfills a predefined criterion; inhibiting the forming of the layer 2 protocol packet and conveying the uplink packet to a packet core network if the uplink packet fulfills the predefined criterion.

According to a sixth aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform monitoring if a request for a target cell address is received, wherein the request comprises a cell identifier; providing, in response to the request, the target cell address, wherein the target cell address is of an internet protocol or a layer 2 protocol, and the cell identifier is of a protocol different from the internet protocol and the layer 2 protocol.

According to a seventh aspect of the invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor, with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform determining a node being closest to a root of a star of a source cell, a target cell, and an ingress point of a payload traffic to a terminal, wherein a handover of the terminal from the source cell to the target cell is being prepared; instructing the node to forward the payload traffic from the ingress point to the source cell and to the target cell.

The at least one memory and the computer program code, may be arranged to cause the apparatus to further perform monitoring if a handover preparation indication is received, wherein the handover preparation message comprises identifiers of the terminal, the source cell, the target cell, and the ingress point.

The at least one memory and the computer program code, may be arranged to cause the apparatus to further perform intercepting a handover preparation message of the handover; extracting identifiers of the terminal, the source cell, the target cell, and the ingress point from the handover preparation message.

According to an eighth aspect of the invention, there is provided a method, comprising retrieving a target address of an internet protocol from a header of a first downlink packet of the internet protocol received by a source cell, wherein the first downlink packet is addressed to the target address, and the first downlink packet comprises the header and a payload; determining a radio access bearer identifier associated to the target address; identifying a terminal address of the internet protocol based on the target address; instructing to forward the terminal address and the payload of the first downlink packet in a packet data convergence protocol context on a radio bearer identified by the radio access bearer identifier.

The identifying may comprise identifying the terminal address based on a port number, wherein the target address may comprise the port number; and the determining may comprise determining the radio access bearer identifier based on the port number.

The terminal address may be the target address.

According to a ninth aspect of the invention, there is provided a method, comprising retrieving a terminal address of an internet protocol and a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer; forming an internet protocol packet comprising a header and the payload, wherein the header comprises an origin address of the internet protocol as an origin; instructing to transmit the internet protocol packet, wherein the origin address is the terminal address.

According to a tenth aspect of the invention, there is provided a method, comprising retrieving a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer, wherein the uplink packet comprises the payload and a terminal address of an internet protocol; identifying an origin address of the internet protocol based on an identifier of the radio access bearer; forming an internet protocol packet of t e internet protocol comprising a header and the payload, wherein the header comprises the origin address as an origin; instructing to transmit the internet protocol packet.

The identifying may comprise identifying a port number based on the identifier of the radio access bearer; and the origin address may comprise a predetermined cell address of the internet protocol and the port number.

Plural radio access bearers with different identifiers may be configured in the source cell, and the cell address may be independent from the respective identifier of the radio access bearer.

The origin address may be the terminal address.

According to any of the eighth to tenth aspects, the method may further comprise monitoring if a request to handover a terminal to a target cell is received in the packet data convergence protocol context, wherein the target cell is identified by a target cell identifier and the terminal is identified by a radio identifier, and the target cell identifier and the radio identifier do not belong to the internet protocol; requesting a target cell address of the target cell from a data repository based on the target cell identifier, wherein the target cell address is of the internet protocol; forming a handover preparation packet of the internet protocol directed to the target cell address, wherein a payload of the handover preparation packet comprises the terminal address and the identifier of the radio access bearer; instructing to transmit the handover preparation packet to the target cell address.

According to any of the eighth to tenth aspects, the method may further comprise inhibiting the source cell to instruct the terminal to handover to the target cell; checking if an acknowledgment of the handover preparation packet is received from the target cell; cancelling the inhibiting of the source cell to instruct the terminal to handover to the target cell if the acknowledgement is received.

According to any of the eighth to tenth aspects, the method may further comprise monitoring if an second downlink packet of the internet protocol addressed to the target address is received by the source cell after the terminal was instructed to handover and before the handover is completed; instructing to forward the second downlink packet to the target cell address if the second downlink packet is received by the source cell after the terminal was instructed to handover and before the handover is completed. According to any of the eighth to tenth aspects, the method may further comprise providing a handover preparation indication to a controller, wherein the handover preparation message may comprise the target address, an internet protocol address of the source cell, the target cell address, and an ingress point address of an ingress point of a traffic to the terminal, wherein the ingress point address is of the internet protocol.

According to any of the eighth to tenth aspects, the method may further comprise monitoring if a target cell receives a handover preparation packet of the internet protocol for preparing a handover of a terminal from a source cell to the target cell, wherein the handover preparation packet may comprise the terminal address and the identifier of the radio access bearer; checking if the handover of the terminal to the target cell is initiated; attaching the terminal to the target cell using the terminal address if the target cell received the handover preparation packet and the handover is initiated.

According to any of the eighth to tenth aspects, the method may further comprise prohibiting the target cell to involve a mobility management entity for the preparing of the handover.

According to any of the eighth to tenth aspects, the method may further comprise requesting a mobility management entity to validate the terminal address after the terminal has been attached to the target cell.

According to any of the eighth to tenth aspects, the method may further comprise checking if the uplink packet fulfills a predefined criterion; inhibiting the forming of the internet protocol packet and conveying the uplink packet to a packet core network if the uplink packet fulfills the predefined criterion.

According to an eleventh aspect of the invention, there is provided a method, comprising retrieving a target address of a layer 2 protocol from a header of a first downlink packet of the layer 2 protocol received by a source cell, wherein the first downlink packet is addressed to the target address, and the first downlink packet comprises the header and a payload; determining a radio access bearer identifier associated to the target address; instructing to forward the payload of the first downlink packet in a packet data convergence protocol context on a radio bearer identified by the radio access bearer identifier.

According to a twelfth aspect of the invention, there is provided a method, comprising retrieving a payload from an uplink packet received by a source cell in a packet data convergence protocol context on a radio access bearer; identifying an origin address based on an identifier of t e radio access bearer; forming a layer 2 packet comprising a header and the payload, wherein the header comprises the origin address as an origin; instructing to transmit the layer 2 packet.

The method may further comprise retrieving a destination internet protocol address of an internet protocol for the uplink packet; requesting a destination layer 2 address of the layer 2 protocol based on the destination internet protocol address; monitoring if the destination layer 2 address is received in response to the request; wherein the instructing may comprise instructing to transmit the layer 2 packet to the destination layer 2 address.

According to any of the eleventh and twelfth aspects, the method may comprise monitoring if a request to handover a terminal to a target cell is received in the packet data convergence protocol context, wherein the target cell is identified by a target cell identifier and the terminal is identified by a radio identifier, and the target cell identifier and the radio identifier do not belong to the layer 2 protocol; requesting a target cell address of the target cell from a data repository based on the target cell identifier, wherein the target cell address is of the layer 2 protocol; forming a handover preparation packet of the layer 2 protocol directed to the target cell address, wherein a payload of the handover preparation packet comprises the terminal address and the identifier of the radio access bearer.

According to any of the eleventh and twelfth aspects, the method may comprise inhibiting the source cell to instruct the terminal to handover to the target cell; checking if an acknowledgment of the handover preparation packet is received from the target cell; cancelling the inhibiting of the source cell to instruct the terminal to handover to the target cell if the acknowledgement is received.

According to any of the eleventh and twelfth aspects, the method may comprise monitoring if a second downlink packet of the layer 2 protocol addressed to the target address is received by the source cell after the terminal was instructed to handover and before the handover is completed; instructing to forward the second downlink packet to the target cell address if the second downlink packet is received by the source cell after the terminal was instructed to handover and before the handover is completed.

According to any of the eleventh and twelfth aspects, the method may comprise providing a handover preparation indication to a controller, wherein the handover preparation message comprises t e target address, an layer 2 protocol address of the source cell, the target cell address, and an ingress point address of an ingress point of a traffic to the terminal, wherein the ingress point address may be of the layer 2 protocol.

According to any of the eleventh and twelfth aspects, the method may comprise monitoring if a target cell receives a handover preparation packet of the layer 2 protocol for preparing a handover of a terminal from a source cell to the target cell, wherein the handover preparation packet comprises the terminal address and a radio identifier of the terminal associated to the terminal address; checking if the handover of the terminal to the target cell is initiated; attaching the terminal to the target cell using the terminal address if the target cell received the handover preparation packet and the handover is initiated.

According to any of the eleventh and twelfth aspects, the method may comprise prohibiting the target cell to involve a mobility management entity for the preparing of the handover.

According to any of the eleventh and twelfth aspects, the method may comprise requesting a mobility management entity to validate the terminal address after the terminal has been attached to the target cell.

According to any of the eleventh and twelfth aspects, the method may comprise assigning a layer 2 address associated to the terminal when the terminal attaches to the source cell; informing that the layer 2 address and an internet protocol address of an internet protocol assigned to the terminal are related to the terminal.

According to any of the eleventh and twelfth aspects, the method may comprise checking if the uplink packet fulfills a predefined criterion; inhibiting the forming of the layer 2 protocol packet and conveying the uplink packet to a packet core network if the uplink packet fulfills the predefined criterion.

According to a thirteenth aspect of the invention, there is provided a method, comprising monitoring if a request for a target cell address is received, wherein the request comprises a cell identifier; providing, in response to the request, the target cell address, wherein the target cell address is of an internet protocol or a layer 2 protocol, and the cell identifier is of a protocol different from the internet protocol and the layer 2 protocol. According to a fourteenth aspect of the invention, there is provided a method, comprising determining a node being closest to a root of a star of a source cell, a target cell, and an ingress point of a payload traffic to a terminal, wherein a handover of the terminal from the source cell to the target cell is being prepared; instructing the node to forward the payload traffic from the ingress point to the source cell and to the target cell.

The method may further comprise monitoring if a handover preparation indication is received, wherein the handover preparation message comprises identifiers of the terminal, the source cell, the target cell, and the ingress point.

The method may further comprise intercepting a handover preparation message of the handover; extracting identifiers of the terminal, the source cell, the target cell, and the ingress point from the handover preparation message.

Each of the methods of the eighth to fourteenth aspects may be a method of protocol conversion or a method of handover.

According to a fifteenth aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the eighth to fourteenth aspects. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.

According to some embodiments of the invention, at least one of the following advantages may be achieved:

• arbitrary transport networks may be used for 3GPP traffic;

• mobility is supported without affecting the transport network;

• no packet loss during handover;

• UEs are not affected;

• coexistence of "classical" 3GPP core networks and the arbitrary transport networks in one PLMN;

• TCO may be reduced;

• Administering of X2 ranges may be avoided;

• latency may be reduced by shortest path connections;

• Control plane traffic may be reduced compared to 3GPP TS 23.401 , chapter 5.5.1 .2.2;

• the bottleneck at the source eNB may be avoided; • the additional delay caused by packet forwarding from the source eNB to the target eNB may be minimized.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.

Brief description of the drawings

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein

Fig. 1 shows a BFNMN network;

Fig. 2 shows a GLAN network;

Fig. 3 shows network slicing;

Fig. 4 shows conventional radio-terrestric binding;

Fig. 5 shows radio-terrestic binding according to some embodiments of the invention;

Fig. 6 shows radio-terrestic binding according to some embodiments of the invention;

Fig. 7 shows a network according to some embodiments of the invention;

Fig. 8 shows a network according to some embodiments of the invention and a related initial attach procedure;

Fig. 9 shows a network according to some embodiments of the invention and a related handover procedure;

Fig. 10 shows a network according to some embodiments of the invention and a related IP validation procedure following the handover procedure;

Fig. 1 1 shows a network according to some embodiments of the invention based on a GLAN network and a related handover procedure;

Fig. 12 shows a network according to some embodiments of the invention and a related initial attach procedure;

Fig. 13 shows a handover procedure according to some embodiments of the invention;

Fig. 14 shows an apparatus according to an embodiment of the invention;

Fig. 15 shows a method according to an embodiment of the invention;

Fig. 16 shows an apparatus according to an embodiment of the invention;

Fig. 17 shows a method according to an embodiment of the invention;

Fig. 18 shows an apparatus according to an embodiment of the invention; Fig. 19 shows a method according to an embodiment of the invention;

Fig. 20 shows an apparatus according to an embodiment of the invention;

Fig. 21 shows a method according to an embodiment of the invention;

Fig. 22 shows an apparatus according to an embodiment of the invention.

Fig. 23 shows a method according to an embodiment of the invention;

Fig. 24 shows an apparatus according to an embodiment of the invention;

Fig. 25 shows a method according to an embodiment of the invention;

Fig. 26 shows an apparatus according to an embodiment of the invention;

Fig. 27 shows a method according to an embodiment of the invention; and

Fig. 28 shows an apparatus according to an embodiment of the invention.

In Figs. 1 to 13, corresponding functions are represented by corresponding symbols.

Detailed description of certain embodiments

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

Some embodiments of the invention allow to connect cellular access points (eNodeB) to any kind of Telco/IT network (transport network, RAN, LAN, ...) in a way that no non-access- stratum (NAS) signalling is required (and thus not carried out) and in a way that standard 4G/5G devices can be connected without modification.

Furthermore, some embodiments of the invention provide means that allow a seamless transition between access points avoiding packet losses at handover. Thus, the networking principles of the connected network are unaffected although EPC control plane is not required. The level of mobility support may be left to said connected network (no mobility, transport based mobility, implicit mobility, ...). In Figs. 5 and 6, it is shown how to adapt an eNodeB to a given native network (L2 network and L3 network (in particular: IP network), respectively) allowing to address individual UEs via this network and out of this network by identities used in this network (MAC address and IP address, respectively). Hence, Figs. 5 and 6 show an adapted radio-terrestrial binding.

Figure 5 shows an eNodeB with its RTB unit which is connected to a layer 3 network (e.g. corresponding to the Brute-Force approach). In this case, the RTB unit may use the UEs IP address as anchor for binding a bearer. In order to do so, the eNodeB may notice and store the IP address of the UE and bind it to a corresponding radio link (radio bearer) represented by its E-RAB-ID. UEs may then be addressed directly by their IP address from entities connected to the (IP) network. In contrast to conventional RTB, eNodeB must be aware of UE- IP addresses and IP addresses have to be unique over the whole (IP) network. This way an eNodeB appears as a router to the network.

The eNB may retrieve the IP address of the UE e.g. via the S1 interface in the PCO (protocol configuration option) parameter which the MME sends back to UE (via eNB) in response to Initial Attach. Note that this communication between UE and MME does not require a GTP tunnel on the S1 interface. In addition or alternatively, eNB may retrieve the IP address from packets sent on top of the PDCP (i.e., via a RAB). It may even cross-check if the IP address retrieved from PCO is the same as that of the IP packet sent via RAB. If these are addresses are different, an error message may be issued. Furthermore, in case of such a discrepancy, the packet may not be conveyed, or the IP address stored as being associated to the respective RAB may be updated by that comprised in the IP packet, or vice versa, depending on implementation or on further parameters.

A beneficial extension to the approach of Fig. 5 according to some embodiments of the invention (not shown in Fig. 5), a NAT-function and (optionally) a DHCP function are implemented at the eNodeB. Thus, UEs may retrieve a local (local as long as those are attached to this eNodeB) IP address, either by a local DHCP function or by an initial attach procedure involving an MME. In some embodiments, fixed IP addresses may be assigned to the UEs. In case of local IP address assignment, the NAT function may map those local IP addresses into a public one (e.g. eNodeB IP address) by separating the different connections by the port number. Here, also a binding of E- RAB- ID/port number may take place.

Fig. 6 shows RTB of an eNodeB according to some embodiments of the invention, wherein the eNB is connected to a flat L2 network, typically represented by a LAN or by GLAN. For t e L2 network, the eNodeB appears as a layer 2 bridge, i.e., packet forwarding bases on the MAC address. This requires that each UE can be addressed by a MAC address (an example of a MAC address is an Ethernet MAC address). Since UEs do not have an Ethernet MAC address, the eNodeB provides "temporary" or "virtual" MAC addresses as part of the RTB function. That is, in the RTB, each RAB of a UE is associated to a respective [virtual] MAC address. This allows outside nodes connected to the L2 network (e.g. LAN) to address UEs by their [virtual] MAC address. For example, the [virtual] MAC address may be assigned when the UE attaches to the network (e.g. at initial attach or at handover).

For example, the eNB may compile virtual MAC addresses by using the first 10 digits of its own MAC address ("<base MAC>" in Fig. 6) and adding two digits referencing the E-RAB-IDs. The RTB unit will then receive the IP packets from a UE, terminate the LTE-U-Plane stack and put the IP packet into an Ethernet frame (IEEE 802.3) with the terminals IP address as source IP address and with the virtual MAC address as source MAC address into the according header fields. In downlink direction entities connected via the L2 network will use these addresses as target IP or target MAC address. For the L2 network, a UE appears as an Ethernet host which is connected to the network.

In a beneficial extension of this approach according to some embodiments of the invention, upon assignment of a virtual MAC address, i.e., when a UE attaches to the eNodeB, the eNodeB may send out a gratuitous ARP message to allow support of L2 inherent mobility as e.g. for GLAN.

The principles lined out hereinabove apply in case of one or plural RABs per UE correspondingly. That is, a L3 address and L2 address, respectively, is assigned to each of the RABs, regardless of whether the RABs are of one UE or plural UEs.

One of the advantages of the solutions shown in Fig. 5 and Fig. 6 is that they do not require tunnel based NAS signalling - which is considered a major advantage to conventional RTB. Thus, eNodeBs are made adaptive to typical existing network infrastructures (IP networks, LAN, GLAN etc.). In addition, in some embodiments of the invention, eNB need not be capable of handling GTP tunnels.

Figure 7 shows some functions of an embodiment of the invention that may be used to support this adaptiveness. On the left side there are three UEs [UE-1 to UE-n) representing a multitude of standard 4G/5G devices, each being assigned an IP address [IP-1 to IP-n]. Those UEs can be connected to any of multiple eNodeB which are identified by one or more cell-IDs [cell-ID- A, cell-ID-n] and one or more IP addresses [IP-A to IP-n] (not shown in the eNB boxes but in HO-DB) and one or more MAC addresses [in case eNB is connected to the transport network TRA via Ethernet which is not mandatory]. Each eNB has a data base [UE-DB] in which UE context data is stored for each connected UE. Each of these data records comprises the UE IP address[es], keys [for ciphering over the air interface], bearer information [of existing connection(s)], identities [e.g. IMSI or TIMSI], context data [e.g. PDCP (Packet Data Convergence Protocol) context, allowing the eNB to identify individual connections] and potentially more data. Furthermore, the eNB has a function mobility control function (M-Ctrl) allowing it to communicate with one [or several] MME, e.g. to perform authentication or to get a new IP address assigned (initial attach) and to get information about slice selection related behaviour.

The eNB may comprise a discrimination function DF which acts as a simple MUX: depending on the information received w.r.t. which network slice shall be used for a given connection, UE payload traffic will be conveyed to an S1 -interface (standard 4G/5G eNB RAN connection, involves GTP tunnelling) or to a simple native network connection (IP in case connected network is a routed L3 network, or MAC/Ethernet in case said network is a LAN L2 network). For instance, the decision of the DF may be based on a DECOR (Dedicated Core Networks selection mechanism) related information element like the "UE Usage Type" or the Slice ID or the S-NSSAI (Single Network Slice Selection Assistance Information which identifies a Network Slice.) etc., For instance, a particular value may be allocated to one of these information elements and mapped for the injection of the payload towards the native transport network instead of legacy EPC tunnelling.

In some cases, an eNB according to some embodiments of the invention may not comprise the DF. E.g., the eNB may not comprise an S1 interface and route all traffic through the native network connection (L2 or L3 network without 3GPP functions like MME, PGW, SGW).

Additionally, there may be a handover database (HO-DB) which stores information about all eNBs that are part of the system. The information stored comprises reachability information, e.g. the control plane and/or the user plane eNB IP addresses and / or eNB layer 2 MAC addresses (if existing) correlated with one or more eNB specific cell-ID. The address stored the HO-DB corresponds to the addressing used in the transport network. The HO-DB may be populated by the eNBs during their start-up with the correlation of all the Cell IDs it hosts with the associated IP addresses and/or MAC addresses, as applicable. Alternatively or in addition, the population may administered in advance by means of OAM.

Fig. 7 shows two implementations of an MME (U-MME and S-MME). They may be used for authentication (U-MME) and IP address assignment (S-MME). For example, in case this system is used in a mobile network for selected use cases or services only, the system may be realized as network slice.

Most typically, upon service request, an umbrella MME (U-MME) will be contacted, which, depending on parameters or identities sent from the UE will then determine an appropriate network slice and re-direct the request to an appropriate MME of that slice (S-MME). This mechanism is not novel.

However, embodiments of the invention do not need to implement U-MME and S-MME. For example, in some embodiments, one MME implementation is sufficient, e.g., if the PLMN is not sliced.

Fig. 8 shows an "initial attach" procedure which is used to make a UE known to a network and which is carried out at least when a switched off UE is connecting to an eNB.

As shown in Fig. 8, a UE sends information about itself (IMSI, service identifier) to the eNodeB which interrogates an umbrella MME indicating the appropriate slice MME which finally handles the initial attach. The MME performs a 3GPP compliant authentication as a result of which parameter sets (cipher keys) will be sent and stored at the eNodeB (and the UE). In the eNB, the parameter sets will be stored in the UE-DB in the according UE data record (see Fig. 7).

Upon successful authentication the UE may be assigned an IP address which may be provided by a global (network wide) IP address pool, or by a local MME managed IP address pool, or by a eNodeB managed IP address pool, e.g. via DHCP. The IP address may be stored in the corresponding UE record of the UE-DB in the eNB, too.

In case the eNBs are connected to a transport network based on "brute force no mobility" principles (e.g. BFNMN), assignment of IP address may have to happen each time the UE changes the eNodeB. In this case, the (S-)MME has a geographical meaning, i.e. groups of eNB are assigned to different MMEs, in this case likely more than one MME has to be involved during the lifetime of the UE.

In case eNBs are connected to a network based on GLAN principles, assignment of IP address only has to happen when the UE has no IP address (e.g. factory settings) or if there is (for whatever reason) a network demand to change the IP address. From a system point of view, there is no need to change the IP address frequently, so in principle it is possible, that a UE keeps the IP address for its whole lifetime. In this case, the MME does not have a geographical meaning which allows to have one MME only for this slice. In some of these embodiments, the MME function may be collocated with the eNodeB.

Fig. 9 shows a handover procedure according to some embodiments of the invention allowing session continuity without MME interrogation.

As shown in Fig. 9, UE1 is in a connection with eNB A. Measurement reports indicate that the radio connection is getting worse and UE1 reports the cell-ID of eNB B as a potential target cell. After a while eNB A makes a handover decision, that is, UE 1 shall handover to eNB B. Before eNB A instructs UE1 to handover, eNB A interrogates the HO-DB with connection parameters related to eNB B's cell-ID. The HO-DB will report according parameters: the IP- address of eNB B, if eNB B can be reached via a routed network and/or the MAC address of eNB B in case eNB B can be reached via a layer 2 network, e.g. in case of a GLAN based network.

After retrieval of the connection parameters from the HO-DB, eNB A sends the UE related data (e.g. IP address, cypher keys, and identifier(s) of the radio access bearer(s) (bearer context ID or E-RAB ID)) in a Handover Prepare message as stored in its UE-DB to eNB B using the retrieved connection parameters (IP address and/or MAC address) as a target address.

Only then, eNB A instructs UE1 to handover. When UE1 attaches to eNB B all parameters necessary to setup a radio link (keys, bearer information) are already available at the target eNodeB so that an MME interrogation is not necessary.

If the transport network is of a "brute force no mobility" design (e.g. BFNMN), UE then performs an initial attach in order to retrieve a new IP address. On the other hand, if the transport network corresponds to the GLAN solution, UE issues an ARP request and based on the ARP request, AM-C may send SDN based instruction towards the AM-Us. This mechanism for retrieving connectivity information via a HO-DB allows eNodeBs to communicate directly and transparently for the underlying network (especially without MME involvement).

In some embodiments, MME might still be involved, e.g. in case the network design requires the existence of the S1 -MME Interface for the HO and the assignment of a new IP address. Fig. 10 shows possible MME interrogation scenarios. These interrogations follow after the handover of UE1 to eNB B started, as shown in Fig. 9. That is, UE1 shown in Fig. 10 is initially in a state where it attaches to eNB B as part of a handover.

Here, depending on implementation, the eNodeB may have the option to request an MME whether or not further action shall be taken. For example, upon attach, eNB B requests from S-MME if the IP address of UE1 is valid.

The MME may now act according to one of the following three cases:

• In case 1 , if the IP address of UE1 is valid, an action is not to be done. MME will indicate this in its response and the handover may be finalized, as described with respect to Fig. 9.

• Depending on the underlying network, there might be the need to assign a new IP address (e.g. "brute force no mobility"; case 2). MME may assign the new IP address to the UE and inform the eNB B in the validity response message on the new IP address. It should be noted that in this case the radio bearers would have to be torn down and re-established, an IP address would have to be assigned out of a pool of IP addresses, in total this procedure might take several hundred of milliseconds.

• In case 3, for whatever reason, service related backend procedures may have decided that a service is no longer allowed for UE1 or a user of UE1 (e.g. subscription ended, lack of budget). This decision is known to MME. In this case, the validity response from MME instructs the eNodeB B to not allow access.

Note that in case of a GLAN based network design the interrogation with MME is not necessarily required. Again, if an MME is involved anyway, it would not have to have a geographical context and one MME entity would be sufficient which could also become part of an eNodeB then. Fig. 1 1 shows a beneficial design according to some embodiments of the invention. It is related to network layouts that follow mobility aware transport principles such as GLAN.

Again, if eNB A detects that a handover to eNB B is necessary it will request the HO-DB for appropriate connection parameters. HO-DB returns IP B, the address under which eNB B can be reached. Thus, in some embodiments, eNB A forwards payload data for UE1 received after eNB A instructed UE1 to handover and before handover is completed, to eNB B, addressing these payload data by the IP address of eNB B.

However, since eNB A and eNB B are nodes in a GlobalLAN, they can reach each other by their L2 (MAC) address. When nodes of a LAN know the IP address but not the MAC address of their peer, they may send an ARP request in order to receive the corresponding MAC address. Accordingly, eNB A may send an ARP request in order to receive a valid MAC address of eNB B. In case eNB B belongs to the same LAN segment, it will respond on its own, providing its MAC address (standard LAN behaviour, not shown in Fig. 1 1 ).

In case eNB B belongs to a layer 2 network [LAN] different from that of eNB A, AM-U1 , which is controlling the layer 2 network eNB A is connected to, will interrogate, via AM-C, the CLR to retrieve the MAC address of the AM-U entity (denoted AM-U2) which is controlling the layer 2 network eNB B is connected to. Finally, AM-U1 respond to the requesting eNB A with its own MAC address (i.e., MAC address of AM-U1 ). In another implementation, AM-U1 may directly report AM-U2's MAC address to eNB A as the MAC address of eNB B.

After eNB A instructed UE1 to handover and before handover is completed, payload packets for UE1 addressed to eNB A have to be forwarded to eNB B. According to some embodiments of the invention, eNB A may address these payload packets to the address of eNB B known to eNB A, i.e. the IP address of eNB B, the MAC address of eNB B, the MAC address of AM- U1 , or the MAC address of AM-U2, depending on the implementation and case described above. In the case that such packets from eNB A to eNB B are addressed to the MAC address of AM-U1 , AM-U1 will do header swapping and replace the destination MAC address (i.e. that of AM-U1 ) with the MAC address of AM-U2, if the packets arrive at AM-U1 .

The MAC-address of AMU-2 was formerly retrieved by a CLR-DB request. Packets conveyed to AMU-2 will now have AMU-2-MAC address and UE IP address as destination addresses. AMU-2 has to swap the destination MAC addresses (its own AMU-2 MAC address) with the virtual MAC addresses of the corresponding UEs. This swap is based on a table the AMU-2 is maintaining and its entries are entered/deleted/modified based on attachments of UEs. Between AMU-2 and eNB-B there may be layer 2 Ethernet network with a hierarchy of layer 2 switches involved. The correct target eNodeB will be found and addressed by the UEs' [virtual] MAC addresses - from here on normal layer 2 switching takes place (in layer 2 networks switches maintain MAC address/port tables).

In the opposite direction, a corresponding header swapping may take place.

Thus, in addition to the preparation phase of a handover (sending keys, etc. beforehand) eNB A can now also send payload packets meant for UE1 to the target base station eNB B. This is similar to existing X2 handover as defined by 3GPP with the difference (and benefit, of course) that no X2 ranges have to defined and managed, no MME involvement is necessary and the mechanism is completely transparent for the network in place (over-the-top).

As part of GLAN principles, the SDN controller may modify all flow tables of all nodes that are part of the eNB A - eNB B link such that packets are conveyed following shortest path principles and both nodes can send and receive packets on layer 2.

In yet another beneficial implementation according to some embodiments of the invention, in order to save transport costs, payload data for UE1 received after eNB A instructed UE1 to handover and before handover is completed may not be forwarded from eNB A to eNB B. Instead, the SDN controller identifies a suitable node which dual-casts the data to both eNB A and eNB B. SDN controller may select the node such that a total length of the transport paths is minimized (i.e. a root of a star of the source eNB, the target eNB, and an ingress point of a payload traffic to the terminal). Further details are described further below.

Some further implementation details according to some embodiments of the invention are described below:

Initial Attach

As shown in Fig. 12, at the initial attach of an UE within the selected slice (identified by the slice ID) the RAN stores the associated data for that UE: A basic principle that needs to be kept is that the eNodeB needs to be enabled to differentiate which packet it receives has to be conveyed to which UE that might be connected to it. In principle, there are several ways to address this issue: According to one option, all packets send from and received by t e eNodeB have the same MAC address (the eNodeB MAC address). In this case, the eNodeB uses the UE IP address to keep flows separate. Therefore, in this case, the eNodeB has to be IP address sensitive.

Another way is shown in Fig. 12. Here the eNodeB the UE is associated with assigns a "virtual MAC address" to said UE to allow distinguishing between different packet flows from/to different UEs. The virtual MAC addresses are taken out of a pool of eNodeB specific virtual MAC addresses. For example, the eNodeB may compile such MAC addresses by taking the first digits of its own MAC address and by adding subsequent numbering to said virtual MAC addresses. Most beneficially, the eNodeB could then assign received packets containing this MAC address to an existing / or newly setup PDCP context (which relates to an existing / or newly setup bearer). When sending out a gratuitous ARP message (e.g. in case of initial attach or handover, see above), the ARP message will have the assigned [virtual] MAC address and the UE IP address as source addresses.

Handover

In the paragraph "Initial Attach", a simple procedure for attaching one UE to the GLAN network has been shown. Hereinafter, a case of two peering UEs attached to the GLAN slice are further studied. In this example, one UE performs a 3GPP handover such that, after the handover, the two UEs a) are connected to two different eNBs; and

b) the two eNBs are served by two different AM-Us.

Fig. 13 shows the handover of the UE from the source eNB to the target eNB attached to different AM-Us and a reconfiguration of the GLAN slice according to some embodiments of the invention.

As shown in Fig. 13, the source eNB slice recognizes, e.g. due to UE measurement reports, that radio conditions get worse and decides to perform handover for this connection to an eNB with a certain Cell ID (reported by UE as part of measurement reports) and consults the HO- DB of the GLAN slice.

At first, the eNB consults the HO-DB (the eNBs are configured with the address of the HO-DB) and requests the IP addresses for the target eNB hosting the Cell ID from the HO-DB via the message "Request target connection parameter". In this example, the HO-DB provides the IP Addresses of the target eNB back to the source eNB. However, in some embodiments, the MAC addresses are provided additionally to or instead of the IP addresses.

In the example shown for this scenario it is assumed that the MAC addresses and the IP addresses of the target eNB are not known to the source eNB already. Similarly, the target eNB does not know the source eNB yet (Cell-ID).

In the following, the establishment of the connectivity on Control plane level is described. However, the establishment for U-Plane connectivity follows the same procedure [not shown in Fig. 13].

As a next step, the source eNB issues an ARP Request with the IP address of the control plane of the target eNB as being provided by the HO-DB in the previous step. The AM-U1 (Access mediator - user plane) forwards the ARP request as part of e.g. the OpenFlow (OF) "Packet IN" message to the AM-C (AM Controller) via the embedded SDN controller. The AM- C queries the Client Location Register (CLR) which provides the MAC address of the AM-U2 to which the target eNB is connected back to the AM-C. In this case the AM-C responds with the ARP reply (via OF:Packet Out) containing the MAC address of the AM-U1 the source eNB is connected to such that the source eNB will be able to contact the target eNB via the AM-U. Furthermore the AM-C instructs the AM-U1 and the AM-U2 with OpenFlow "FlowModification"- message so that MAC addresses of the packets from/to source/target eNBs are swapped at the AM-Us. Additionally the AM-C sends a ARP reply in the OF:"Packet OUT" message via the AM-U2 towards the target eNB such that the target eNB will send IP packets to the AM-U2 which forwards them to the AM-U1 from which the packets are sent to the source eNB.

After this procedure, control plane connectivity between the eNBs exists. Similarly, the user plane connectivity is established (not shown in figure).

Most beneficially, the eNodeBs keep track of this associations such that this procedure is not needed to be carried out upon each handover..

Besides making IP addresses of the target eNBs known to the source eNB upon handover, the connectivity between eNBs may also be preconfigured at/after the start-up of eNBs. Since now, the target eNB is known at the source eNB. The source eNB informs the target eNB about the details for the intended handover and signals at least the UE ID, the keys, radio bearer characteristics, IP address of the UE, IP address of the source eNB and the slice ID of the GLAN via the "prepare HO"-message. On receipt, the target eNB starts to prepare radio resources. Once the target eNB has prepared the radio resources successfully, it will respond with the "Prepare Handover Ack"-message and signals the successful radio resource preparation towards the source eNB via both the AM-U2 and AM-U1 .

On receipt of the "Prepare Handover Ack"-message at the source eNB, the source eNB instructs the UE to perform the HO to the new target eNB via the "Handover" command. The source eNB starts to forward the downlink payload packets to the target eNB (instead of sending them to the UE directly).

According to some embodiments of the invention, this may be done by the following mechanism:

In order to allow keeping different HO-streams separate, the eNB-eNB flows have to be multiplexed to some extent since packets will always have the same source/destination IP addresses although payload data might comprise packets related to different UEs. One option to keep streams separate is assigning port numbers to the packet headers with each port number reflecting different UEs.

In the example shown in Fig. 13, a tunnelling approach is used.

According to some embodiments of the invention, the source eNB inserts/stacks each original IP packet into another IP Packet destined to the target eNB and at least also prepends the Context ID of the UE and the downlink indication before it is forwarded to the target eNB (see Table 1 ).

On receipt at the target eNB the outer IP header is removed and the Context ID of the UE is evaluated by the target eNB to fetch the correlated radio bearer from the eNB internal database so that the de-capsulated payload is forwarded to the UE via the air interface. In addition, the target eNB may now issue the gratuitous ARP indicating that the IP address of the UE is hosted at the target eNB. Based on the gratuitous ARP, the the flow rules at the AM-Us are modified accordingly. Outer header Context ID of the DL/UL Inner header Payload

UE indicator

Table 1 : Layout o the encapsulation

A corresponding mechanism is applied to the uplink direction.

Once the UE has synchronized with the new target eNB and with the receipt of the "Handover confirmation" message sent by the UE at the target eNB, the target eNB forwards the Handover confirmation message to the source eNB. On receipt of the handover confirmation message at the source eNB, the resources are released and the handover procedure is completed. Furthermore, the target eNB sends a Gratuitous ARP request as in the case of the Fig. 12 (initial Attach) to announce that the IP address is reachable with the new combination of IP Address and MAC address at the target eNB. For instance in case the target eNB belongs to the AM-U2, the AM-U2 informs the AM-C via OF packet IN. The AM-C updates the CLR and the AM-C configures the AM-U2 and AM-U1 such that the packets to and from the target eNB and the source eNB are swapped at the AM-Us accordingly.

As already stated, the above description is valid for the case where the UE leaves the area of one AM-U and attaches to an eNB which is connected to the area of another AM-U.

In case the two eNBs are served by the same AM-U the HO procedure is simpler in the sense that the AM-C(/CLR)

a) will not respond with the OF ARP Reply towards the Source eNB as depicted in Fig.

13 , since the target eNB itself will respond with its own ARP reply

b) will also not issue the OF ModFlow message to both the AM-U1 and AM-U1 , since the both eNBs are within the range of the same AM-U thus directly connected where no modification of AM-Us is needed and therefore the eNB B will respond with its own ARP reply

c) will also not send an OF Gratuitous ARP reply to the eNB B, as the eNB B will receive the gratuitous ARP Request (being sent by the eNB A) directly and therefore the eNB B will respond directly with an ARP reply

Handover optimization procedure (HOO) The forwarding of payload data from the source eNB to the target eNB has the drawback that it adds additional latency and creates a possible bottleneck at the eNB, as the packets arrive at the source eNB first and are then forwarded to the final destination.

It would be highly beneficial to be able to shortcut this bottleneck and to minimize the additional delay. It would be much beneficial to "multicast" the packets at an advantageous location, such that packets are sent to both the source and target eNB.

In some embodiments of the invention, in the case of GLAN, there may be further SDN enabled switches deployed in the layer 2 network, which are instructed via SDN means to duplicate traffic to the source eNB and also to the target eNB.

That is, in order to save transport costs, payload data for UE1 received after eNB A instructed UE1 to handover and before handover is completed may not be forwarded from eNB A to eNB B. Instead, the SDN controller identifies a suitable node which dual-casts the data to both eNB A and eNB B. SDN controller may select the node such that a total length of the transport paths is minimized (i.e. a root of a star of the source eNB, the target eNB, and an ingress point of a payload traffic to the terminal).

The best location for this duplication would be the switch, which is at the intersection of the paths of a star built by the three endpoints source eNB, target eNB and the eNB where partner UE is attached to (in case of UE-UE communication) or the ingress point of the traffic into the network. Normal SDN controller with topology knowledge are able to identify and calculate the root of this star. If a node does not exist at the root, the SDN controller may determine the node closest to the root of the star.

To enable the advantageous duplication of packets, it is suggested that the source eNB informs a new "HO optimisation application" (HOO) (riding on top of a SDN controller) about the three participating eNBs (or two eNBs and the ingress point) and the addresses of the two UEs for which the optimisation is requested. Therefore, it is proposed to send a new "HO optimization request" message to the HOO application, when the source eNB receives the "prepare HO Ack" message. This new message contains the IP/MAC address for the user plane of each of the involved eNBs (ingress point) and the Context ID of the UE being handed over. Furthermore, the IP and MAC addresses of the participating UEs are also signalled. Based on this information the HOO application calculates the root of the star of the three eNBs (or two eNBs and the ingress point). Furthermore, with the IP/MAC address of the participating UEs, the HOO application instructs said root switch via its SDN Controller to additionally duplicate, so that the downlink packets sent to the source eNB will also be sent to the target eNB. E.g., the SDN controller may encapsulate them into outer IP Packets while prepending said context ID and the down link indication to the original payload.

Alternatively instead of sending the "HO optimization request" message on receiving the "prepare HO Ack" message, the source eNB may also issue a "tentative HO optimization request" message when sending the "prepare HO" message, if the calculation of the root switch at the HOO application is expected to take too long.

Preferably, at least at the receipt of the "prepare HO Ack" message the HOO application should be notified to perform the start of the duplication of the packets towards the target eNB. On receipt of the handover confirmation message at the source eNB, the source eNB instructs the HOO application to stop the forwarding at the root switch to source and target eNB.

The HOO procedure may be further optimised in case the UE performs a handover from where the AM-U is changed. In this case, a HOO application riding on top of the SDN-C in parallel with the AM-C, the HOO application could request to be notified about the traverse of the "prepare handover", prepare "handover ack" and the "handover confirmation" messages, which allows the HOO application to get knowledge of the participating eNBs. Furhermore the HOO application should also request the notification of the gratuitous ARP on behalf of each UE. Thus, the HOO application is able to instruct the root switch without additional impact on the eNBs.

The HOO procedure is an optional procedure which allows to improve QoE (quality of experience) and relief the network from additional traffic.

Fig. 14 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station such as a NodeB or eNodeB or a cell, or an element thereof. For example, the apparatus may act as a source eNB in a handover procedure, but the name "source eNB" does not imply that the eNB is actually involved in any handover procedure. Fig. 15 shows a method according to an embodiment of the invention. The apparatus according to Fig. 14 may perform the method of Fig. 15 but is not limited to this method. The method of Fig. 15 may be performed by the apparatus of Fig. 14 but is not limited to being performed by this apparatus. The apparatus comprises retrieving means 10, determining means 20, identifying means 30, and instructing means 40. The retrieving means 10, determining means 20, identifying means 30, and instructing means 40 may be retrieving processor, determining processor, identifying processor, and instructing processor, respectively.

The retrieving means 10 retrieves a target address of an IP from a header of a downlink packet of the IP received by a source cell (S10). The target address and the downlink packet are an address and a packet, respectively, of an internet protocol. The downlink packet is addressed to the target address, and the downlink packet comprises the header and a payload.

The determining means 20 determines a radio access bearer identifier associated to the target address (S20).

The identifying means 30 identifies a terminal address based on the target address (S30). The terminal address is an address of the internet protocol, too. For example, the terminal address may be the same as the target address. As another example, the target address may comprise a port number based on which the determining means 20 determines the radio access bearer, but the terminal address does not comprise the port number.

The instructing means 40 instructs to forward the terminal address and the payload of the downlink packet in a PDCP context on a radio bearer identified by the radio access bearer identifier determined by the determining means 20 (S40).

Fig. 16 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station such as a NodeB or eNodeB or a cell, or an element thereof. For example, the apparatus may act as a source eNB in a handover procedure, but the name "source eNB" does not imply that the eNB is actually involved in any handover procedure. Fig. 17 shows a method according to an embodiment of the invention. The apparatus according to Fig. 16 may perform the method of Fig. 17 but is not limited to this method. The method of Fig. 17 may be performed by the apparatus of Fig. 16 but is not limited to being performed by this apparatus.

The apparatus comprises retrieving means 1 10, forming means 120, and instructing means 130. The retrieving means 1 10, forming means 120, and instructing means 130 may be retrieving processor, forming processor, and instructing processor, respectively. The retrieving means 1 10 retrieves a terminal IP address and a payload from an uplink packet received by a source cell in a PDCP context on a radio access bearer (S1 10). The forming means 120 forms an IP packet comprising a header and the payload (S120). The header comprises an origin IP address as an origin. The origin IP address is the terminal IP address. The instructing means 130 instructs to transmit the IP packet (S130).

Fig. 18 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station such as a NodeB or eNodeB or a cell, or an element thereof. For example, the apparatus may act as a source eNB in a handover procedure, but the name "source eNB" does not imply that the eNB is actually involved in any handover procedure. Fig. 19 shows a method according to an embodiment of the invention. The apparatus according to Fig. 18 may perform the method of Fig. 19 but is not limited to this method. The method of Fig. 19 may be performed by the apparatus of Fig. 18 but is not limited to being performed by this apparatus.

The apparatus comprises retrieving means 210, identifying means 220, forming means 230, and instructing means 240. The retrieving means 210, identifying means 220, forming means 230, and instructing means 240 may be retrieving processor, identifying processor, forming processor, and instructing processor, respectively.

The retrieving means 210 retrieves a payload from an uplink packet received by a source cell in a PDCP context on a radio access bearer (S210). The uplink packet comprises the payload and a terminal IP address.

The identifying means 220 identifies an origin IP address based on an identifier of the radio access bearer (S220).

The forming means 230 forms an IP packet comprising a header and the payload (S230). The header comprises the origin IP address as an origin. The instructing means 240 instructs to transmit the IP packet (S240).

Fig. 20 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station such as a NodeB or eNodeB or a cell, or an element thereof. For example, the apparatus may act as a source eNB in a handover procedure, but the name "source eNB" does not imply that the eNB is actually involved in any handover procedure. Fig. 21 shows a method according to an embodiment of the invention. The apparatus according to Fig. 20 may perform the method of Fig. 21 but is not limited to this method. The method of Fig. 21 may be performed by the apparatus of Fig. 20 but is not limited to being performed by this apparatus. The apparatus comprises retrieving means 310, determining means 320, and instructing means 330. The retrieving means 310, determining means 320, and instructing means 330 may be retrieving processor, determining processor, and instructing processor, respectively.

The retrieving means 310 retrieves a target address from a header of a downlink packet received by a source cell (S310). The target address and the downlink packet are an address and a packet, respectively, of a L2 protocol. The downlink packet is addressed to the target address, and the downlink packet comprises the header and a payload.

The determining means 320 determines a radio access bearer identifier associated to the target address (S320). The instructing means 330 instructs to forward the payload of the downlink packet in a PDCP context on a radio bearer identified by the radio access bearer identifier (S330).

Fig. 22 shows an apparatus according to an embodiment of the invention. The apparatus may be a base station such as a NodeB or eNodeB or a cell, or an element thereof. For example, the apparatus may act as a source eNB in a handover procedure, but the name "source eNB" does not imply that the eNB is actually involved in any handover procedure. Fig. 23 shows a method according to an embodiment of the invention. The apparatus according to Fig. 22 may perform the method of Fig. 23 but is not limited to this method. The method of Fig. 23 may be performed by the apparatus of Fig. 22 but is not limited to being performed by this apparatus.

The apparatus comprises retrieving means 410, identifying means 420, forming means 430, and instructing means 430. The retrieving means 410, identifying means 420, forming means 430, and instructing means 430 may be retrieving processor, identifying processor, forming processor, and instructing processor, respectively.

The retrieving means 410 retrieves a payload from an uplink packet received by a source cell in a PDCP context on a radio access bearer (S410).

The identifying means 420 identifies an origin address based on an identifier of the radio access bearer (S420). The origin address is of a L2 protocol. The forming means 430 forms a L2 packet (i.e. a packet of the L2 protocol) comprising a header and the payload (S430). The header of the L2 packet comprises the origin address as an origin. The instructing means 440 instructs to transmit the L2 packet (S440).

Fig. 24 shows an apparatus according to an embodiment of the invention. The apparatus may be a data repository such as a handover database, or an element thereof. Fig. 25 shows a method according to an embodiment of the invention. The apparatus according to Fig. 24 may perform the method of Fig. 25 but is not limited to this method. The method of Fig. 25 may be performed by the apparatus of Fig. 24 but is not limited to being performed by this apparatus.

The apparatus comprises monitoring means 510, and providing means 520. The monitoring means 510, and providing means 520 may be monitoring processor and providing processor, respectively.

The monitoring means 510 monitors if a request for a target cell address is received (S510). The request comprises a cell identifier.

In response to the request (S510 = "yes"), the providing means 520 provides the target address (S520). The target cell address is of an IP address or an address of a L2 protocol, and the cell identifier is of a protocol different from the IP and the L2 protocol.

Fig. 26 shows an apparatus according to an embodiment of the invention. The apparatus may be a handover optimization function, e.g. in a SDN controller, or an element thereof. Fig. 27 shows a method according to an embodiment of the invention. The apparatus according to Fig. 26 may perform the method of Fig. 27 but is not limited to this method. The method of Fig. 27 may be performed by the apparatus of Fig. 26 but is not limited to being performed by this apparatus.

The apparatus comprises determining means 610 and instructing means 620. The determining means 610 and instructing means 620 may be a determining processor and instructing processor, respectively.

The determining means 610 determines a node being closest to a root of a star of a source base station, a target base station, and an ingress point of a payload traffic to a terminal (S610). In particular, the determining means 610 determines the node if a handover of the terminal from the source base station to the target base station is being prepared. The instructing means 620 instructs the node to forward ("dual-cast") the payload traffic from the ingress point to both the source base station and the target base station (S620).

Fig. 28 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 710, at least one memory 720 including computer program code, and the at least one processor 710, with the at least one memory 720 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to Figs. 15, 17, 19, 21 , 23, 25, and 27.

If encryption is not used in a network, ciphering keys may not be used and are accordingly not transmitted in the handover preparation message.

Typically, handover is started only after the target eNB acknowledges that the handover is prepared. However, in some embodiments of the invention, the source eNB may start the handover after lapse of a predetermined time after it provided the handover preparation message to the target eNB.

Typically, the source eNB releases the resources for a UE after receipt of the handover confirmation message. However, in some embodiments of the invention, the source eNB may release the resources after lapse of a predetermined time after it instructed the UE to handover.

Embodiments of the invention may be employed in a LTE-A network as 3GPP network. They may be employed also in other mobile networks such as CDMA, EDGE, LTE, UTRAN networks, etc.

A terminal may be a user equipment such as a mobile phone, a smart phone, a PDA, a laptop, a tablet PC, a wearable, a machine-to-machine device, or any other device which may be connected to the respective mobile network.

One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality. If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be embodied in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example a base station such as a eNodeB, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example a data repository such as a handover database, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.