Patent Description:
Mobile Back-Haul networks typically depend on an anchor node, such as either one or both of a Serving Gateway (SGW) and a Packet Data Network (PDN) Gateway (PGW) to provide device administration services (such as traffic monitoring, policy enforcement, and generating reports for customer billing) pertaining to mobile electronic devices.

So-called anchorless networks have been proposed, but these proposals do not provide any means by which the device administration services may be maintained.

Document <CIT> discloses a wireless access point controller configured to associate each VLAN from the set of VLANs with a unique tunnel identifier from a set of tunnel identifiers. In particular, the wireless access point controller is configured to provide each wireless access point control information including the set of tunnel identifiers such that each wireless access point can send a data packet received from a wireless device to an access switch associated with a destination VLAN from the set of VLANs using the tunnel identifier associated with the destination VLAN.

Document <CIT> discloses a method for processing network traffic that is sent on a tunnel between a first tunnel and a second tunnel node in a communication network. In particular, an enhanced network address translation, eNAT, component is provided and comprises a first obtaining unit configured to obtain an uplink data packet from an uplink tunnel from the first tunnel node to the second tunnel node. The uplink data packet comprises a first network address associated with the first tunnel node, a second network address associated with the second tunnel node, a first identifier associated with the uplink tunnel an internal network address, and an internal port number. The eNAT further comprises a second obtaining unit configured to obtain a second identifier associated with a downlink tunnel from the second tunnel node to the first tunnel node. The downlink tunnel is related to the uplink tunnel. The eNAT further comprises a checking unit configured to check, based on the second network address and the first identifier, whether a database entry comprising the second network address and the first identifier exists in a database. The eNAT further comprises an up-dating unit configured to update the database in case the checked database entry does not exist in the database, and a manipulating unit configured to manipulate the uplink data packet.

It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.

Accordingly, the present invention is defined by methods for supporting anchorless backhaul in a mobile network according to independent claims <NUM> and <NUM>, and a node for supporting anchorless backhaul in a mobile network according to independent claim <NUM>.

In the following description, features of the present invention are described by way of example embodiments. For convenience of description, these embodiments make use of features and terminology known from <NUM> and <NUM> networks as defined by the Third Generation Partnership Project (3GPP). However, it shall be understood that the present invention is not limited to such networks. Rather, methods and systems in accordance with the present invention may be implemented in any network in which packets destined for an electronic device are routed through a tunnel to an Access Point connected to the electronic device. Similarly, for convenience of description, the example embodiments described herein make use of features of Generic Protocol Radio System (GPRS) Tunnel Protocol (GTP) tunnels established between a pair of endpoint nodes in the network. However, it shall be understood that the present invention is not limited to GTP tunnels. Rather, methods and systems in accordance with the present invention may be implemented using any tunneling protocol.

