WO2018095506A1

WO2018095506A1 - Optimized user plane path selection

Info

Publication number: WO2018095506A1
Application number: PCT/EP2016/078363
Authority: WO
Inventors: Prashanth B R; Sudhish KANICHU VEEDU
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2016-11-22
Filing date: 2016-11-22
Publication date: 2018-05-31

Abstract

It is provided a method, comprising monitoring if a packet is received from a source device identified by a source address, wherein the packet is directed to a destination device identified by a destination address; checking if an entry for an address combination is stored, wherein the address combination comprises the source address and the destination address; deciding if the entry comprises a destination tunnel endpoint identifier related to the destination address, forwarding the packet to the destination device in a downlink context identified by the destination tunnel endpoint identifier if the packet is received from the source device and directed to the destination device and if the entry is stored for the address combination and comprises the destination tunnel endpoint identifier.

Description

DESCRIPTION

TITLE

Optimized user plane path selection

Field of the invention

The present invention relates to an apparatus, a method, and a computer program product related to a mobile communication networks. More particularly, the present invention relates to an apparatus, a method, and a computer program product of a mobile network providing UE-to-UE communication.

Abbreviations

3GPP Third Generation Partnership Project

4G 4th Generation

5G 5th Generation

DL Downlink

eNB evolved NodeB

EPC Evolved Packet Core

E-UTRAN Evolved UTRAN

GPRS General Packet Radio System

GTP GPRS Tunnelling Protocol

GTP-U GTP User Plane

IP Internet Protocol

LCD Localization Context Detection

LCS Localization Context State

LRF Local Routing Function

LRT Local Routing Table LTE Long Term Evolution

LTE-A LTE-Advanced

MEC Mobile Edge Computing

MME Mobility Management Entity

MQTT Message Queuing Telemetry Transport

P2P Peer-to-Peer

PDN Packet Data Network

PDP Packet Data Protocol

PGW PDN Gateway

Pub-Sub Publish-Subscribe

RNIS Radio Network Information Service

RTT Round Trip Time

SGW Serving Gateway

TCP Transmission Control Protocol

Tel D Tunnel endpoint Identifier

TS Technical Specification

UDP User Datagram Protocol

UE User Equipment

UL Uplink

UTRAN Universal Terrestrial Radio Access Netv

VNF Virtual Network Function

Background of the invention

One of the critical requirements of 5G is to bring down the end to end user plane latency. Besides Mobile Edge Computing (MEC) is a key component in 5G network architecture. MEC can be used as a key enabler to address the low latency requirement in 5G or 4G scenarios. 5G attempts to address the low latency requirement for a wide variety of use cases targeting UE to UE communication, such as Drone to Drone controller

communication, vehicular communications, tactile Internet, Industrial communications etc. Besides, a range of P2P applications such as P2P chat, P2P Video, P2P Gaming would also benefit from low end to end latency. Accordingly, MEC can be uniquely positioned to address the low latency requirements for several 5G and 4G use cases.

MEC enables the deployment of services and applications in close proximity of base stations and enables them to take advantage of the information in the local environment to provide better quality or more relevant/targeted services to the end users. The MEC system is typically deployed within a radio cloud environment, and provides access to user plane packets and also provides significant control plane information to dedicated network applications. An example of such control plane information is the identity of user's serving cell. Likewise, another example of control plane information could be the TelD of a specific GTP bearer. Note that a TelD identifies a PDP context of the UE in the SGW and PGW. The PDP context and, thus, the TelD may be bearer specific.

Fig. 1 shows a generic MEC Application Framework that comprises the MEC platform and a set of MEC Applications VNF's. MEC platform provides the virtualization environment for hosting applications VNF's. As shown in the Figure, MEC platform could connect to a cluster of eNB's (such as eNB1 , eNB2, and eNB3) over a Layer 2 or Layer 3 network. The eNBs serve UEs, as an example shown as UE1 , UE2, and UE3.