<FIG> is a block diagram of an electronic device (ED) <NUM> illustrated within a computing and communications environment <NUM> that may be used for implementing the devices and methods disclosed herein. In some embodiments, the electronic device <NUM> may be an element of communications network infrastructure, such as a base station (for example a NodeB, an enhanced Node B (eNodeB), a next generation NodeB (sometimes referred to as a gNodeB or gNB), a home subscriber server (HSS), a gateway (GW) such as a PDN Gateway (PGW) or a serving gateway (SGW) or various other nodes or functions within an evolved packet core (EPC) network. In other embodiments, the electronic device <NUM> may be a device that connects to network infrastructure over a radio interface, such as a mobile phone, smart phone or other such device that may be classified as a User Equipment (UE). In some embodiments, ED <NUM> may be a Machine Type Communications (MTC) device (also referred to as a machine-to-machine (m2m) device), or another such device that may be categorized as a UE despite not providing a direct service to a user. In some references, an ED <NUM> may also be referred to as a mobile device (MD), a term intended to reflect devices that connect to mobile network, regardless of whether the device itself is designed for, or capable of, mobility. Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processors, memories, transmitters, receivers, etc. The electronic device <NUM> typically includes a processor <NUM>, such as a Central Processing Unit (CPU), and may further include specialized processors such as a Graphics Processing Unit (GPU) or other such processor, a memory <NUM>, a network interface <NUM> and a bus <NUM> to connect the components of ED <NUM>. ED <NUM> may optionally also include components such as a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> (shown in dashed lines).

The memory <NUM> may comprise any type of non-transitory system memory, readable by the processor <NUM>, such as static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In some embodiments, the memory <NUM> may include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

The electronic device <NUM> may also include one or more network interfaces <NUM>, which may include at least one of a wired network interface and a wireless network interface. As illustrated in <FIG>, network interface <NUM> may include a wired network interface to connect to a network <NUM>, and also may include a radio access network interface <NUM> for connecting to other devices over a radio link. When ED <NUM> is network infrastructure, the radio access network interface <NUM> may be omitted for nodes or functions acting as elements of the Core Network (CN) other than those at the radio edge (e.g. an eNB). When ED <NUM> is infrastructure at the radio edge of a network, both wired and wireless network interfaces may be included. When ED <NUM> is a wirelessly connected device, such as a User Equipment, radio access network interface <NUM> may be present and it may be supplemented by other wireless interfaces such as WiFi network interfaces. The network interfaces <NUM> allow the electronic device <NUM> to communicate with remote entities such as those connected to network <NUM>.

The mass storage <NUM> may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, or an optical disk drive. In some embodiments, mass storage <NUM> may be remote to the electronic device <NUM> and accessible through use of a network interface such as interface <NUM>. In the illustrated embodiment, mass storage <NUM> is distinct from memory <NUM> where it is included, and may generally perform storage tasks compatible with higher latency, but may generally provide lesser or no volatility. In some embodiments, mass storage <NUM> may be integrated with a memory <NUM> to form an heterogeneous memory.

The optional video adapter <NUM> and the I/O interface <NUM> (shown in dashed lines) provide interfaces to couple the electronic device <NUM> to external input and output devices. Examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and an I/O device <NUM> such as a touch-screen coupled to the I/O interface <NUM>. Other devices may be coupled to the electronic device <NUM>, and additional or fewer interfaces may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device. Those skilled in the art will appreciate that in embodiments in which ED <NUM> is part of a data center, I/O interface <NUM> and Video Adapter <NUM> may be virtualized and provided through network interface <NUM>.

In some embodiments, electronic device <NUM> may be a standalone device, while in other embodiments electronic device <NUM> may be resident within a data center. A data center, as will be understood in the art, is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, a plurality of servers can be connected together to provide a computing resource pool upon which virtualized entities can be instantiated. Data centers can be interconnected with each other to form networks consisting of pools computing and storage resources connected to each by connectivity resources. The connectivity resources may take the form of physical connections such as Ethernet or optical communications links, and may include wireless communication channels as well. If two different data centers are connected by a plurality of different communication channels, the links can be combined together using any of a number of techniques including the formation of link aggregation groups (LAGs). It should be understood that any or all of the computing, storage and connectivity resources (along with other resources within the network) can be divided between different sub-networks, in some cases in the form of a resource slice. If the resources across a number of connected data centers or other collection of nodes are sliced, different network slices can be created.

<FIG> is a block diagram schematically illustrating an architecture of a representative server <NUM> usable in embodiments of the present invention. It is contemplated that the server <NUM> may be physically implemented as one or more computers, storage devices and routers (any or all of which may be constructed in accordance with the system <NUM> described above with reference to <FIG>) interconnected together to form a local network or cluster, and executing suitable software to perform its intended functions. Those of ordinary skill will recognize that there are many suitable combinations of hardware and software that may be used for the purposes of the present invention, which are either known in the art or may be developed in the future. For this reason, a figure showing the physical server hardware is not included in this specification. Rather, the block diagram of <FIG> shows a representative functional architecture of a server <NUM>, it being understood that this functional architecture may be implemented using any suitable combination of hardware and software. It will also be understood that server <NUM> may itself be a virtualized entity. Because a virtualized entity has the same properties as a physical entity from the perspective of another node, both virtualized and physical computing platforms may serve as the underlying resource upon which virtualized functions are instantiated.

As may be seen in <FIG>, the illustrated server <NUM> generally comprises a hosting infrastructure <NUM> and an application platform <NUM>. The hosting infrastructure <NUM> comprises the physical hardware resources <NUM> (such as, for example, information processing, traffic forwarding and data storage resources) of the server <NUM>, and a virtualization layer <NUM> that presents an abstraction of the hardware resources <NUM> to the Application Platform <NUM>. The details of this abstraction will depend on the requirements of the applications being hosted by the Application layer (described below). Thus, for example, an application that provides traffic forwarding functions may be presented with an abstraction of the hardware resources <NUM> that simplifies the implementation of traffic forwarding policies in one or more routers. Similarly, an application that provides data storage functions may be presented with an abstraction of the hardware resources <NUM> that facilitates the storage and retrieval of data (for example using Lightweight Directory Access Protocol - LDAP). The virtualization layer <NUM> and the application platform <NUM> may be collectively referred to as a Hypervisor.

The application platform <NUM> provides the capabilities for hosting applications and includes a virtualization manager <NUM> and application platform services <NUM>. The virtualization manager <NUM> supports a flexible and efficient multi-tenancy run-time and hosting environment for applications <NUM> by providing Infrastructure as a Service (IaaS) facilities. In operation, the virtualization manager <NUM> may provide a security and resource "sandbox" for each application being hosted by the platform <NUM>. Each "sandbox" may be implemented as a Virtual Machine (VM) <NUM> that may include an appropriate operating system and controlled access to (virtualized) hardware resources <NUM> of the server <NUM>. The application-platform services <NUM> provide a set of middleware application services and infrastructure services to the applications <NUM> hosted on the application platform <NUM>, as will be described in greater detail below.

Applications <NUM> from vendors, service providers, and third-parties may be deployed and executed within a respective Virtual Machine <NUM>. For example, MANagement and Orchestration (MANO) functions and Service Oriented Network Auto-Creation (SONAC) functions (or any of Software Defined Networking (SDN), Software Defined Topology (SDT), Software Defined Protocol (SDP) and Software Defined Resource Allocation (SDRA) controllers that may in some embodiments be incorporated into a SONAC controller) may be implemented by means of one or more applications <NUM> hosted on the application platform <NUM> as described above. Communication between applications <NUM> and services in the server <NUM> may conveniently be designed according to the principles of Service-Oriented Architecture (SOA) known in the art.

Communication services <NUM> may allow applications <NUM> hosted on a single server <NUM> to communicate with the application-platform services <NUM> (through pre-defined Application Programming Interfaces (APIs) for example) and with each other (for example through a service-specific API).

A service registry <NUM> may provide visibility of the services available on the server <NUM>. In addition, the service registry <NUM> may present service availability (e.g. status of the service) together with the related interfaces and versions. This may be used by applications <NUM> to discover and locate the end-points for the services they require, and to publish their own service end-point for other applications to use.

Mobile-edge Computing allows cloud application services to be hosted alongside virtualized mobile network elements in data centers that are used for supporting the processing requirements of the Cloud-Radio Access Network (C-RAN). For example, eNodeB or gNB nodes may be virtualized as applications <NUM> executing in a VM <NUM>. Network Information Services (NIS) <NUM> may provide applications <NUM> with low-level network information. For example, the information provided by NIS <NUM> may be used by an application <NUM> to calculate and present high-level and meaningful data such as: cell-ID, location of the subscriber, cell load and throughput guidance.

A Traffic Off-Load Function (TOF) service <NUM> may prioritize traffic, and route selected, policy-based, user-data streams to and from applications <NUM>. The TOF service <NUM> may be supplied to applications <NUM> in various ways, including: A Pass-through mode where (either or both of uplink and downlink) traffic is passed to an application <NUM> which can monitor, modify or shape it and then send it back to the original Packet Data Network (PDN) connection (e.g. 3GPP bearer); and an End-point mode where the traffic is terminated by the application <NUM> which acts as a server.

As may be appreciated, the server architecture of <FIG> is an example of Platform Virtualization, in which each Virtual Machine <NUM> emulates a physical computer with its own operating system, and (virtualized) hardware resources of its host system. Software applications <NUM> executed on a virtual machine <NUM> are separated from the underlying hardware resources <NUM> (for example by the virtualization layer <NUM> and Application Platform <NUM>). In general terms, a Virtual Machine <NUM> is instantiated as a client of a hypervisor (such as the virtualization layer <NUM> and application-platform <NUM>) which presents an abstraction of the hardware resources <NUM> to the Virtual Machine <NUM>.

Other virtualization technologies are known or may be developed in the future that may use a different functional architecture of the server <NUM>. For example, Operating-System-Level virtualization is a virtualization technology in which the kernel of an operating system allows the existence of multiple isolated user-space instances, instead of just one. Such instances, which are sometimes called containers, virtualization engines (VEs) or jails (such as a "FreeBSD jail" or "chroot jail"), may emulate physical computers from the point of view of applications running in them. However, unlike virtual machines, each user space instance may directly access the hardware resources <NUM> of the host system, using the host systems kernel. In this arrangement, at least the virtualization layer <NUM> of <FIG> would not be needed by a user space instance. More broadly, it will be recognised that the functional architecture of a server <NUM> may vary depending on the choice of virtualisation technology and possibly different vendors of a specific virtualisation technology.

<FIG> is a block diagram schematically illustrating an architecture of a representative network <NUM> usable in embodiments of the present invention. In some embodiments, the network <NUM> may be physically implemented as one or more computers, storage devices and routers (any or all of which may be constructed in accordance with the system <NUM> described above with reference to <FIG>) interconnected together to form a Wide Area Network, and executing suitable software to perform its intended functions. In other embodiments, some or all of the elements of the network <NUM> may be virtualized entities executing in a server environment such as described above with reference to <FIG>. For this reason, a figure showing the physical network hardware is not included in this specification. Rather, the block diagram of <FIG> shows a representative functional architecture of a network <NUM>, it being understood that this functional architecture may be implemented using any suitable combination of hardware and software.

In the example of <FIG>, the network <NUM> comprises a pair of access points 302A, 302B connected to a core network <NUM> which is configured to provide communications and connectivity services to electronic devices <NUM> connected to the access points 302A, 302B via links <NUM>. In some embodiments, the links <NUM> may include wireless links between the ED <NUM> and an antenna <NUM> (not shown in <FIG>) connected to network interfaces <NUM> of the AP <NUM>. In embodiments deployed in a Centralized Radio Access network (CRAN) environment, the links <NUM> may encompass both wireless links and fronthaul connections to the access point <NUM>. In the <NUM> or <NUM> networking environments, the access points 302A, 302B may be provided as eNodeB or gNB nodes, and the core network <NUM> may be an Evolved Packet Core (EPC) network providing network functions such as a Serving Gateway (SGW) <NUM>, Service Provider Server (SPS) <NUM>, a Home Subscriber Server (HSS) <NUM>, a Policy and Charging Control (PCC) function <NUM>, an Access and Mobility Management Function (AMF) <NUM> or its predecessor Mobility Management Entity (MME), a Network Exposure Function (NEF) <NUM> and a PDN Gateway (PGW) <NUM>. In some embodiments, the PDN Gateway <NUM> may be configured to provide connectivity to a data network <NUM> (such as the Internet, for example). It will be appreciated that in typical <NUM> or <NUM> networking environment, there may be more than one each of the SGW <NUM>, SPS <NUM>, HSS <NUM>, PCC <NUM>, AMF/MME <NUM>, NEF <NUM> and PGW <NUM>. User-Plane packets to and from the ED <NUM> may be transported through a first GPRS Tunnel Protocol (GTP) tunnel (GTP-<NUM>) <NUM> extending between an Access Point <NUM> serving the ED <NUM> and the SGW <NUM>, and a second GTP tunnel (GTP-<NUM>) <NUM> extending between the SGW <NUM> and the PGW <NUM>. In some embodiments, a respective tunnel <NUM> extending between an Access Point <NUM> and the SGW <NUM> is established for each link <NUM> between the AP <NUM> and EDs <NUM> located within the coverage area of the AP. Similarly, in some embodiments a respective tunnel <NUM> extending between the SGW <NUM> and the PGW <NUM> is established for each tunnel <NUM> between the AP <NUM> and the SGW <NUM>. In other embodiments a tunnel <NUM> extending between the SGW <NUM> and the PGW <NUM> may be used to convey traffic associated with two or more tunnels <NUM> between the SGW <NUM> and one or more APs <NUM>.

Tunnels GTP-<NUM><NUM> and GTP-<NUM><NUM> are point-to-point tunnels, and are identified by respective Tunnel Endpoint Identifiers (TEIDs), User Data Plane (UDP) Port Numbers and IP addresses associated with the nodes serving as the tunnel endpoints. For example, <FIG> illustrates, in greater detail, tunnel GTP-<NUM><NUM> which extends between AP(A) 302A and SGW <NUM>. As may be seen in <FIG>, GTP-<NUM><NUM> comprises a pair of unidirectional tunnels GTP-<NUM>(DL) 324A and GTP-<NUM>(UL) 324B. GTP-<NUM>(DL) 324A is used to convey Downlink packets from SGW <NUM> to AP(A) 302A. Conversely, GTP-<NUM>(UL) 324B is used to convey Uplink packets from AP(A) 302A to SGW <NUM>.

Each of the two endpoint nodes of GTP-<NUM><NUM> has a respective IP address, which may be used for routing Uplink and Downlink packet traffic through the UL and DL tunnels. During establishment of GTP-<NUM><NUM>, AP(A) 302A may allocate a respective Tunnel Endpoint Identifier (= TEID1) and a UDP Port Number (=Port1) to the UL and DL tunnels, while SGW <NUM> may allocate a respective Tunnel Endpoint Identifier (= TEID2) and a UDP Port Number (=Port2) to the tunnels. In some embodiments, a predetermined UDP port number (such as "<NUM>") may be used for GTP tunnels established within a network or network domain. In such cases, both Port1 and Port <NUM> will correspond with the predetermined UDP port number, and so will have the same value. In other embodiments, a respective port number for each endpoint node may chosen during tunnel establishment. In such a case, each endpoint node may use the same or a different port number, which may or may not be "<NUM>". Typically, at least the TEIDs will be shared between the two endpoint nodes during tunnel establishment, so that each node can identify and properly handle packets received through the tunnel. For example, a DownLink (DL) packet destined for ED <NUM> may be sent by SGW <NUM> to the AP(A) 302A through the tunnel GTP-<NUM>(DL) 324A, encapsulated with a tunnel header 328A that includes: the IP address of the SGW <NUM> as the source address (SA); the UDP port number used by the SGW <NUM> as the source port (SP); the IP address of the AP(A) 302A as the destination address (DA); the port number used by the AP(A) 302A as the destination port (DP), and the TEID (=TEID2) assigned to the tunnel by the SGW <NUM> during tunnel establishment. Upon receipt of the DL packet, the AP(A) 302A can read the Source Port Number and Source Address from the header 328A to verify that the DL packet was sent from the SGW <NUM>, and compare the TEID field of the header 328A to the information previously provided to it by the SGW <NUM> during tunnel establishment to verify that the TEID of the packet was issued by the SGW <NUM>. Based on these steps, the AP(A) 302A can verify whether or not the received DL packet was indeed sent through the tunnel GTP-<NUM> by the SGW <NUM>. The AP(A) may also use the TEID (=TEID2) of the tunnel header 328A to identify the link <NUM> through which the DL packet should be forwarded to the ED <NUM>.

Similarly, an UpLink UL) packet destined for Data Network <NUM> may be sent by AP(A) 302A to the SGW <NUM> through the tunnel GTP-<NUM>(UL) 324B, encapsulated with a tunnel header 328B that includes: the IP address of the AP(A) 302A as the source address (SA); the UDP port number used by the AP(A) 302A as the source port (SP); the IP address of the SGW <NUM> as the destination address (DA); the port number used by the SGW <NUM> as the destination port (DP), and the TEID (=TEID1) assigned by the AP(A) 302A during tunnel establishment. Upon receipt of the UL packet, the SGW <NUM> can read the Source Port Number and Source Address from the header to verify that the UL packet was sent from the AP(A) 302A, and compare the TEID field of the header to the information previously provided to it by the AP(A) 302A during tunnel establishment to verify that the TEID of the packet was issued by the AP(A) 302A. Based on these steps, the SGW <NUM> can verify whether or not the received UL packet was indeed sent through the tunnel GTP-<NUM> by the AP(A) 302A. The SGW <NUM> may also use the TEID (= TEID1) of the tunnel header 328B to identify the tunnel GTP-<NUM><NUM> through which the UL packet should be forwarded to the PGW <NUM>.