Fig. 1 shows "traffic offload" component of the MEC platform that is responsible for offloading the S1 user plane (S1 -U) packets to application VNF's and/or a "Radio Network Information Service (RNIS)" component that is responsible to provide LTE control plane (S1 -C) information to application VNF's. The Life cycle management service provided by the MEC platform is responsible for startup, configuration and shutdown of the application virtual machines. The optimized user plane path selection logic described here could be a MEC application VNF.

In wireless communication networks such as 4G LTE, all user plane packets are sent from E-UTRAN to EPC network elements. The user plane routing between the end

communicating entities is then centrally handled by PGW. In case of applications that need very low end to end latency, the RTT delay incurred as each packet goes through EPC core network elements SGW and PGW may not be acceptable. A few candidate example use cases that demand very low latency include Drone to Drone controller communications, vehicle to vehicle communications etc.

That is, according to the prior art, all traffic initiated by a UE will be sent towards PGW and routed via PGW regardless of the location of the destination. The prior art assumes that all communications are destined towards end points connected to Internet and reachable via PGW's SGi interface (see e.g. 3GPP TS 23401 -d70). UE Traffic (such as IP traffic) is sent on a single S1 GTPU tunnel between eNB and S-GW for both uplink and downlink direction for every unique bearer . This tunnel is identified at the eNB by uplink Tel D and at SGW by downlink TelD. Uplink Tel D is generated by the SGW and downlink TelD is generated by the eNB. An S1 bearer transports the UE traffic packets between an eNodeB and S-GW.

Summary of the invention

It is an object of the present invention to improve the prior art.

According to a first 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 at least monitoring if a packet is received from a source device identified by a source address, wherein the packet is directed to a destination device identified by a destination address; checking if an entry for an address combination is stored, wherein the address combination comprises the source address and the destination address; deciding if the entry comprises a destination tunnel endpoint identifier related to the destination address, forwarding the packet to the destination device in a downlink context identified by the destination tunnel endpoint identifier if the packet is received from the source device and directed to the destination device and if the entry is stored for the address combination and comprises the destination tunnel endpoint identifier.

The at least one memory and the computer program code may be arranged to cause the apparatus to further perform creating the entry for the address combination if the entry for the address combination is not stored.

The at least one memory and the computer program code may be arranged to cause the apparatus to further perform checking if the packet is received in the uplink direction; and inhibiting the creating of the entry if the packet is not received in the uplink direction.

The at least one memory and the computer program code may be arranged to cause the apparatus to further perform if the entry is stored for the address combination, checking if the packet is a downlink packet; storing the destination tunnel endpoint identifier of the packet in the entry if the entry is stored for the address combination and if the packet is a downlink packet. The at least one memory and the computer program code may be arranged to cause the apparatus to further perform inhibiting the storing of the destination tunnel endpoint identifier in the entry if the packet is not a downlink packet.

The at least one memory and the computer program code may be arranged to cause the apparatus to further perform setting a flag for the entry to a first value if the entry comprises the destination tunnel endpoint identifier; setting the flag to a second value different from the first value if the entry does not comprise the destination tunnel endpoint identifier; wherein the deciding if the entry comprises the destination tunnel endpoint identifier comprises checking if the flag has the first value.

The address combination may comprise the source address and the destination address in an ordered manner.

The at least one memory and the computer program code may be arranged to cause the apparatus to further perform calculating a hash value for the stored address combination and storing the hash value as a stored hash value in the entry; calculating the hash value for the source address and the destination address in the packet in order to obtain a calculated hash value; wherein the checking if the entry for the address combination is stored comprises checking if the calculated hash value matches the stored hash value.

According to a second aspect of the invention, there is provided a method, comprising monitoring if a packet is received from a source device identified by a source address, wherein the packet is directed to a destination device identified by a destination address; checking if an entry for an address combination is stored, wherein the address

combination comprises the source address and the destination address; deciding if the entry comprises a destination tunnel endpoint identifier related to the destination address, forwarding the packet to the destination device in a downlink context identified by the destination tunnel endpoint identifier if the packet is received from the source device and directed to the destination device and if the entry is stored for the address combination and comprises the destination tunnel endpoint identifier.