In accordance with aspects of the present invention, tunnel information pertaining to a tunnel <NUM> extending between an Access Point <NUM> and the SGW <NUM> is exposed to other entities in the network.

In accordance with a first alternative of the invention, each node (eg. an AP <NUM> or an SGW <NUM>) maintains its own listing of tunnel information, which pertains only to those tunnels for which the involved node operates as an endpoint. In such cases, the node permits other nodes to access to its listing of tunnel information. For example, the node may offer a tunnel information update service to which other nodes may subscribe. In another example, the node may respond to requests for information from other nodes. The node exposes some or all of its tunnel information listing to other nodes of the network <NUM> will be (or will become) apparent to those of ordinary skill in the art.

<FIG> illustrate a second alternative of the invention in which a central repository <NUM> of tunnel information is maintained by any suitable network management function, for example, and is accessed by other nodes in the network. In the example, of <FIG>, the central repository <NUM> stores tunnel information comprising, for each tunnel <NUM>: a device identifier <NUM>; a destination address <NUM>; a destination port <NUM> and a source TEID <NUM>. The device identifier <NUM> may identify an endpoint of an end-to-end traffic flow associated with the tunnel. For example, GTP-<NUM>(DL) 324A is associated with Downlink traffic flows to the ED <NUM>, which is an endpoint of an end-to-end traffic flow between the ED <NUM> and an application server (not shown) accessible through the Data Network <NUM>. Accordingly, the device identifier <NUM> may contain an identifier (such as, for example, an IP address) of the ED <NUM>. The destination address <NUM>, destination port <NUM> and the source TEID <NUM> comprise data that is inserted into packets being sent through the tunnel. For example, as described above with reference to <FIG>, DL packets destined for the ED <NUM> are encapsulated by the SGW <NUM> with a header 328A that includes a destination address and destination port of the AP(A) 302A, and a TEID assigned by the SGW <NUM>. Accordingly, these values are provided to the central repository <NUM> (for example by either the AP(A) 302A or the SGW <NUM>) and exposed to other entities in the network <NUM>.