The method may further comprise creating the entry for the address combination if the entry for the address combination is not stored.

The method may further comprise checking if the packet is received in the uplink direction; and inhibiting the creating of the entry if the packet is not received in the uplink direction. The method may further comprise if the entry is stored for the address combination, checking if the packet is a downlink packet; storing the destination tunnel endpoint identifier of the packet in the entry if the entry is stored for the address combination and if the packet is a downlink packet.

The method may further comprise inhibiting the storing of the destination tunnel endpoint identifier in the entry if the packet is not a downlink packet. The method may further comprise setting a flag for the entry to a first value if the entry comprises the destination tunnel endpoint identifier; setting the flag to a second value different from the first value if the entry does not comprise the destination tunnel endpoint identifier; wherein the deciding if the entry comprises the destination tunnel endpoint identifier comprises checking if the flag has the first value.

The method may further comprise calculating a hash value for the stored address combination and storing the hash value as a stored hash value in the entry; calculating the hash value for the source address and the destination address in the packet in order to obtain a calculated hash value; wherein the checking if the entry for the address combination is stored comprises checking if the calculated hash value matches the stored hash value.

The method may be a method of UE-to-UE communication.

According to a third 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 the second aspect. 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: latency for UE to UE communication may be reduced;

bandwidth requirements on the backhaul may be reduced;

signaling and processing load on the core network may be reduced.

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 generic MEC application framework;

Fig. 2a shows a MEC application framework according to some embodiments of the invention;

Figs. 2b to 2d show packet flows according to some embodiments of the invention;

Fig. 3a shows an entry of a LRT according to some embodiments of the invention;

Fig. 3b shows a LRT according to some embodiments of the invention;

Fig. 4 shows a LCD method according to some embodiments of the invention;

Fig. 5 shows a detail of a LCD method according to some embodiments of the invention;

Fig. 6 shows a detail of a LCD method according to some embodiments of the invention;

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

Fig. 8 shows a packet flow according to some embodiments of the invention;

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

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

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

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 described.

Some embodiments of the invention provide a MEC hosted application service that learns the fact that the two communicating end points (User Equipments, UEs) are within close proximity and then chooses an optimal routing path for packets exchanged between such end points. The proximity decision is based on whether the two UE's are served by the same cell or two cells of a same eNB or two eNB's connected to the same instance of the MEC platform, wherein the eNBs themselves could constitute any kind of cells such as macro eNBs or small cells (pico cells, femto cells etc.). The IP flows that are detected to be "localized" are then routed through the MEC platform itself and not routed to the EPC.

The proximity decision as described through this invention does not rely on any LTE control plane signalling. It is based on simple inspection of LTE user plane GTP-U packets. The proximity decision logic detects whether both the uplink and downlink flows associated with an end-to-end bidirectional communication pass through the same instance of MEC platform. The flows that are evaluated to be "localized" are then routed at the MEC platform itself using the user plane path selector application service described hereinafter, thereby bypassing traffic forwarding towards EPC. The optimized routing involves intercepting the GTP packet entering the MEC platform in uplink direction and then replacing the GTP-TelD in the uplink packet with the GTP TelD of the peer UE and sending the packet in downlink towards eNB.

As shown in the Fig 2a, the optimized user plane path selector VNF that executes the logic comprises a localization context detection function and a localized routing function. The localization context detection function (LCD) populates the local routing table (LRT) after inspecting the uplink and downlink flows. The local routing table stores the GTP Tel D's of the peer UE's that are involved in the end to end communication. The localized routing function LRF changes the GTP TelD of the received packet in uplink direction with the GTP TelD associated with the peer UE and sends the packets in downlink direction towards eNB. As shown in Figs. 2b to 2d, LCD and LRF may act in different sequences on a packet. For example, as shown in Fig. 2b, a packet may first be evaluated by LCD, and then passed to LRF. Thus, an update of the LRT by LCD may be taken into account by LRF. In an alternative way, as shown in Fig. 2c, a packet may be treated first by LRF, and then passed to EPC or eNB depending on whether or not the flow is localized. The packet passed through LRF is additionally forwarded to LCD in order to update LRT, if needed. In a still further alternative as shown in Fig 2d, the packet is treated by LCD and LRF in parallel. The options of Figs. 2c and 2d have a lower latency in the handling by the user plane path selector, but they do not take into account potential changes of the LRT due to the packet under discussion.