<FIG> is a message flow diagram illustrating example session establishment <NUM> and Hand-Over <NUM> procedures of a type that may be implemented in the network <NUM> of <FIG>. <FIG> illustrates a state of the network <NUM> after completion of the Hand-Over procedure <NUM>.

Referring to <FIG> and <FIG>, session establishment <NUM> typically begins with a service request <NUM> that is sent from the mobile electronic device (ED) <NUM> to an initial Access Point 302A. Upon receipt of the service request <NUM>, the Access Point 302A may forward a corresponding service request (at <NUM>) to the AMF/MME <NUM>. Following receipt of the service request, the AMF/MME <NUM> may interact (at <NUM>) with the HSS <NUM> to authenticate the service request and, upon successful authentication, with the SGW <NUM> and PGW <NUM> to establish connections (such as, for example GTP tunnel <NUM>) and associations needed to support the requested service.

Once connections and associations needed to support the requested service have been established, end-to-end traffic flows associated with the service session can begin (at <NUM>). At the same time, the Access Point 302A (or the SWG <NUM>) may forward to the central repository <NUM> (at <NUM>) tunnel information pertaining to the Downlink GTP tunnel (GTP-<NUM>(DL)) 324A established between the initial AP 302A and the SGW <NUM>. As noted above, the tunnel information sent to the Central Repository <NUM> by the SGW <NUM> may include a device identifier <NUM> of the ED <NUM>, a destination Address <NUM> and Destination port <NUM> of the initial AP 302A, and the source TEID <NUM> allocated by the SGW <NUM>.

Optionally, the initial AP 302A (or the SWG <NUM>) may also forward to the central repository <NUM> (at <NUM>) tunnel information pertaining to the Uplink GTP tunnel (GTP-<NUM>(UL)) 324B established between the initial AP 302A and the SGW <NUM>. As noted above, the tunnel information sent to the Central Repository <NUM> by the initial AP 302A may include a device identifier <NUM> of an Application Server accessible through the Data network <NUM>, a destination Address <NUM> and Destination port <NUM> of the SGW <NUM>, and the source TEID <NUM> allocated by the initial AP 302A. In some embodiments, the device identifier field <NUM> of the Uplink tunnel information may be a wildcard value, rather than an address of a particular Application Server. In operation, the use of the wildcard value would mean that all Uplink traffic received by the initial AP 302A (from all EDs <NUM> within its coverage area) is forwarded through the GTP-<NUM><NUM> to the SGW <NUM>.