The options of Figs. 2b to 2d may depend on implementation. In some embodiments, the sequence may be selected e.g. based on a type of UE. E.g. , if the UE is a UE for vehicle- to-vehicle communication, the lower latency of Figs. 2c and 2d may be selected. Also, in case the UE is typically static (e.g. in some machine type communication), changes of the LRT may be seldom such that one of the options of Figs. 2c and 2d may be selected. On the other hand, for "normal" UEs (subscriber related UEs), the latency is typically not critical, and it might be preferred to include any latest changes to LRT in the routing by LRF. Therefore, the option of Fig. 2b may be preferred for subscriber related UEs.

A logic of the user plane path selector VNF according to some embodiments of the invention is described. The local routing functionality LRF uses a Local Routing Table (LRT). Local context Detection (LCD) is responsible to create entries and to update the fields of each LRT entry after inspecting the uplink and downlink flows. Based on the LRT entry, the LRF routes the packet either towards eNB (and not to SGW as part of EPC) which is described as "local routing" or towards the SGW for all flows that are not to be locally routed according to the respective entry in LRT.

Fig. 3a shows an entry in an example LRT. In Fig. 3a, downlink UE TelD (sometimes also named "destination UE downlink TelD") is the downlink TelD of the S1 -U bearer associated with the UE that receives this packet in downlink direction. Likewise, uplink UE Tel D is the uplink TelD of the S1 -U bearer associated with the UE that has sent this packet in the uplink direction. The IP packet 5- tuple comprises source and destination IP addresses, source and destination TCP/UDP ports, protocol) of the associated UL/DL flow. The IP packet 5-tuple is an example of an address combination, and source and destination IP addresses are examples of addresses. In some embodiments of the invention, the address combination may not comprise at least one of the source and destination TCP/UDP ports and the protocol. In some embodiments, the LRT does not store the uplink TelD of the UE. Fig. 3b shows an implementation example of the LRT according to some embodiments of the invention. Each entry has a hash (hashl to hash-in), which may be used as a primary key to select an entry Columns 2 and 3 of the LRT comprise Tel Ds (uplink TelD is optional depending on implementation), and column 4 comprises an address combination such as an IP 5-tuple. In column 5, it is indicated by a flag if a corresponding flow may be locally routed.

The sequence of the columns is arbitrary, and Fig. 3b shows one example. The LRT may be implemented as part of a database.

The Tel Ds are related to the addresses in the address combination. For example, the uplink Tel D (if it is stored in the LRT) is related to the source IP address and the downlink Tel D is related to the destination IP address. The control flow of the LCD function, responsible for creating and updating fields in LRT is illustrated in Figs. 4 to 6. In these Figures, the IP 5-tuple is used as an example of an address combination.