During the course of the communications session, the ED <NUM> may move from a coverage area of the initial Access Point 302A and enter a coverage area of a new Access Point, such as access point 302B. Referring to <FIG> and <FIG>, the new access point 302B may initiate the Hand-Over procedure <NUM> by sending a Hand-Over request <NUM> to the initial Access Point 302A, which may respond to the Hand-Over request <NUM> by sending a corresponding Hand-Over request <NUM> to the AMF/MME <NUM>. Following receipt of the Hand-Over request <NUM>, the AMF/MME <NUM> may interact with the ED <NUM>, the involved access points 302A and 302B and the SGW <NUM> to trigger establishment (at <NUM>) of new connections with the new access point 302B. These new connections may include new GTP tunnel (GTP-<NUM>) <NUM> between the SGW <NUM> and the new AP 302B. Once the new GTP tunnel GTP-<NUM><NUM> has been set up, the new access point 302B (or the SGW <NUM>) may send (at <NUM>) an update message to the central repository <NUM> to update the tunnel information pertaining to the ED <NUM>. In the example of <FIG>, this updated tunnel information may include the device identifier <NUM> of the ED <NUM>, a destination Address <NUM> and Destination port <NUM> of the new AP 302B, and the source TEID <NUM> allocated by the SGW <NUM>.

Optionally, the new AP 302B (or the SGW <NUM>) may also forward to the central repository <NUM> (at <NUM>) tunnel information pertaining to the corresponding Uplink GTP tunnel (GTP-<NUM>(UL)) between the new AP 302B and the SGW <NUM>. The tunnel information sent to the Central Repository <NUM> by the new AP 302B may include a device identifier <NUM> of an Application Server accessible through the Data network <NUM> (or a Wildcard value), a destination Address <NUM> and Destination port <NUM> of the SGW <NUM>, and the source TEID <NUM> allocated by the new AP 302B.

The AMF/MME <NUM> may further interact with the ED <NUM>, the involved access points 302A and 302B and the SGW <NUM> to reroute traffic (at <NUM>) to the ED <NUM> via the new tunnel GTP-<NUM><NUM> and the new access point 302B. Upon completion of the foregoing steps, end-to-end traffic flows to and from the ED <NUM> can continue (at <NUM>), but in this case are being routed through GTP-<NUM><NUM> and the new access point 302B.

During the Hand-Over procedure <NUM>, there may be a delay between the time at which the link 306A between the ED <NUM> and the initial AP 302A has been released, and the time at which the SGW <NUM> begins redirecting traffic to the ED <NUM> through the new tunnel GTP-<NUM><NUM>. During this interval, DL packets destined for the ED <NUM> may arrive at the initial AP 302A. However, because the link 306A between the ED <NUM> and the initial AP 302A has been released, the initial AP 302A is unable to forward these "late-arriving" DL packets directly to the ED <NUM>. In conventional systems, the initial AP 302A would either discard these DL packets, redirect them back to the SGW <NUM>, or establish a connection (which may include negotiating another GTP tunnel) to the new AP 302B through which the DL packets can be forwarded.

Referring to <FIG>, in accordance with the present invention, when the initial AP 302A receives late-arriving DL packets destined for the ED <NUM> (at <NUM>), the initial AP 302A may access the central repository <NUM> to obtain the (new) tunnel information associated with the ED <NUM>. For example, the initial AP 302A may send a Request message (at <NUM>) with the device identifier of the ED <NUM> to the central repository <NUM>. Following receipt of the look-up request message, the central repository <NUM> may extract the device identifier from the request and use it to locate the tunnel information that pertains to the ED <NUM> (which in this case will relate to GTP-<NUM><NUM> established between the SGW <NUM> and the new AP 302B). The central repository <NUM> may then send a response message (at <NUM>) containing the tunnel information to the initial AP 302A.

Alternatively, the initial AP 302A may subscribe with the central repository <NUM> to receive tunnel information updates pertaining to the ED <NUM>. In some embodiments, the initial AP 302A may subscribe with the central repository <NUM> when it first provides its tunnel information pertaining to the ED to the central repository <NUM> (e.g. at step <NUM>). In other embodiments, the initial AP 302A may subscribe with the central repository <NUM> at some later time, for example following receipt of the Hand-Over request message from the new AP 302B (at step <NUM>). Similarly, the new AP 302B may subscribe with the central repository <NUM> when it first provides its tunnel information pertaining to the ED to the central repository <NUM> (e.g. at step <NUM>), or at some later time.

Following receipt of the response message from the central repository <NUM>, the initial AP 302A may encapsulate the DL packets (at <NUM>) with a tunnel header containing the tunnel information received from the central repository <NUM>. In embodiments in which the initial AP 302A receives tunnel information updates pertaining to the ED <NUM> from the central repository <NUM>, the steps of sending a Request message (at <NUM>) with the device identifier of the ED <NUM> to the central repository <NUM> and receiving (at <NUM>) a response message from the central repository <NUM> are omitted, and (after receiving the updated tunnel information from the central repository) the initial AP 302A may proceed directly to encapsulate the DL packets (at <NUM>) with a tunnel header containing the updated tunnel information. The initial AP 302A may then send the encapsulated DL packets (at <NUM>) to the new AP 302B. Since the updated tunnel information obtained by the initial AP 302A from the central repository <NUM> already contains the address of the new AP 302B as the destination address, it is not necessary to establish a temporary tunnel between the initial AP 302A and the new AP 302B to convey late-arriving DL packets to the new AP 302B.

The encapsulated DL packets sent to the new AP 302B by the initial AP 302A (at <NUM>) will contain at least the destination address and port and source TEID associated with the new tunnel GTP-<NUM><NUM>, and so are effectively indistinguishable from encapsulated DL packets sent through the tunnel GTP-<NUM><NUM> to the new AP 302B by the SGW <NUM>. Accordingly, when the new AP 302B receives the encapsulated DL packets from the initial AP 302A, the new AP 302B can read the tunnel header (at <NUM>), and compare the tunnel header information from the received packets to its own information pertaining to GTP-<NUM><NUM>. Based on this comparison, the new AP 302B will determine that the received encapsulated DL packets match those sent by the SGW <NUM>, and so proceed to process the DL packets in a corresponding manner. Thus the new AP 302B will forward (at <NUM>) the DL packets to the ED <NUM> through its link 306B.

It is important to note that the tunnel GTP-<NUM><NUM> may have been established (following conventional techniques) as a "one-to-one" tunnel between the SGW <NUM> and the new AP 302B. However, the present invention enables GTP-<NUM><NUM> to be used as a "many-to-one" tunnel, in which packets may be forwarded to the new AP 302B from (possibly) many different nodes in the network <NUM>, and will be treated by the AP 302B as if those packets had been sent via GTP-<NUM><NUM> from the SGW <NUM>.

An advantage of the present invention is that, once a GTP tunnel between two endpoint nodes has been established (in a conventional manner, for example), the tunnel information can be used by other nodes in the network to send packets to one of the endpoint nodes, and can be treated by the receiving endpoint node as if those packets had been sent through the tunnel from the other endpoint node. This avoids the need to establish new connections or tunnels to one of the endpoint nodes. For example, in the scenario described above, the initial AP 302A may send the encapsulated DL packets to the new AP 302B, which will treat those packets as if they had been received from the SGW <NUM>. This operation exploits the existing tunnel GTP-<NUM><NUM> between the new AP 302B and the SGW <NUM>, and so avoids the need to establish a new tunnel between the initial AP 302A and the new AP 302B.

Based on the foregoing description, it may be appreciated that the SGW <NUM> is no longer used to route all traffic destined for the ED <NUM>, but rather is used primarily as an endpoint to support the initial establishment of a tunnel (such as GTP-<NUM><NUM>) to the particular AP <NUM> through which the ED <NUM> may be reached. Once the tunnel has been established and its associated tunnel information exposed to the network (e.g. via the central repository <NUM>) other nodes may send packets to the ED using the tunnel information, without further involvement of the SGW <NUM>. In such cases, the SGW <NUM> may be replaced by a router in the network, and the administration services conventionally performed by a Serving Gateway (SGW) relocated to other nodes in the network (such as the AP <NUM> hosting the ED <NUM>). By this means, the present invention provides a migration path towards a so-called "anchorless" network, in which traffic may be routed through the Core Network <NUM> between the Data Network <NUM> and an AP <NUM> hosting a particular ED <NUM>, without the involvement of an anchor node to maintain continuity of device administration as the ED <NUM> moves from the coverage area of one AP <NUM> to the coverage area of another AP.

In the embodiments of <FIG>, the initial and new access points 302A and 302B are connected to a common Serving Gateway SGW <NUM> via respective GTP tunnels GTP-<NUM><NUM> and GTP-<NUM><NUM>. <FIG> illustrates an embodiment in which the initial and new access points 302A and 302B are connected to respective different Serving Gateways SGW1 308A and SGW2 308B. As may be seen in <FIG>, DownLink packets destined for the ED <NUM> that arrive at the initial Serving Gateway SGW1 308A after the initial tunnel GTP-<NUM><NUM> has been released can be forwarded to the ED <NUM> using a method that is directly analogous to that described above with reference to <FIG>.

Referring to <FIG>, when the initial Serving Gateway SGW1 308A receives DL packets destined for the ED <NUM> (at <NUM>), SGW1 308A may access the central repository <NUM> to obtain the (new) tunnel information associated with the ED <NUM>. For example, the SGW1 308A may send a Request message (at <NUM>) with the device identifier of ED <NUM> to the central repository <NUM>. Following receipt of the look-up request message, the central repository <NUM> may extract the device identifier from the request and use it to locate the tunnel information that pertains to the ED <NUM> (which in this case will relate to the new tunnel GTP-<NUM><NUM>). The central repository <NUM> may then send a response message (at <NUM>) containing the tunnel information pertaining to GTP-<NUM><NUM> to SGW1 308A.

Alternatively, the initial SGW1 308A may subscribe with the central repository <NUM> to receive tunnel information updates pertaining to the ED <NUM>. In some embodiments, the initial SGW1 308A may subscribe with the central repository <NUM> when the initial tunnel GTP tunnels GTP-<NUM><NUM> is established (e.g. at step <NUM>). In other embodiments, the initial SGW1 308A may subscribe with the central repository <NUM> at some later time, for example during the re-routing of traffic flows (at step <NUM>). Similarly, the new SGW2 308B may subscribe with the central repository <NUM> during establishment of new connections (e.g. at step <NUM>), or at some later time.

Following receipt of the response message from the central repository <NUM>, SGW1 308A may encapsulate the DL packets (at <NUM>) with a tunnel header containing the tunnel information received from the central repository <NUM>. In embodiments in which the initial SGW1 308A receives tunnel information updates pertaining to the ED <NUM> from the central repository <NUM>, the steps of sending a Request message (at <NUM>) with the device identifier of the ED <NUM> to the central repository <NUM> and receiving (at <NUM>) a response message from the central repository <NUM> are omitted, and the initial SGW1 308A may (after receiving the updated tunnel information from the central repository) proceed directly to encapsulate the DL packets (at <NUM>) with a tunnel header containing the updated tunnel information. The SGW1 308A may then send the encapsulated DL packets (at <NUM>) to the new AP 302B. Since the updated tunnel information obtained by the initial SGW1 308A from the central repository <NUM> already contains the address of the new AP 302B as the destination address, it is not necessary for the initial SGW1 308A to send the encapsulated DL packets (at <NUM>) to the new AP 302B via either the new SGW2 308B or the PGW <NUM>.

The encapsulated DL packets sent to the new AP 302B by the initial Serving Gateway SGW1 308A (at <NUM>) are effectively indistinguishable from encapsulated DL packets sent to the new AP 302B by the new Serving Gateway SGW2 308B. Accordingly, when the new AP 302B receives the encapsulated DL packets from SGW1 308A, the new AP 302B can read the tunnel header (at <NUM>), and compare the tunnel header information in the received packets to its own information pertaining to the tunnel GTP-<NUM><NUM>. Based on this comparison, the new AP 302B will determine that the received encapsulated DL packets match those sent by the SGW2 308B, and proceed to process the DL packets in a corresponding manner. Consequently, the new AP 302B will forward (at <NUM>) the DL packets to the ED <NUM> through its link 306B.

The description above focusses on DownLink traffic destined for an ED <NUM>. However, it will be appreciated that directly analogous methods may be implemented for UpLink traffic destined for an Application Server in the Data Network <NUM>, for example. For example, <FIG> shows an embodiment in which tunnel information pertaining to the uni-directional tunnel GTP-<NUM>(UL) 326A is exposed via an entry in the central repository <NUM>. In the example of <FIG>, the Device ID <NUM> for this entry is a Wildcard value (=[*]), meaning that all UpLink packets destined for an address accessible through the PGW <NUM> may be forwarded to the PGW <NUM> using that tunnel information. In this case, when an SGW <NUM> receives a UL packet destined for an address accessible through the PGW <NUM>, it may forward that packet to the PGW <NUM> via an already established tunnel, or, alternatively, it may use the tunnel information obtained from the central repository <NUM> to forward the packet (encapsulated with a suitable tunnel header) to the PGW <NUM>, which will treat the packet as if it had been transmitted through the tunnel GTP-<NUM>(UL) 326A from SGW-<NUM>308A. Furthermore, when an AP <NUM> receives a UL packet destined for an address accessible through the PGW <NUM>, it may forward that packet to the PGW <NUM> via an SGW as described above, or, alternatively, it may use the tunnel information obtained from the central repository <NUM> to forward the packet (encapsulated with a suitable tunnel header) to the PGW <NUM> directly, and so bypassing any SGWs in the network <NUM>.