As shown in the Fig. 4, for all the uplink and downlink packets passing through the MEC platform, the Localization Context Detection (LCD) function receives the I P 5-tuple (source and destination IP address, source and destination TCP/UDP port, protocol) of the associated UL/DL flow (S41 ). For every such received IP 5-tuple information, LCD generates a hash using the IP 5-tuple that represents a unique identifier for the associated flow (S42). It then checks for an entry in the local routing table matching the generated hash (S43). If LCD does not find an entry, it creates a new entry in the local routing table (S45). This is shown at greater detail in Fig. 5. If an entry is found, LCD may potentially fill the TelD of the respective communication end point into the entry, potentially after validating that the same is not yet filled. For details, see Fig. 6. As shown in Fig. 5, when creating a new entry in the local routing table (S51

corresponding to e.g. S45), LCD checks the packet direction (S52). If the packet is received in downlink, the downlink UE TelD and IP 5-tuple are stored in the local routing table (S54). If packet is received in uplink, the uplink UE TelD (if storing thereof is implemented) and IP 5-tuple are stored in the local routing table (S53). The "Localization Context State (LCS)" (last column in Fig. 3B) is then set to a first value (e.g. "initialized") (S55). If storing of uplink TelD is not implemented, S53 is omitted and the flow passes directly from S52 to S55 if the packet is in uplink direction. As shown in Fig 6, updating local routing table entry (e.g. S44) involves learning the Tel D of the peer UE and completing the TelD pair combination stored in the local routing table. As an illustrative example, in the case of vehicular networking involving two vehicles communicating over LTE wireless network, the TelD pair would be the TelD's of the respective communicating vehicles. A precondition for this update functionality is that the LCS in the local routing table is set to "initialized", which means that the TelD of one of the paired UE's is already stored in the local routing table. This is checked in S61 . If the value of LCS is different from "initialized" (e.g. "local route detected", which is a second value different from the first value), the flow jumps to S62. If the LRF execution follows LCD processing (Fig. 2b), the flow may then jump to LRF (Fig. 7). In particular, in some embodiments, it may jump immediately to S75 of Fig. 7.

The execution of the LCD logic continues only for the flows whose "localization context state" is "initialized" and for such flows, LCD checks the packet direction (S63). If the packet direction is uplink, LCD checks whether the downlink UE TelD is already stored in the LRT (S64) and if so, the uplink UE TelD is also stored (S65). Correspondingly, if the packet direction is downlink, LCD checks whether the uplink UE TelD is already stored in the LRT (S66) and if so, the downlink UE TelD is also stored (S67). After the second Tel D is stored, the status of LCS is changed to "local route detected" (S66), the other of the two values LCS can have. Then, the LCD flow stops (S69). If the flow continues from LCD to LRF (Fig. 2b), it may then flow to LRF (Fig. 7). In some embodiments, the flow may jump immediately to S75 of Fig. 7.

If the check in S64 or S66 is negative, it means that the packet under consideration is received in a PDP context whose TelD is already stored in the entry. Hence, the LCD logic stops here (S650, S670). If the flow continues to LRF (Fig. 2b), the flow may jump to LRF. In some embodiments, it may jump immediately to S76 of Fig. 7.

In embodiments, where uplink TelD is not stored, S65 may be omitted. Instead, if the downlink UE TelD is already stored in the LRT for the address combination (S64 = "yes"), the localization context state is set to "local route detected" (the second value this field can have),

As can be seen from the description of the LCD logic, it is sufficient that LCD receives the Tel D at the UE's end of the tunnel and the address combination (e.g. IP 5-tuple) of the packet. LCD need not to receive the packet. Therefore, in some embodiments according to Figs. 2c and 2d, the packet is not forwarded to LCD but only the address combination and Tel Ds. For example, in embodiments according to Fig. 2c (LCD follows LRF), LRF anyway retrieves address combination and TelD from the received packet and may forward them to LCD. Also for example, in embodiments according to Fig. 2d (LCD in parallel to LRF), address combination and TelD may be retrieved by a retrieval function from a packet either on its path to LCD only or before the branching to LCD and LRF. In the latter case, LRF need not to retrieve again address combination and TelD from the packet but may receive it from the retrieval function.

The control flow for LRF is shown in Fig 7 and the associated packet flow is shown in Fig 8. Fig. 8 corresponds to Fig. 1 , wherein the flow of the packets for local routing and routing to SGW are additionally shown.

As shown in Fig. 7, when LRF receives a packet (S71 ), it uses the 5-tuple information in the packet header and generates a hash to index into the LRT (S72). LRF may receive the packet either from LCD (Fig. 2b) or directly from the traffic offload function (Figs. 2c, 2d).

LRF checks if there is an entry in LRT indexed by the hash calculated for the packet (S73). If there is an entry, LRF checks if the localization context state is "local route detected" (S74). If yes, LRF does not forward the packet to SGW but forwards the packet towards eNB by way of insertion (Tel D modification) into peer UE's downlink tunnel (S75). If there is no entry for the hash or if LRF finds the LCS of the entry with value "initialized", it forwards the packet towards SGW according to conventional LTE packet flow (S76).