In such cases, the SGW <NUM> and PGW <NUM> serve primarily to provide end-points for establishing of tunnels that enable traffic forwarding from (potentially) many different nodes in the network <NUM>, and so may be replaced by suitable routers. The administration services conventionally performed by a Serving Gateway (SGW) and the PDN) Gateway (PGW) can be relocated to other nodes in the network (such as the AP <NUM> hosting the ED <NUM>), which provides a migration path towards a so-called "anchorless" network, as discussed above.

As noted above, <FIG> illustrates an example Hand-Over process <NUM> that may be executed in response to the ED <NUM> moving from the coverage area of the initial AP(A) 302A and into the coverage area of a new AP(B) 302B. Following receipt of the Hand-Over request, the AMF/MME <NUM> may interact with the ED <NUM>, the involved access points 302A and 302B and the SGW <NUM> to trigger establishment (at <NUM>) of new connections with the new access point 302B. These new connections may include new GTP tunnel (GTP-<NUM>) <NUM> between the SGW <NUM> and the new AP 302B. Once the new GTP tunnel GTP-<NUM><NUM> has been set up, either or both of the SGW <NUM> and the new Access Point 302B may send (at <NUM>) tunnel information pertaining to GTP-<NUM><NUM> to the central repository <NUM>. The AMF/MME <NUM> may further interact with the ED <NUM>, the involved access points 302A and 302B and the SGW <NUM> to reroute traffic (at <NUM>) to the ED <NUM> via the new tunnel GTP-<NUM><NUM> and the new access point 302B.

In some embodiments, rerouting traffic to the ED <NUM> via the new tunnel GTP-<NUM><NUM> and the new access point AP(B) 302B, may require installing context information associated with the ED <NUM> in the new access point AP(B) 302B. Such context information may, for example, include device administration information for traffic monitoring and statistics, policy enforcement, and billing. If desired, the context information may be sent to the new access point AP(B) 302B by either the initial AP(A) <NUM>(A) or SGW <NUM> via the new GTP tunnel GTP-<NUM><NUM>, by encapsulating the context information with a tunnel header <NUM> containing the tunnel information pertaining to GTP-<NUM><NUM> obtained from the central repository <NUM>, as described above with reference to <FIG> and <FIG>.

<FIG> illustrates an embodiment in which the ED <NUM> is connected to the network via two links 306A and 306B, each of which terminates on a respective different access point AP(A) 302A and AP(B) 302B. In the illustrated embodiment, each access point AP(A) 302A and AP(B) 302B is connected to a respective different serving gateway SGW1 308A and SGW2 308B. In other embodiments, the access points AP(A) 302A and AP(B) 302B may be connected to a common serving gateway SGW <NUM>.

In some embodiments, it may be desirable to route all DL packets destined for the ED <NUM> through both of the links 306A and 306B. This requires replication of the DL packets, and the forwarding of each stream of DL packets through a respective one of the two links 306A and 306B. <FIG> is a message flow diagram illustrating an example method of performing this operation in accordance with the present invention.

Referring to <FIG>, in accordance with the present invention, when an access point (such as, for example AP 302A) receives DL packets destined for the ED <NUM> (at <NUM>), the receiving AP(A) 302A may access the central repository <NUM> to obtain the tunnel information associated with the ED <NUM>. For example, AP(A) 302A may send a Request message (at <NUM>) with the device identifier of the ED <NUM> to the central repository <NUM>. Following receipt of the look-up request message, the central repository <NUM> may extract the device identifier from the request and use it to locate the tunnel information that pertains to the ED <NUM> (which in this case will relate to GTP-<NUM><NUM> and GTP-<NUM><NUM>). The central repository <NUM> may then send a response message (at <NUM>) containing the tunnel information to the initial AP(A) 302A. As described above, in an alternative embodiment, AP(A) 302A may automatically receive updated tunnel information pertaining to the ED <NUM> from the central repository <NUM>, in which case the request message (at <NUM>) and Response message (at <NUM>) would be omitted.

Following receipt of the response message from the central repository <NUM>, AP(A) 302A may recognise that the tunnel information relating to GTP-<NUM><NUM> is associated with itself, and therefore requires no further action. On the other hand, AP(A) 302A may recognise that the tunnel information relating to GTP-<NUM><NUM> is associated with AP(B) 302B. Accordingly, AP(A) 302A may replicate the DL packets (at <NUM>), before sending one copy of the DL packets to the ED <NUM> (at <NUM>) via its local link 306A, and encapsulating the other copy of the DL packets (at <NUM>) with a tunnel header containing the tunnel information associated with GTP-<NUM>. AP(A) 302A may then send the encapsulated DL packets (at <NUM>) to AP(B) 302B.

The encapsulated DL packets sent to AP(B) 302B by the AP(A) 302A (at <NUM>) are effectively indistinguishable from encapsulated DL packets sent to AP(B) 302B by the SGW2 308B. Accordingly, when AP(B) 302B receives the encapsulated DL packets from AP(A) 302A, AP(B) 302B can read the tunnel header (at <NUM>), and compare the tunnel header information from the received packets to its own information pertaining to GTP-<NUM><NUM>. Based on this comparison, AP(B) 302B will determine that the received encapsulated DL packets match those sent by the SGW2 308B, and proceed to process the DL packets in a corresponding manner. Thus AP(B) 302B will forward (at <NUM>) the DL packets to the ED <NUM> through its link 306B.

As may be appreciated, the method described above with reference to <FIG> and <FIG> may also be used to divide a traffic flow between the two links 306A and 306B. For example, rather than replicate all DL packets destined for the ED <NUM>, AP(A) 302A may separate an inbound flow of DL packets, so that some defined proportion of the DL packets are forwarded to the ED <NUM> via Link 306A, while the remaining DL packets are forwarded to the ED <NUM> via Link 306B. Example scenarios may include:.