If the packet flow of Fig. 2c is implemented (LCD follows LRF) and the packet is forwarded to SGW, LRF may additionally forwards the packet to LCD. In some embodiments, it forwards only the address combination (IP 5-tuple) and source TelD to LCD (S77). The flow may then jump immediately to S42 of Fig. 4.

If the packet flow of Fig. 2c is implemented (LCD follows LRF) and the packet is forwarded to eNB (S75), the packet (or the address combination and TelD) may be forwarded to LCD, too. However, such forwarding may not be needed because the entry in the LRT is already present and complete. Thus, such forwarding is not performed in some embodiments.

In some embodiments of the invention, the LCS status value may not be used and the column may not be present in LRT. In these embodiments, instead of S74, LRF may check if the TelDs related to the source and the destination are stored in the LRT. If both Tel Ds are stored, LRF applies local routing (S75).

Fig. 8 shows the LRF packet flow. The Figure shows LRF handling two network interfaces named e.g. eth eNB and eth SGW which are the interfaces towards eNB(s) and SGW, respectively, as seen from the application VNF's perspective. When LRF receives packets from traffic offload function or LCD, for those packets which are marked to be "locally routed" in the LRT, the inner I P packets are extracted and encapsulated into the peer GTP tunnel (peer TelD is learnt by LRT lookup). This new GTP packet so created will be forwarded to the eth eNB interface. Packets put on eth eNB by User Plane Path Selector VNF will be sent towards eNB cluster by MEC platform (solid line in Fig. 8). Likewise, packets sent on eth SGW interface by User Plane Path Selector application VNF will be forwarded to SGW by MEC platform (dashed line in Fig. 8). Fig. 8 shows that locally routed packets enter LRF through eth eNB (potentially with LCD in between) and such packets after GTP tunnel modification are sent back on the same interface by LRF.

Packets that do not qualify local routing criterion will continue to have LCS state as "initialized". Such packets are routed to SGW.

A received packet is a packet in uplink direction, if it is received from the interface towards the eNB(s). If a packet is received on interface towards eNB(s) (eth eNB), then the associated destination Tel D belongs to SGW and it is a uplink packet. If a packet is received on interface towards SGW (eth SGW), then the associated destination TelD belongs to eNB and it is a downlink packet. Thus, LCD, when filling the LRT, can decide if a packet is in uplink direction or in downlink direction.

Hashing (S42, S72) is used to simplify search for a suitable entry in LRT. However, in some embodiments of the invention, hashing (S42, S72) may not be used and the corresponding column may not be present in the LRT. In these embodiments, LCD and/or LRF may search for a combination of the source and destination addresses stored in the address combination (instead of for a matching hash according to S43, S73).

In some embodiments of the invention, local routing may be applied to both of an (I P) request and an (I P) response. That is, if the source (source address IP1 ) sends a packet to a destination (destination address IP2) via local routing (i.e. the address combination (IP1 , IP2) and the downlink TelD of I P2 are stored as one entry in LRT), and the destination replies, LRF looks for the combination (IP2, I P1 ) and the downlink TelD of IP1 in LRT. If such entry is stored in LRT, local routing is applied to the response, too.

Otherwise, the response is routed via SGW.

If these embodiments use hashing, LRF may create a respective hash value for (IP1 , IP2) and for (IP2, IP1 ) and check if the relevant one of these hashes matches an entry in the LRT. Alternatively, LRF may create a hash which does not depend on the sequence of IP1 and IP2. Examples are a sum or a product of the hashes for (IP1 , IP2) and (IP2, IP1 ). In the latter case, one entry in the LRT may comprise the downlink TelDs of both addresses, wherein each of the downlink TelDs is related to the respective address. In addition, the entry may comprise the uplink TelDs of one or both addresses, if accordingly

implemented.

Some embodiments of the invention are applicable to a case where one UE has plural bearers corresponding to plural uplink and downlink tunnels with respective TelDs. In this case, a local I P flow may go through one (or more) of these uplink and downlink tunnels, and a flow to the internet or other destinations may go through the remaining uplink and downlink tunnels. Since LRT stores an address combination of source address and destination address, LRF may assign the correct downlink tunnel to an IP flow based on the address combination.

In contrast to that, one may consider a case where LRT does not store the address combination including the source address but only the destination address. Furthermore, for the one destination address of the destination UE, two TelDs (corresponding to two downlink tunnels for different bearers) may be stored. If LRF receives a packet to the destination IP address, it cannot decide which downlink tunnel is to be used for local routing.

On the other hand, since the source IP address is stored in LRT and the local routing is decided based on the address combination of source address and destination address according to some embodiments of the invention, LRF may select the same tunnel (bearer) which has been previously used for a packet from source address to destination address and which TelD is stored in LRT for the address combination.

In the following example cases, entries in LRT continue to remain in "initialized" state:

1 . In the case of regular Internet bound flows wherein MEC platform detects only the uplink or only the downlink leg.

2. If one of the UE's in the end to end communication is served by an eNB not connected to MEC platform.

These entries remaining in "initialized" state for ever consume memory resources and slow down the searching for an entry. Hence, a garbage collection mechanism may periodically check such stale entries in "initialized" state and cleans up such entries.

Also, an entry in the LRT may become wrong, e.g. if a UE moves to another base station. In order to remove such wrong entries, a garbage collection mechanism may remove entries if a packet flow has not been observed for a certain time. In some embodiments, LCD may check for each packet or some of the received packets if the uplink TelD of the PDP context in which the packet was received matches the uplink Tel D stored in the LRT related to the source IP address. If not, the stored uplink TelD in the LRT is replaced by the uplink TelD of the PDP context.

In some embodiments, in order to avoid unnecessary entries in the LRT, a new entry is created only based on the address combination of a packet in uplink direction.

Correspondingly, the downlink TelD is filled in an existing entry based on a packet received in downlink direction. A new entry is not created based on a packet received in downlink direction. Thus, it is ensured that the LRT comprises only address combinations which might potentially result in local routing.

For example, if a source UE (address IP1 ) sends a packet to a destination UE (address IP2) served by the same LRF and LCD and an entry for this address combination does not exist in the LRT, LCD receives the packet in uplink direction. It then creates an entry in the LRT for the address combination (I P1 , IP2) without an entry for destination TelD. LRF routes the packet to SGW. SGW sends the packet back to MEC comprising LRF and LCD. LCD sees that the entry for (I P1 , IP2) exists and that the packet is received in downlink. Hence, it fills downlink TelD into the entry. When source UE sends a next packet to destination UE, the packet is locally routed.

On the other hand, if a packet for destination UE is received e.g. from internet or from remote devices in downlink direction, an entry is not created because this flow can never be routed locally. Thus, unnecessary entries are avoided in LRT.

Fig. 9 shows an apparatus according to an embodiment of the invention. The apparatus may be a user plane path selector or an element thereof such as a LRF. Fig. 10 shows a method according to an embodiment of the invention. The apparatus according to Fig. 9 may perform the method of Fig. 10 but is not limited to this method. The method of Fig. 10 may be performed by the apparatus of Fig. 9 but is not limited to being performed by this apparatus.

The apparatus comprises monitoring means 910, checking means 920, deciding means 930, and forwarding means 940. The monitoring means 910, checking means 920, deciding means 930, and forwarding means 940 may be a monitoring processor, checking processor, deciding processor, and forwarding processor, respectively. The monitoring means 910 monitors if a packet is received from a source device identified by a source address, wherein the packet is directed to a destination device identified by a destination address (S910). Each of the source and destination devices may be a user equipment or another terminal.

The checking means 920 checks if an entry for an address combination is stored (S920). The address combination comprises the source address and the destination address identifying the source and destination devices, respectively.

The deciding means 930 decides if the entry comprises a destination tunnel endpoint identifier related to the destination address (S930).