The embodiments described above with reference to <FIG> and <FIG> implement packet duplication for routing packets to a specific ED <NUM> via a pair of Access Points (302A and 302B). It will be appreciated that the same method may be used to implement packet duplication for other purposes. For example, in a lawful intercept scenario, a law enforcement agency may require packet flows to and from a particular ED <NUM> to be duplicated, and the duplicates sent to a predetermined node in the network. In such a scenario, tunnel information associated with the Law Enforcement node can be forwarded to (and recorded by) the central repository <NUM>, and may include a device identifier <NUM> of the particular ED <NUM>, a destination Address <NUM> and Destination port <NUM> of the Law Enforcement node, and a source TEID <NUM> having either a wildcard value or a value allocated by an endpoint node associated with the Law Enforcement node.

In embodiments in which a node sends a request message (e.g. at <NUM>) to the central repository <NUM> to obtain tunnel information pertaining to the particular ED, the central repository <NUM> will include the tunnel information for the Law Enforcement node in the response message (e.g. at <NUM>). In embodiments in which a node may subscribe with the central repository <NUM> to obtain updated tunnel information pertaining to the particular ED, the tunnel information for the Law Enforcement node will be automatically forwarded to the node. In either case, the node will respond by replicating DL packets destined for the ED (e.g. at <NUM>), encapsulating the replicated packets (e.g. at <NUM>) with a tunnel header containing the tunnel information for the Law Enforcement node, and forwarding the encapsulated packets to the law enforcement node (e.g. at <NUM>). It will be appreciated that directly analogous methods may be used to direct (replicated) Uplink traffic sent from the particular ED to the law enforcement node.

The embodiments described above relate to scenarios in which an ED <NUM> establishes a connection to an initial AP 302A, and subsequently moves to the coverage area of a new AP 302B. <FIG> illustrates an embodiment in which a pair of EDs (e.g. ED(A) 102A and ED(B) 102B) are connected to respective different access points 302A and 302B, and messages are exchanged between the two EDs. As may be seen in <FIG>, packets transmitted by ED(A) 102A can be forwarded to ED(B) 102B using a method that is directly analogous to those described above.

Referring to <FIG>, when AP(A) 302A receives packets from ED(A) 102A (at <NUM>) that are destined for the ED(B) 102B, AP(A) 302A may access the central repository <NUM> to obtain the tunnel information associated with the ED(B) 102B. For example, the AP(A) 302A may send a Request message (at <NUM>) with the device identifier of ED(B) 102B to the central repository <NUM>. Following receipt of the look-up request message, the central repository <NUM> may extract the device identifier from the request and use it to locate the tunnel information that pertains to the ED(B) 102B (which in this case will relate to the tunnel GTP-<NUM><NUM>). The central repository <NUM> may then send a response message (at <NUM>) containing the tunnel information pertaining to GTP-<NUM><NUM> to AP(A) 302A. As may be seen in <FIG>, this tunnel information will include: the Destination Address <NUM> (=AP(B)) and Destination Port <NUM> (=Port5) assigned by the AP(B) 302B, and the TEID <NUM> (=TEID6) assigned by the SGW2 308B during establishment of the tunnel GTP-<NUM><NUM>.

Following receipt of the response message from the central repository <NUM>, AP(A) 302A may encapsulate the packets (at <NUM>) with a tunnel header <NUM> containing the tunnel information received from the central repository <NUM>. The AP(A) 302A may then send the encapsulated packets (at <NUM>) to the AP(B) 302B. Since the tunnel information obtained by the AP(A) 302A from the central repository <NUM> already contains the address of the AP(B) 302B as the destination address, it is not necessary for the AP(A) 302A to send the encapsulated UL packets (at <NUM>) to the AP(B) 302B via either of the Serving Gateways SGW1 308A or SGW2 308B.

The encapsulated packets sent to AP(B) 302B by the AP(A) 302A (at <NUM>) are effectively indistinguishable from encapsulated DL packets sent to the AP(B) 302B by the SGW2 308B. Accordingly, when the AP(B) 302B receives the encapsulated UL packets from AP(A) 302A, the AP(B) 302B can read the tunnel header (at <NUM>), and compare the tunnel header information in the received packets to its own information pertaining to the tunnel GTP-<NUM><NUM>. Based on this comparison, AP(B) 302B will determine that the received encapsulated packets match DL packets sent by the SGW2 308B, and proceed to process the received packets in a corresponding manner. Consequently, AP(B) 302B will forward (at <NUM>) the packets to the ED(B) 102B through its link 306B.

In the foregoing description, embodiments of the invention are described by way of example embodiments that exploit features of GTP tunnels between nodes of the core network <NUM>. One such feature of GTP tunnels is that the receiving node does not positively verify the sending node of received packets. Thus, for example, if a node receives a packet encapsulated with a tunnel header <NUM> that contains the correct Destination address <NUM>, Destination Port number <NUM> and Source TEID <NUM>, then the receiving node will accept the received packet as having been sent through the tunnel, and process the received packet accordingly. Other tunneling protocols have other features, some of which may include more rigorous validation of the source node of received packets. In all cases, however, there will be a combination of header fields and field content values that will cause the receiving node to accept the received packet as having been sent through the tunnel. It is contemplated that the specific tunnel information fields exposed to other nodes in the network (e.g. through the central repository <NUM>) will be varied as needed such that a requesting node can obtain the tunnel information needed to send packets to a receiving node that will accept the received packet as having been sent through the tunnel.

Although the present invention has been described with reference to features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, or combinations that fall within the scope of the claims.

Claim 1:
A method for supporting anchorless backhaul in a mobile network, the mobile network including a first endpoint node configured to receive packets through a point-to-point tunnel from a second endpoint node, the method comprising:
exposing, by the first endpoint node or a central repository of the mobile network, tunnel information identifying the point-to-point tunnel between the first endpoint node and the second endpoint node, such that at least one other node of the mobile network can access the exposed tunnel information; and
providing, by the first endpoint node or the central repository, the exposed tunnel information to a third node of the at least one other node, wherein the exposed tunnel information is used by the third node to encapsulate a packet with a tunnel header, such that the first endpoint node will accept the encapsulated packet as having been sent by the second endpoint node through the point-to-point tunnel,
wherein the tunnel information identifying the point-to-point tunnel comprises:
an address of the first endpoint node;
a port number of the point-to-point tunnel at the first endpoint node; and
a Tunnel Endpoint Identifier, TEID, of the point-to-point tunnel assigned by the second endpoint node.