If the packet is received from the source device and directed to the destination device (S910 = "yes") and if the entry is stored for the address combination (S920 = "yes") and comprises the destination tunnel endpoint identifier related to the destination address (S930 = "yes"), the forwarding means 940 forwards the packet to the destination device a downlink context identified by the destination tunnel endpoint identifier (S940).

Fig. 1 1 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 1 1 10, at least one memory 1 120 including computer program code, and the at least one processor 1 1 10, with the at least one memory 1 120 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to Fig. 10.

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

For example, embodiments of the invention may be deployed in a base station (e.g. eNB) such that communication between two UEs in base station is short-cut at the base station and does not involve the core network such as EPC.

A user equipment may be e.g. 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. If not otherwise indicated or made clear from the context, a UE is considered to include the meaning of a terminal for a user (typically a subscriber of the mobile network) and the meaning of a terminal without a user such as a machine-to-machine device.

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.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example a virtual network function such as a VNF of a MEC application, 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.

Claims

Claims:

1 . 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 at least

monitoring if a packet is received from a source device identified by a source address, wherein the packet is directed to a destination device identified by a destination address; checking if an entry for an address combination is stored, wherein the address combination comprises the source address and the destination address;

deciding if the entry comprises a destination tunnel endpoint identifier related to the destination address,

forwarding the packet to the destination device in a downlink context identified by the destination tunnel endpoint identifier if the packet is received from the source device and directed to the destination device and if the entry is stored for the address

combination and comprises the destination tunnel endpoint identifier.

2. The apparatus according to claim 1 , wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform

creating the entry for the address combination if the entry for the address combination is not stored.

3. The apparatus according to claim 2, wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform

checking if the packet is received in the uplink direction; and

inhibiting the creating of the entry if the packet is not received in the uplink direction.

4. The apparatus according to any of claims 2 and 3, wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform if the entry is stored for the address combination, checking if the packet is a downlink packet;

storing the destination tunnel endpoint identifier of the packet in the entry if the entry is stored for the address combination and if the packet is a downlink packet.

5. The apparatus according to claim 4, wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform

inhibiting the storing of the destination tunnel endpoint identifier in the entry if the packet is not a downlink packet.

6. The apparatus according to any of claims 1 to 5, wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform setting a flag for the entry to a first value if the entry comprises the destination tunnel endpoint identifier;

setting the flag to a second value different from the first value if the entry does not comprise the destination tunnel endpoint identifier; wherein

the deciding if the entry comprises the destination tunnel endpoint identifier comprises checking if the flag has the first value.

7. The apparatus according to any of claims 1 to 6, wherein the address combination comprises the source address and the destination address in an ordered manner.

8. The apparatus according to any of claims 1 to 7, wherein the at least one memory and the computer program code, is arranged to cause the apparatus to further perform

calculating a hash value for the stored address combination and storing the hash value as a stored hash value in the entry;

calculating the hash value for the source address and the destination address in the packet in order to obtain a calculated hash value; wherein

the checking if the entry for the address combination is stored comprises checking if the calculated hash value matches the stored hash value.

9. Method, comprising

forwarding the packet to the destination device in a downlink context identified by the destination tunnel endpoint identifier if the packet is received from the source device and directed to the destination device and if the entry is stored for the address combination and comprises the destination tunnel endpoint identifier.

10. The method according to claim 9, further comprising

1 1 . The method according to claim 10, further comprising

checking if the packet is received in the uplink direction; and

12. The method according to any of claims 10 and 1 1 , further comprising

if the entry is stored for the address combination, checking if the packet is a downlink packet;

13. The method according to claim 12, further comprising

14. The method according to any of claims 9 to 13, further comprising setting a flag for the entry to a first value if the entry comprises the destination tunnel endpoint identifier;

15. The method according to any of claims 9 to 14, wherein the address combination comprises the source address and the destination address in an ordered manner.

16. The method according to any of claims 9 to 15, further comprising

17. 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 claims 9 to 16.

18. The computer program product according to claim 17, embodied as a computer readable medium or directly loadable into a computer.