WO2024088594A1

WO2024088594A1 - Integrating a long-range wide area network with a wireless communication network

Info

Publication number: WO2024088594A1
Application number: PCT/EP2023/062691
Authority: WO
Inventors: Apostolis Salkintzis
Original assignee: Lenovo (Singapore) Pte. Ltd
Priority date: 2023-03-31
Filing date: 2023-05-11
Publication date: 2024-05-02

Abstract

There is provided a method in a first network node in a wireless communication network, the method comprising: creating context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receiving a first packet from a first LoRaWAN gateway; selecting a first LNS from the first set of LoRaWAN network servers using the context information; and forwarding the first packet to the first LNS.

Description

INTEGRATING A LONG-RANGE WIDE AREA NETWORK

WITH A WIRELESS COMMUNICATION NETWORK

Field

[0001] The subject matter disclosed herein relates generally to the field of integrating a long-range wide area network with a wireless communication network. This document defines a first network node, a method in a first network node, an application function, and a method in an application function.

Introduction

[0002] The Internet of Things (loT) has been growing at a rapid pace, with billions of devices now connected to the Internet. One of the biggest challenges of loT is to connect devices that are located in remote or difficult-to-reach areas. LoRaWAN has been created to address this challenge. LoRaWAN, which stands for “Long Range Wide Area Network”, is a wireless communication technology designed to support low-power, long-range communication for Internet of Things (loT) devices. It is a protocol that operates on unlicensed radio frequencies and provides a wide range of benefits for loT applications, including low power consumption, long-range communication, and reliable connectivity.

[0003] One of the primary strengths of LoRaWAN is its long-range capabilities. This technology allows loT devices to communicate with one another over distances of several miles, making it ideal for applications that require remote monitoring or control. Additionally, LoRaWAN devices are low power, which means they can operate for extended periods without batteries needing to be recharged or replaced.

[0004] The use cases for LoRaWAN are numerous and diverse. Some of the most common applications include smart cities, precision agriculture, asset tracking, and environmental monitoring. In smart cities, LoRaWAN can be used to connect sensors and devices throughout the city, allowing for more efficient management of resources such as energy, water, and waste. In agriculture, LoRaWAN can be used to connect sensors to monitor soil moisture, temperature, and other environmental factors to optimize crop yields. Asset tracking is another area where LoRaWAN is seeing increased adoption, where asset tags that communicate using LoRaWAN allow companies to track the location and status of their assets in real-time. Environmental monitoring is also a popular use case for LoRaWAN, with sensors placed in remote locations to monitor air quality, water quality, and other environmental factors.

Summary

[0005] A problem with LoRaWAN using a mobile network for the backhaul is that for the mobile network the operation of LoRaWAN is transparent. The mobile network blindly transports data between the LoRaWAN gateways and the LNSs without knowing that this data carries LoRaWAN traffic. Such an arrangement limits the ability of the mobile network operator to appropriately identify and manage LoRaWAN traffic being carried in the network.

[0006] Disclosed herein are procedures for integrating a long-range wide area network with a wireless communication network. Said procedures may be implemented by a first network node, a method in a first network node, an application function, and a method in an application function.

[0007] Accordingly, there is provided a first network node in a wireless communication network, the first network node comprising a processor and a memory coupled with the processor. The processor is configured to cause the first network node to: create context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receive a first packet from a first LoRaWAN gateway; select a first LNS from the first set of LoRaWAN network servers using the context information; and forward the first packet to the first LNS.

[0008] There is further provided a method in a first network node in a wireless communication network, the method comprising: creating context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receiving a first packet from a first LoRaWAN gateway; selecting a first LNS from the first set of LoRaWAN network servers using the context information; and forwarding the first packet to the first LNS.

[0009] There is further provided an application function in a wireless communication network, the application function comprising a processor and a memory coupled with the processor. The processor is configured to cause the application function to: send a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; and receive a response message from the first network node, the response message containing an identity for the created context information.

[0010] There is further provided a method in an application function in a wireless communication network, the method comprising: sending a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; and receiving a response message from the first network node, the response message containing an identity for the created context information.

[0011] Such arrangements may advantageously allow a mobile network operator to identify and appropriately manage LoRaWAN backhaul traffic being carried in the network. For example, such traffic may be assigned particular Quality-of-Service requirements.

Brief description of the drawings

[0012] In order to describe the manner in which advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to certain apparatus and methods which are illustrated in the appended drawings. Each of these drawings depict only certain aspects of the disclosure and are not therefore to be considered to be limiting of its scope. The drawings may have been simplified for clarity and are not necessarily drawn to scale.

[0013] Methods and apparatus for integrating a long-range wide area network with a wireless communication network will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 depicts an embodiment of a wireless communication system for integrating a long-range wide area network with a wireless communication network;

Figure 2 depicts a user equipment apparatus that may be used for implementing the methods described herein;

Figure 3 depicts further details of the network node that may be used for implementing the methods described herein;

Figure 4 illustrates a conventional LoRaWAN implementation whereby LoRaWAN networks are deployed in areas where mobile connectivity is available; Figure 5 illustrates a new LoRaWAN implementation wherein the mobile network operator provides a shared LoRaWAN radio network;

Figure 6 illustrates schematically how the uplink traffic travels from an end device to a certain LNS, via a LoRaWAN Forwarding Function, and then further to an loT application;

Figure 7 illustrates a procedure for how the LoRaWAN Forwarding Function creates LNS context information;

Figure 8 illustrates a join procedure that enables the join procedure to be executed via the LoRaWAN Forwarding Function;

Figure 9 illustrates a method to support uplink/ downlink data traffic in a LoRaWAN;

Figure 10 illustrates a method in a first network node in a wireless communication network; and

Figure 11 illustrates a method in an application function in a wireless communication network.

Detailed description

[0014] As will be appreciated by one skilled in the art, aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects.

[0015] For example, the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0016] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/ or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code.

[0017] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0018] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

[0019] Reference throughout this specification to an example of a particular method or apparatus, or similar language, means that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein. Thus, reference to features of an example of a particular method or apparatus, or similar language, may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise. The terms “including”, “comprising”, “having”, and variations thereof, mean “including but not limited to”, unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an”, and “the” also refer to “one or more”, unless expressly specified otherwise.

[0020] As used herein, a list with a conjunction of “and/ or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/ or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of’ includes one, and only one, of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

[0021] Furthermore, the described features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

[0022] Aspects of the disclosed method and apparatus are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0023] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/ act specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0024] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagram.

[0025] The schematic flowchart diagrams and/ or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowchart diagrams and/ or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). [0026] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0027] The description of elements in each figure may refer to elements of proceeding Figures. Like numbers refer to like elements in all Figures.

[0028] Figure 1 depicts an embodiment of a wireless communication system 100 for integrating a long-range wide area network with a wireless communication network. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Even though a specific number of remote units 102 and network units 104 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP User Equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit. [0029] In one embodiment, the remote units 102 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle onboard computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In certain embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication.

[0030] The network units 104 may be distributed over a geographic region. In certain embodiments, a network unit 104 may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network, an aerial server, a radio access node, an AP, NR, a network entity, an Access and Mobility Management Function (“AMF”), a Unified Data Management Function (“UDM”), a Unified Data Repository (“UDR”), a UDM/UDR, a Policy Control Function (“PCF”), a Radio Access Network (“RAN”), an Network Slice Selection Function (“NSSF”), an operations, administration, and management (“OAM”), a session management function (“SMF”), a user plane function (“UPF”), an application function, an authentication server function (“AUSF”), security anchor functionality (“SEAF”), trusted non-3GPP gateway function (“TNGF”), an application function, a service enabler architecture layer (“SEAL”) function, a vertical application enabler server, an edge enabler server, an edge configuration server, a mobile edge computing platform function, a mobile edge computing application, an application data analytics enabler server, a SEAL data delivery server, a middleware entity, a network slice capability management server, or by any other terminology used in the art. The network units 104 are generally part of a radio access network that includes one or more controllers communicab ly coupled to one or more corresponding network units 104. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet and public switched telephone networks, among other networks. These and other elements of radio access and core networks are not illustrated but are well known generally by those having ordinary skill in the art.

[0031] In one implementation, the wireless communication system 100 is compliant with New Radio (NR) protocols standardized in 3GPP, wherein the network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and the remote units 102 transmit on the uplink (UL) using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, Lora AN among other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0032] The network units 104 may serve a number of remote units 102 within a serving area, for example, a cell or a cell sector via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and/ or spatial domain.

[0033] Figure 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein. The user equipment apparatus 200 is used to implement one or more of the solutions described herein. The user equipment apparatus 200 is in accordance with one or more of the user equipment apparatuses described in embodiments herein. The user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0034] The input device 215 and the output device 220 may be combined into a single device, such as a touchscreen. In some implementations, the user equipment apparatus 200 does not include any input device 215 and/ or output device 220. The user equipment apparatus 200 may include one or more of: the processor 205, the memory 210, and the transceiver 225, and may not include the input device 215 and/or the output device 220.

[0035] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units. The transceiver 225 may be operable on unlicensed spectrum. Moreover, the transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 may support at least one network interface 240 and/ or application interface 245. The application interface (s) 245 may support one or more APIs. The network interface (s) 240 may support 3GPP reference points, such as Uu, Nl, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art.

[0036] The processor 205 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225. [0037] The processor 205 may control the user equipment apparatus 200 to implement the user equipment apparatus behaviors described herein. The processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.

[0038] The memory 210 may be a computer readable storage medium. The memory 210 may include volatile computer storage media. For example, the memory 210 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). The memory 210 may include non-volatile computer storage media. For example, the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile and non-volatile computer storage media.

[0039] The memory 210 may store data related to implement a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200. [0040] The input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touch panel.

[0041] The output device 220 may be designed to output visual, audible, and/ or haptic signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smartwatch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0042] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime). The output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215. For example, the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. The output device 220 may be located near the input device 215.

[0043] The transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages.

[0044] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The one or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers 235. Further, the transmitter(s) 230 and the receiver(s) 235 may be any suitable type of transmiters and receivers. The transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmiter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

[0045] The first transmiter/ receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmiter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. The first transmiter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers 225, transmiters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/or software resource, such as for example, the network interface 240.

[0046] One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a single hardware component, such as a multitransceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a multi-chip module. Other components such as the network interface 240 or other hardware components/ circuits may be integrated with any number of transmiters 230 and/ or receivers 235 into a single chip. The transmitters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmiters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.

[0047] Figure 3 depicts further details of the network node 300 that may be used for implementing the methods described herein. The network node 300 may be one implementation of an entity in the wireless communication network, e.g. in one or more of the wireless communication networks described herein. The network node 300 may comprise a first network node, a LoRaWAN Forwarding Function 530, 630, 730, 830, or 930 as described herein. The network node 300 may comprise an application function, an AF 544, 644, 754, or 854 as described herein. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325. [0048] The input device 315 and the output device 320 may be combined into a single device, such as a touchscreen. In some implementations, the network node 300 does not include any input device 315 and/ or output device 320. The network node 300 may include one or more of: the processor 305, the memory 310, and the transceiver 325, and may not include the input device 315 and/ or the output device 320.

[0049] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 may support at least one network interface 340 and/or application interface 345. The application interface(s) 345 may support one or more APIs. The network interface(s) 340 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art.

[0050] The processor 305 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. The processor 305 may execute instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325.

[0051] The memory 310 may be a computer readable storage medium. The memory 310 may include volatile computer storage media. For example, the memory 310 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). The memory 310 may include non-volatile computer storage media. For example, the memory 310 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 may include both volatile and non-volatile computer storage media.

[0052] The memory 310 may store data related to establishing a multipath unicast link and/ or mobile operation. For example, the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described herein. The memory 310 may also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0053] The input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touch panel.

[0054] The output device 320 may be designed to output visual, audible, and/ or haptic signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smartwatch, smart glasses, a heads-up display, or the like. Further, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0055] The output device 320 may include one or more speakers for producing sound. For example, the output device 320 may produce an audible alert or notification (e.g., a beep or chime). The output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315. For example, the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. The output device 320 may be located near the input device 315.

[0056] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 may be used to communicate with network functions in the PLMN and/ or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. Further, the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers.

[0057] The Internet of Things (loT) has been growing at a rapid pace, with billions of devices now connected to the Internet. One of the biggest challenges of loT is to connect devices that are located in remote or difficult-to-reach areas. LoRaWAN has been created to address this challenge. LoRaWAN, which stands for “Long Range Wide Area Network”, is a wireless communication technology designed to support low-power, long-range communication for Internet of Things (loT) devices. It is a protocol that operates on unlicensed radio frequencies and provides a wide range of benefits for loT applications, including low power consumption, long-range communication, and reliable connectivity.

[0058] One of the primary strengths of LoRaWAN is its long-range capabilities. This technology allows loT devices to communicate with one another over distances of several miles, making it ideal for applications that require remote monitoring or control. Additionally, LoRaWAN devices are low power, which means they can operate for extended periods without batteries needing to be recharged or replaced.

[0059] Another benefit of LoRaWAN is its ability to provide reliable connectivity in challenging radio environments. The protocol uses spread-spectrum modulation, which makes it resistant to interference from other wireless signals. This feature enables LoRaWAN devices to maintain their connections even in areas where other wireless technologies may struggle, for example due to interference or physical obstructions. In addition, the signal transmitted from a LoRaWAN device can be received by multiple base stations (aka LoRaWAN gateways), providing multiple copies of the same signal, which makes communication robust and reliable.

[0060] LoRaWAN also offers significant cost savings compared to traditional mobile communication technologies, and even compared to Narrow-Band loT (NB-IoT). Its low-power requirements mean that devices can be powered by small batteries and can operate for years without requiring replacement or maintenance. Additionally, LoRaWAN's long-range capabilities mean that fewer gateways are needed to cover a given area, reducing the overall cost of deployment.

[0061] The use cases for LoRaWAN are numerous and diverse. Some of the most common applications include smart cities, precision agriculture, asset tracking, and environmental monitoring. In smart cities, LoRaWAN can be used to connect sensors and devices throughout the city, allowing for more efficient management of resources such as energy, water, and waste. In agriculture, LoRaWAN can be used to connect sensors to monitor soil moisture, temperature, and other environmental factors to optimize crop yields. Asset tracking is another area where LoRaWAN is seeing increased adoption, where asset tags that communicate using LoRaWAN allow companies to track the location and status of their assets in real-time. Environmental monitoring is also a popular use case for LoRaWAN, with sensors placed in remote locations to monitor air quality, water quality, and other environmental factors. [0062] Figure 4 illustrates a conventional LoRaWAN implementation 400 whereby LoRaWAN networks are deployed in areas where mobile connectivity is available (e.g., where 4G or 5G mobile networks provide coverage). The LoRaWAN networks use mobile connectivity for their backhaul infrastructure, i.e., as away to connect the LoRaWAN gateways with one or more LoRaWAN Network Servers (LNSs). Such mobile connectivity is provided by a wireless communication network.

[0063] The illustrated conventional LoRaWAN implementation 400 comprises four LoRaWAN end devices: LoRaWAN End Device-1, 401, LoRaWAN End Device-2, 402, LoRaWAN End Device-3, 403, and LoRaWAN End Device-4, 404. The implementation 400 further comprises three LoRaWAN Gateways 411, 412 and 413. A 5G network 420 comprises four base stations in the form of gNBs 421, 422, 423, and 424, and a User Plane Function (UPF) 426.

[0064] Two LoRaWAN providers are illustrated: LoRaWAN Provider A 440 comprising a LoRaWAN Network Server A (LNS-A) 442; and LoRaWAN Provider B 450 comprising a LoRaWAN Network Server A (LNS-A) 452. The LoRaWAN providers provide connectivity to a plurality of loT Apps 460, illustrated here are loT App-1, 461, loT App-2, 462 and loT App-3, 463. While a particular number of nodes and network elements are illustrated in this example, it should be noted that these numbers are for illustration purposes only.

[0065] LoRaWAN End Device-1, 401 communicates with a first LoRaWAN Gateway

411. LoRaWAN End Device-2, 402 communicates with a second LoRaWAN Gateway

412. LoRaWAN End Device-3, 403 and LoRaWAN End Device-4, 404 communicate with a third LoRaWAN Gateway 413. Each LoRaWAN Gateway 411, 412 and 413 communicates with a single LoRaWAN Network Server (LNS) via a respective gNB 421, 422 and 423 and via the UPF 426. The UPF 426 provides connectivity with each LNS 442, 452 of the respective LoRaWAN Network Providers 440, 450. The LoRaWAN providers provide connectivity to a plurality of loT Apps 460, illustrated here are loT App-1, 461, loT App-2, 462 and loT App-3, 463.

[0066] In the present example, LoRaWAN End Device-1, 401 and LoRaWAN End Device-2, 402, communicate via the LoRaWAN and 5G Network 520 with LoRaWAN Provider 440 and loT App-1 461; this communication path is illustrated with a dashed line in figure 4. Similarly, LoRaWAN End Device-3, 403 and LoRaWAN End Device-4, 404, communicate via the LoRaWAN and 5G Network 520 with LoRaWAN Provider 450 and each of loT App-2, 462 and loT App-3 463; this communication path is illustrated with a dot-and-dashed line in figure 4.

[0067] For the mobile network (in this case 5G Network 420), the operation of LoRaWAN is transparent. The mobile network blindly transports data between the LoRaWAN gateways (411, 412, and 413) and the LNSs (442, 452) without knowing that this data carries LoRaWAN traffic. Such an arrangement limits the ability of the mobile network operator to appropriately identify and manage LoRaWAN traffic being carried in the network. Given the existence of LoRaWAN networks as a promising low-power, wide-area wireless technology, it would be beneficial if mobile network operators could better manage LoRaWAN network backhaul traffic.

[0068] The Helium network supports methods for sharing a single LoRaWAN gateway across many LoRaWAN network servers. However, the methods applied in the Helium network are based on blockchain technology and are different from the methods defined in the present disclosure.

[0069] Figure 5 illustrates a new LoRaWAN implementation 500 wherein the mobile network operator provides a shared LoRaWAN radio network. In contrast to the implementation 400 shown in Figure 4, wherein each LoRaWAN gateway can communicate only with a single LoRaWAN network server, in the new LoRaWAN implementation 500, each LoRaWAN gateway can communicate with multiple LoRaWAN network servers via a LoRaWAN Forwarding Function. The mobile network operator deploys multiple LoRaWAN gateways, possibly in the same locations where they have already deployed gNBs. All gateways are connected to the LoRaWAN Forwarding Function via the existing backhaul infrastructure of the mobile network. The deployed gateways can be regular LoRaWAN gateways with no additional functionality. [0070] The illustrated modified LoRaWAN implementation 500 comprises four LoRaWAN end devices: LoRaWAN End Device-1, 501, LoRaWAN End Device-2, 502, LoRaWAN End Device-3, 503, and LoRaWAN End Device-4, 504. The implementation 500 further comprises four LoRaWAN Gateways 511, 512, 513 and 514 implemented by the 5G network 520 alongside by or even within base stations that are not illustrated in figure 5. The 5G network 520 comprises a LoRaWAN Forwarding Function 530. The LoRaWAN Forwarding Function 530 may be located inside a UPF or may be an independent function in the 5G Network 520. The LoRaWAN Forwarding Function 530 may comprise a network node 300, a first network node, or a LoRaWAN Forwarding Function 630, 730, 830, or 930 as described herein. The AF 544 may comprise a network node 300, an application function, an AF 644, 754, or 854 as described herein.

[0071] Two LoRaWAN providers are illustrated: LoRaWAN Provider A 540 comprising a LoRaWAN Network Server A (LNS-A) 542 and an Application Function-A 544; and LoRaWAN Provider B 550 comprising a LoRaWAN Network Server A (LNS-A) 552 and an Application Function-B 554. A Network Exposure Function (NEF) 528 serves Application Function-A 544 and Application Function-B 554. The LoRaWAN providers provide connectivity to a plurality of loT Apps 560, illustrated here are loT App-1, 561, loT App-2, 562 and loT App-3, 563. While a particular number of nodes and network elements are illustrated in this example, it should be noted that these numbers are for illustration purposes only.

[0072] LoRaWAN End Device-1, 501 communicates with a first LoRaWAN Gateway

511. LoRaWAN End Device-2, 502 communicates with a second LoRaWAN Gateway

512. LoRaWAN End Device-3, 503 communicates with a third LoRaWAN Gateway

513. LoRaWAN End Device-4, 504 communicates with a fourth LoRaWAN Gateway

514. Each LoRaWAN Gateway 511, 512, 513 and 514 communicates with the LoRaWAN Forwarding Function 530. The LoRaWAN Forwarding Function 530 communicates with each LoRaWAN Network Server (LNS) 542, 552 of the respective LoRaWAN Network Providers 540, 550. The LoRaWAN providers provide connectivity to a plurality of loT Apps 560, illustrated here are loT App-1, 561, loT App-2, 562 and loT App-3, 563.

[0073] In the present example, LoRaWAN End Device-1, 501 and LoRaWAN End Device-3, 503, communicate via the LoRaWAN and 5G Network 520 with LoRaWAN Provider 540 and loT App-1 561. Similarly, LoRaWAN End Device-2, 502 and LoRaWAN End Device-4, 504, communicate via the LoRaWAN and 5G Network 520 with LoRaWAN Provider 550 and each of loT App-2, 562 and loT App-3 563.

[0074] The LoRaWAN Forwarding Function is a key component of the system and is responsible to relay traffic between the gateways (511, 512, 513 and 514) and one or more LNSs (542, 552). In Figure 5 these LNSs are shown external to the mobile network but they could also be deployed inside the mobile network. The LoRaWAN Forwarding Function can be collocated with a User-Plane Function (UPF) in the mobile network or could be deployed as a standalone function outside of the UPF.

[0075] Each LNS (542, 552) is configured to support a plurality of LoRaWAN end devices (501, 502, 503 and 504). For example, the LNS-A 542 may be configured to support the LoRaWAN end device-1 501 and the LoRaWAN end device-3 503, while the LNS-B is configured to support the LoRaWAN end device-2 502 and the LoRaWAN end device-4 504.

[0076] The LoRaWAN Forwarding Function can exchange signaling traffic with the LNSs (542, 552) via the Network Exposure Function (NEF) 528, which is enhanced for supporting this interaction. In particular, the NEF 528 is enhanced to expose additional northbound APIs and additional southbound APIs. Each LNS (542, 552) can interface with the NEF 528 directly or via a special Application Function (AF) (544, 554). The advantage of using an AF (544, 554) is that a regular LNS (542, 552) can be used with no additional functionality. The AF (544, 554) provides a middleware functionality that interacts with the LNS (542, 552) via an API already supported by the LNS (542, 552) and interacts also with the NEF 528 via the new northbound APIs. As an example, the AF-A 544 may retrieve the list of end devices configured in LNS-A 542 and provide this list to LoRaWAN Forwarding Function via NEF 528.

[0077] Each LNS (542, 552) operates as it normally operates in a LoRaWAN network. It supports the LoRaWAN MAC protocol and exchanges MAC commands with the end devices, and relays data traffic between end devices and loT applications (loT Apps).

For example, each LNS (542, 552) forwards all data traffic received from electricity meters (e.g., end devices that measure electrical consumption) to a loT App 560 that collects, analyzes, and monitors the energy consumption. The LNS (542, 552) applies existing techniques for relaying data traffic to loT Apps 560.

[0078] Figure 6 illustrates schematically how the uplink traffic travels from an end device to a certain LNS, via the LoRaWAN Forwarding Function, and then further to an loT application. In a typical LoRaWAN network, each gateway is configured to communicate with a single LNS only. However, in the system 600 presented herein and illustrated in figure 6, a shared LoRaWAN network is provided, wherein each gateway 611, 612, 613 and 614 can communicate with multiple LNSs.

[0079] The illustrated shared LoRaWAN implementation 600 comprises four LoRaWAN end devices: LoRaWAN End Device-1, 601, LoRaWAN End Device-2, 602, LoRaWAN End Device-3, 603, and LoRaWAN End Device-4, 604. The implementation 600 further comprises four LoRaWAN Gateways 611, 612, 613 and 614 implemented by the 5G network 620 alongside by or even within base stations that are not illustrated in figure 6. The 5G network 620 comprises a LoRaWAN Forwarding Function 630. The LoRaWAN Forwarding Function 630 may be located inside a UPF or may be an independent function in the 5G Network 620. The LoRaWAN Forwarding Function 630 may comprise a network node 300, a first network node, or a LoRaWAN Forwarding Function 530, 730, 830, or 930 as described herein. The AF 644 may comprise a network node 300, an application function, an AF 544, 754, or 854 as described herein.

[0080] Two LoRaWAN providers are illustrated: LoRaWAN Provider A 640 comprising a LoRaWAN Network Server A (LNS-A) 642 and an Application Function-A 644; and LoRaWAN Provider B 650 comprising a LoRaWAN Network Server A (LNS-A) 652 and an Application Function-B 654. A Network Exposure Function (NEF) 628 serves Application Function-A 644 and Application Function-B 654. The LoRaWAN providers provide connectivity to a plurality of loT Apps 660, illustrated here are loT App-1, 661, loT App-2, 662 and loT App-3, 663. While a particular number of nodes and network elements are illustrated in this example, it should be noted that these numbers are for illustration purposes only.

[0081] LoRaWAN End Device-1, 601 communicates with a first LoRaWAN Gateway

611. LoRaWAN End Device-2, 602 communicates with a second LoRaWAN Gateway

612. LoRaWAN End Device-3, 603 communicates with a third LoRaWAN Gateway

613. LoRaWAN End Device-4, 604 communicates with a third LoRaWAN Gateway

614. In other scenarios, any of the LoRaWAN End Device 601, 602, 603, 604 may communicate multiple LoRaWAN gateways. Each LoRaWAN Gateway 611, 612, 613 and 614 communicates with the LoRaWAN Forwarding Function 630. The LoRaWAN Forwarding Function 630 communicates with each LoRaWAN Network Server (LNS) 642, 652 of the respective LoRaWAN Network Providers 640, 650. The LoRaWAN providers provide connectivity to a plurality of loT Apps 660, illustrated here are loT App-1, 661, loT App-2, 662 and loT App-3, 663.

[0082] Each gateway 611, 612, 613, and 614 may communicate with many LNSs 642, 652. Each gateway 611, 612, 613, and 614 is configured to send traffic to and receive traffic from the LoRaWAN Forwarding Function 630. When the LoRaWAN Forwarding Function 630 receives an uplink packet from a gateway 611, 612, 613, and 614, it selects an LNS to forward the packet to. Some traffic from the gateway may be sent to LNS-A 642 and some other traffic from the same gateway may be sent to LNS-B 652. In other words, the same gateway is shared by several LNSs.

[0083] Similarly, when the LoRaWAN Forwarding Function 630 receives a downlink packet from an loT app, it selects a gateway to forward this packet to. [0084] Note that, as shown in figure 6, a LoRaWAN gateway 611, 612, 613, and 614 receives, at 671, MAC frames from end devices, and appends, at 672, metadata to each one before it relays it. The Metadata is also added by the LNS to each downlink packet transmitted to a gateway. In the uplink direction, the metadata provided by the gateway includes reception information, such as the time when a MAC frame was received, the frequency via which it was received, the SNR, the Radio Signal Strength Indication (RSSI), the coding rate, the modulation type, etc. In the downlink direction, the metadata provided by the LNS includes transmission information, such as the time when a MAC frame must be transmitted, the frequency and power that should be used for the transmission, the modulation, the coding rate, etc. The LoRaWAN Forwarding Function 630 performs routing, at 673, based on the Metadata and the stored LNS Context. The LoRaWAN Forwarding Function 630 sends, at 674, the packet to the selected LNS, in this case LNS-B 652. The selected LNS forwards the packet via IP/TCP/MQTT to an appropriate loT App 660, in this case loT App-2 662.

[0085] Figure 7 illustrates a procedure 700 for how the LoRaWAN Forwarding Function creates LNS context information. Before the LoRaWAN Forwarding Function can relay traffic between gateways and LNSs, it must create and store information about each LNS, which is referred to as “LNS context”. The LNS context contains information needed to communicate with an LNS (IP address, port, etc.) and the list of end devices supported by each LNS. Note that each end device can communicate only with one LNS and information about the device must be provisioned in the LNS. Such information includes the unique identity of the device (called DevEUI), capabilities of the device (e.g., supported frequency bands, power ranges, etc.) and security information for the device, which is needed for protecting the traffic between the device and the LNS.

[0086] The procedure 700 is performed by a LoRaWAN Forwarding Function 730, a NEF 728, an AF 754 and an LNS 752. The LoRaWAN Forwarding Function 730 may comprise a network node 300, a first network node, or a LoRaWAN Forwarding Function 530, 630, 830, or 930 as described herein. The AF 754 may comprise a network node 300, an application function, an AF 544, 644, or 854 as described herein. [0087] The process 700 begins at 772, and is initiated by the AF 754, which requests and retrieves the list of end devices provisioned in the LNS 752. This is accomplished by using a conventional API supported by the LNS 752. [0088] At 773, the AF 754 sends a Create LNS Context Request message to the NEF 728. All messages between the AF 754 and the NEF 728 are authenticated and encrypted with conventional procedures, which are not discussed in detail herein. The Create LNS Context Request message contains the identities of the end devices supported by the LNS (List of DevEUIs) and contact information for the LNS, such as the identity of the LNS, its IP address, port number, protocol used by LNS, etc.

[0089] At 774, the NEF 728 forwards the Create LNS Context Request message to the LoRaWAN Forwarding Function 730. Note that, if the LNS 752 is deployed inside the mobile network (and considered trusted), it can communicate directly with LoRaWAN Forwarding Function 730, without the need to involve the NEF 728.

[0090] At 775, the LoRaWAN Forwarding Function 730 creates and stores an LNS context for the LNS 752. The LNS context contains the information in the Create LNS Context Request message.

[0091] At 776, the LoRaWAN Forwarding Function 730 sends a Create LNS Context Response message containing an LNS context identity, which can be used later to refer to the created LNS context.

[0092] At 777, the NEF 728 relays the Create LNS Context Response message to AF 754.

[0093] The above procedure 700 is executed for each LNS that can communicate with the shared LoRaWAN network of the mobile network operator. Hence, the LoRaWAN Forwarding Function maintains an LNS context for each such LNS.

[0094] A Join procedure in LoRaWAN is a procedure used to authenticate and register end devices with a LoRaWAN network server (LNS), and also to establish a security context that can protect subsequent traffic between them. Before an end device can exchange data with the LNS, it needs to successfully perform the Join procedure. There are two types of Join procedures in LoRaWAN, and while either could be used, here we consider one of them: the Over-the-Air Activation (OTAA). In this method, the end device sends a Join Request message to the LNS, which responds with a Join Accept message containing a unique set of cryptographic keys that are used to encrypt and decrypt data transmitted between the end device and the LNS.

[0095] Figure 8 illustrates a join procedure 800 that enables the Join procedure to be executed via the LoRaWAN Forwarding Function. The procedure 800 is performed by a LoRaWAN end device 801, a LoRaWAN gateway 811, a LoRaWAN Forwarding Function 830, an LNS 852, an NEF 828 and an AF 854. Novel functionality is provided by LoRaWAN Forwarding Function 830 and by the AF 854. The LoRaWAN Forwarding Function 830 may comprise a network node 300, a first network node, or a LoRaWAN Forwarding Function 530, 630, 730, or 930 as described herein. The AF 854 may comprise a network node 300, an application function, an AF 544, 644, or 754 as described herein. It is assumed that the protocol used between the gateway and the LNS is the “UDP Packet Forwarder” protocol (defined in https://github.com/Lora- net/ packet_forwarder/blob/ master/PROTOCOL.TXT).

[0096] The process 800 begins at 871, with the LoRaWAN end device 801 transmitting a Join Request message to join with the LoRaWAN network server (LNS) 852. The Join Request is contained in a MAC frame (also referred to as PHY Payload), which also contains a MAC Header (MHDR) and a Message Integrity Code (MIC1) value. The MIC1 is created by using a unique key in the LoRaWAN end device 801, which is known also by the LNS 852 in which this device is provisioned. The MHDR may include FType, RFU, Major (0000 0000). The Join -Request may include JoinEUI, DevEUI, DevNonce.

[0097] At 872, the LoRaWAN gateway 811 receives the transmitted MAC frame (PHY Payload) containing the Join Request and forwards it to the LoRaWAN Forwarding Function 830 within a Push_Data packet. This packet contains also a Token created by the LoRaWAN gateway 811 (a pseudo random value), the LoRaWAN gateway’s MAC address and metadata including reception information (such as a timestamp, the received signal strength, SNR, frequency, etc.). This packet may take the form Token XI, Gateway MAC, {"rxpk": <Metadata>, <PHY Payload>] .

[0098] At 873, the LoRaWAN Forwarding Function 830 inspects the received Push_Data, determines that the PHY Payload contains a Join Request message and it obtains the end device’s identity (DevEUI) from the PHY Payload. The LoRaWAN Forwarding Function 830 may obtain DevEUI from the PHY Payload Based on the stored LNS contexts, identify the LNS supporting the end device Forward to the identified LNS, and store the timestampl of the Join Request. Subsequently, it checks all stored LNS contexts and identifies the LNS that supports this end device 801. Recall that the LoRaWAN Forwarding Function 830 has created an LNS context for every available LNS using the method 700 illustrated in Figure 7. This context contains the list of end devices (DevEUIs) supported by each available LNS. The LoRaWAN Forwarding Function 830 forwards the received Push_Data packet to the identified LNS 852 that supports the end device 801. This packet may take the form Token XI, Gateway MAC, {"rxpk": <Metadata>, <PHY Payload>] . In addition, it stores the timestamp (included in metadata) that determines when the Join Request was received by the gateway 811, as determined by the gateway’s internal clock. This timestamp is called timestampl and will be used later (see step 881) when deciding how to route a Join Accept message. Note that the LoRaWAN Forwarding Function 830 does not change the contents of the Push_Data packet; it simply relays it to the identified LNS 852. [0099] At 875, after receiving the Push_Data packet, the LNS 852 responds with a Push_Ack packet, which contains the same Token as the Token in the Push_Data, Token XI in this example. The Token is generally used as a value that correlates a request packet (e.g., a Push_Data) and a response packet (e.g., Push_Ack).

[0100] At 876, the LoRaWAN Forwarding Function 830 receives the Push_Ack packet and identifies a gateway 811 to forward this packet to based on the Token value in the Push_Ack. The LoRaWAN Forwarding Function 830 identifies a gateway 811 by checking which gateway has sent a Push_Data packet containing the same Token value. After identifying the gateway 811, the LoRaWAN Forwarding Function 830 relays the Push_Ack to the identified gateway 811.

[0101] At 878, after the LNS 852 receives the Join Request message (in step 873b), it creates a Join Accept message, which accepts the end device to join with the LNS. The Join Accept message is created only if the LNS is provisioned with information about the end device (such as security information) and after validating the MIC value provided by the end device.

[0102] At 880, the LNS 852 encrypts the Join Accept message and puts it inside another MAC frame (PHY Payload-2) together with another Message Integrity Code value (MIC2) created using the security keys provisioned in the LNS 852 for the end device 801. The LNS 852 sends a Pull_Resp packet to LoRaWAN Forwarding Function 830 that contains the PHY Payload-2 (including the encrypted Join Accept message), a new Token and metadata information that indicates the transmission parameters to be used by the gateway 811, such as a timestamp (called timestamp2) indicating when to transmit the PHY Payload-2, the transmission power, the transmission frequency, etc. For example, the Pull_Resp packet may comprise Token X2, {"txpk": <Metadata>, <PHY Payload-2>] PHY Payload-2: MHDR, enc{Join Accept] , MIC2.

[0103] Note that, although process 800 shows that the LNS 852 receives the Join Request via one gateway 811 only, in another scenario, the LNS 852 may receive the Join Request message via multiple gateways. In this scenario, the steps 871 to 876 are executed multiples times (one for each gateway 811) and the LNS 852 selects one of these gateways for transmitting the Join Accept message, typically, the gateway that has received the Join Request with the strongest signal.

[0104] At 881, when the LoRaWAN Forwarding Function receives the Pull_Resp packet from the LNS, it determines that it contains a Join Accept message. The Pull_Resp packet may comprise Token X2, {"txpk": <Metadata>, <PHY Payload-2>] . However, it is not clear to which gateway this packet should be forwarded to because the Pull_Resp packet does not contain a gateway identity. Also, the Join Accept is encrypted and cannot be parsed by LoRaWAN Forwarding Function. As noted above, if the same Join Request message is sent to LNS via multiple gateways, the LoRaWAN Forwarding Function does not know which gateway is selected by LNS to transmit the Join Accept message.

[0105] To identify the gateway 811 selected by the LNS 852, the LoRaWAN Forwarding Function 830 checks the timestamp in the Pull_Resp message (timestamp2) and compares it with the timestamps (timestampl) of all recently received Join Request messages, which are stored in LoRaWAN Forwarding Function 830, according to step 873. The time difference between the transmission time of the Join Accept (timestamp2) and the reception time of the Join Request from a gateway (stored timestampl) must be an integer value, usually 5sec, according to the LoRaWAN default Join parameters. Via this comparison of timestamp values, the LoRaWAN Forwarding Function 830 identifies the gateway 811 selected by the LNS 852 and forwards the Pull_Resp packet to this gateway 811. Note that after selecting a gateway 811, the LNS 852 calculates timestamp2 with reference to the timestampl provided by the selected gateway 811. That’s why the difference of these timestamps should be an integer value indicating the time difference between the reception of the Join Request and the transmission of the Join Accept.

[0106] At 882, after the gateway 811 receives the Pull_Resp packet, it responds with a TX_Ack packet that contains the same Token as the one in the Pull_Resp and the identity of the gateway (MAC address) 811. The TX_Ack may comprise Token X2, Gateway MAC. The TX_Ack is received by the LoRaWAN Forwarding Function 830 and is forwarded to the LNS 852 from which a Pull_Resp was received with the same Token value.

[0107] At 883, the gateway 811 that received the Pull_Resp packet transmits the MAC frame (PHY Payload-2) embedded in this packet using the provided transmission parameters (in the metadata field). These parameters may comprise MHDR, enc{Join- Accept} , MIC2. This MAC frame includes the Join Accept message, which informs the end device that it is now joined with an LNS. The end device 801 confirms the validity of MIC2, which was created with keying material in the LNS 852 and, therefore, confirms that the LNS 852 is provisioned with the correct keys for the end device 801. The Join-Accept may comprise JoinNonce, NetID, DevAddr, DLSettings, RXDelay, CFList.

[0108] The Join Accept message contains a temporary identity for the end device 801, called DevAddr. This identity will be included by the end device 801 in all subsequent uplink messages and will be used by the LoRaWAN Forwarding Function 830 for routing these messages to the correct LNS 852 (the one which accepted the Join Request). However, since the Join Accept message is encrypted, the LoRaWAN Forwarding Function 830 does not know the DevAddr allocated to the end device 801 by the LNS 852. In order to find out the DevAddr allocated to the end device 801, the following step is executed.

[0109] At 884, after steps 880 to 882 are executed and a Join Accept message has been sent to an end device 801, the LoRaWAN Forwarding Function 830 sends a DevAddr Request message to the AF 854, from which the Create LNS Context Request was received. This message includes the DevEUI of the end device 801 (its permanent identity included in the Join Request) and information about the LNS 852 that accepted the Join Request of the device 801. The intention of this message is to discover the DevAddr that was allocated to the device by the LNS 852.

[0110] After receiving the DevAddr Request message, the AF 854 retrieves from the identified LNS 852 the requested DevAddr (steps 884b, 884c). This is carried out by using an existing API offered by the LNS 852 (typically, a RESTfull API). In turn, the AF 854 forwards the discovered DevAddr to the LoRaWAN Forwarding Function 830, which appends it to the stored LNS context of this LNS 852. For example, the DevAddr may be 002271d8. From now on, the LoRaWAN Forwarding Function 830 knows the temporary address allocated to the end device 801 and can use it to relay data messages between the end device 801 and the LNS 852, as specified in the next clause. So, the LNS context stores not only the permanent identities (DevEUIs) of the end devices served by the LNS, but also the temporary identities (DevAddrs) of these devices.

[0111] Figure 9 illustrates a method 900 to Support Uplink/Downlink Data Traffic in a shared LoRaWAN network using a LoRaWAN Forwarding Function. The method 900 is performed by a LoRaWAN end device 901, a LoRaWAN gateway 911, a LoRaWAN Forwarding Function 930, an LNS 952. The method 900 enables data messages to be exchanged between the end device 901 and the LNS 952, via LoRaWAN Forwarding Function 930, after the execution of the Join procedure. Novel functionality is provided by LoRaWAN Forwarding Function 930. The LoRaWAN Forwarding Function 930 may comprise a network node 300, a first network node, or a LoRaWAN Forwarding Function 530, 630, 730, or 830 as described herein.

[0112] The method 900 begins at step 971, wherein the end device 901 transmits an Unconfirmed or Confirmed Data Uplink message to the LoRaWAN network server (LNS) 952. This message is contained in a MAC frame (also referred to as PHY Payload), which also contains a MAC Header (MHDR) and a Message Integrity Code (MIC1) value. The MIC1 is created by using a session key in the end device, which was created during the Join procedure. The message thus comprises MHDR, MAC -Payload, and MIC1. The MHDR may comprise FType, RFU, Major. The MAC -Payload may comprise FHDR, FPort, FRMPayload. The FHDR may comprise DevAddr, FCtrl, FCnt, FOpts.

[0113] At 972, a gateway 911 receives the transmitted MAC frame (PHY Payload) containing the (Un)Confirmed Data Uplink message and forwards it to the LoRaWAN Forwarding Function 930 within a Push_Data packet. This packet contains also a Token created by the gateway (a pseudo random value), the gateway’s MAC address and metadata including reception information (such as a timestamp, the received signal strength, SNR, frequency, etc.) The Push_Data packet may thus comprise Token XI, Gateway MAC, {“rxpk”: <Metadata>, <PHY Payload>] .

[0114] At 973, the LoRaWAN Forwarding Function 930 inspects the received Push_Data, determines that the PHY Payload contains an (Un)Confirmed Data Uplink message, and it obtains the end device’s temporary identity (DevAddr) from the PHY Payload. The LoRaWAN Forwarding Function 930 may obtain DevEUI from the PHY Payload Based on the stored LNS contexts, identify the LNS supporting the end device Forward to the identified LNS, and store the timestampl of the Join Request.

Subsequently, it checks all stored LNS contexts and identifies the LNS 952 that supports this end device 901. This packet may take the form Token XI, Gateway MAC, {"rxpk": <Metadata>, <PHY Payload>] . Recall that the LoRaWAN Forwarding Function 930 has created an LNS context for every available LNS using the method specified in process 700 discussed above, and in each LNS context stores also the temporary identities of the end devices served by this LNS 952 (as specified in step 884 of the method 800 discussed above). The LoRaWAN Forwarding Function 930 forwards the received Push_Data packet to the identified LNS that serves the end device 901. In addition, it stores the timestamp (included in metadata) that determines when the (Un)Confirmed Data Uplink message was received by the gateway 911, as determined by the gateway’s internal clock. This timestamp is called timestampl and will be used later (see step 981) when deciding how to route a downlink message. Note that the LoRaWAN Forwarding Function 930 does not change the contents of the Push_Data packet; it simply relays it to the identified LNS 952.

[0115] At 975, after receiving the Push_Data packet, the LNS 952 responds with a Push_Ack packet, which contains the same Token as the Token in the Push_Data, Token XI in this example. The Token is generally used as a value that correlates a request packet (e.g., a Push_Data) and a response packet (e.g., Push_Ack).

[0116] At 976, the LoRaWAN Forwarding Function 930 receives the Push_Ack packet and identifies a gateway 911 to forward this packet to, the determination based on the Token value in the Push_Ack. The LoRaWAN Forwarding Function 930 identifies a gateway 911 by checking which gateway has sent a Push_Data packet containing the same Token value. After identifying the gateway 911, the LoRaWAN Forwarding Function 930 relays the Push_Ack to the identified gateway 911.

[0117] At 978, after the LNS 952 receives the (Un)Confirmed Data Uplink message (in step 973b), it may create a (Un)Confirmed Data Downlink message to be sent to the end device 901. This downlink message is created either as a response to the (Un)Confirmed Data Uplink message (e.g., to acknowledge reception of a Confirmed Data Uplink) or it is a downlink message that was received before from an loT App, and it was buffered in the LNS 952 until the end device 901 becomes available for reception. Note that LoRaWAN end devices 901 operating in class A (as assumed here) can receive downlink traffic only after sending uplink traffic. Note also that the LNS 952 accepts and processes the received (Un)Confirmed Data Uplink message after validating the MIC value in this message.

[0118] At 980, the LNS 952 puts the (Un)Confirmed Data Downlink message inside another MAC frame (PHY Payload-2) together with another Message Integrity Code value (MIC2) created using the session keys stored in the LNS for the end device 901, which were generated during the Join procedure. The LNS 952 sends a Pull_Resp packet to LoRaWAN Forwarding Function 930 that contains the PHY Payload-2 (including the (Un)Confirmed Data Downlink message message), a new Token and metadata information that indicates the transmission parameters to be used by the gateway, such as a timestamp (called timestamp 2) indicating when to transmit the PHY Payload-2, the transmission power, the transmission frequency, etc. For example, the Pull_Resp packet may comprise Token X2, {"txpk": <Metadata>, <PHY Payload-2>} PHY Payload-2: MHDR, enc{Join Accept} , MIC2.

[0119] Note that, although process 900 shows that the LNS 952 receives the

(Un) Confirmed Data Uplink message via one gateway only, in another scenario, the LNS 952 may receive the (Un)Confirmed Data Uplink message via multiple gateways. In this scenario, the steps 971 to 976 are executed multiples times (one for each gateway) and the LNS 952 selects one of these gateways for transmitting the (Un)Confirmed Data Downlink message, typically, the gateway that has received the (Un) Confirmed Data Uplink message with the strongest signal.

[0120] At 981, when the LoRaWAN Forwarding Function 930 receives the Pull_Resp packet from the LNS 952, it determines that it contains a (Un)Confirmed Data Downlink message. The Pull_Resp packet may comprise Token X2, {"txpk": <Metadata>, <PHY Payload-2>} . However, it is not clear to which gateway this packet should be forwarded to because the Pull_Resp packet does not contain a gateway identity. As noted above, if the same (Un)Confirmed Data Uplink message is sent to LNS via multiple gateways, the LoRaWAN Forwarding Function 930 does not know which gateway is selected by LNS to transmit the (Un) Confirmed Data Downlink message.

[0121] To identify the gateway selected by the LNS 952, the LoRaWAN Forwarding Function 930 checks the timestamp in the Pull_Resp message (timestamp2) and compares it with the timestamps (timestampl) of all recently received (Un)Confirmed Data Uplink messages, which are stored in LoRaWAN Forwarding Function 930, according to step 973. The time difference between the transmission time of the (Un) Confirmed Data Downlink message (timestamp 2) and the reception time of the (Un)Confirmed Data Uplink message from a gateway (stored timestampl) must be an integer value, usually l-2sec. Via this comparison of timestamp values, the LoRaWAN Forwarding Function 930 identifies the gateway 911 selected by the LNS 952 and forwards the Pull_Resp packet to this gateway 911. Note that after selecting a gateway, the LNS 952 calculates timestamp2 with reference to the timestampl provided by the selected gateway 911. That’s why the difference of these timestamps should be an integer value indicating the time difference between the reception of the (Un) Confirmed Data Uplink message and the transmission of the (Un)Confirmed Data Downlink message.

[0122] At 982, after the gateway 911 receives the Pull_Resp packet, it responds with a TX_Ack packet that contains the same Token as the one in the Pull_Resp and the identity of the gateway (MAC address). The TX_Ack may comprise Token X2, Gateway MAC. The TX_Ack is received by the LoRaWAN Forwarding Function 930 and is forwarded to the LNS from which a Pull_Resp was received with the same Token value. [0123] At 983, the gateway that received the Pull_Resp packet transmits the MAC frame (PHY Payload-2) embedded in this packet using the provided transmission parameters (in the metadata field). These parameters may comprise MHDR, enc{Join-Accept] , MIC2. This MAC frame includes the (Un)Confirmed Data Downlink message. The end device 901 confirms the validity of MIC2, therefore, confirms that the LNS has created the correct session keys for the end device 901. The Join-Accept may comprise JoinNonce, NetID, DevAddr, DLSettings, RXDelay, CFList.

[0124] Accordingly, there is provided a first network node in a wireless communication network, the first network node comprising a processor and a memory coupled with the processor. The processor is configured to cause the first network node to: create context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receive a first packet from a first LoRaWAN gateway; select a first LNS from the first set of LoRaWAN network servers using the context information; and forward the first packet to the first LNS.

[0125] Such an arrangement advantageously allows a mobile network operator to identify and appropriately manage LoRaWAN backhaul traffic being carried in the network. For example, such traffic may be assigned particular Quality-of-Service requirements.

[0126] The first network node may comprise a LoRaWAN Forwarding Function. The context information may comprise an LoRaWAN Network Server (LNS) Context. The first packet may comprise Push_Data. The first LoRaWAN gateway may be shared by several LNSs in the first set. The first packet contains a first timestamp and a first LoRaWAN frame. A LoRaWAN frame may comprise a PHY payload.

[0127] The context information may contain information needed to communicate with an LNS. Such information may comprise IP address, port, etc. Such information may comprise the identity of the LNS. The context information additionally comprises the list of end devices supported by each LNS. As such the context information may include information for defining the LNS, such as IP address, FQDN, etc.

[0128] The processor may be further arranged to: receive a context request message from a function, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; wherein the context information is created using the received first set of parameters associated with an LNS and the list of LoRaWAN end devices served by the LNS; and send a response message to the function, the response message containing an identity for the created context information. The function may comprise either the NEF or an AF.

[0129] The identity for the created context information may be used so that the function can later update the context, e.g., add or remove LoRaWAN end devices from the context.

[0130] The first packet may contain a first token and the processor may be further arranged to: receive a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identify the first LoRaWAN gateway based on the first token; and forward the first acknowledgement to the first LoRaWAN gateway.

[0131] The first packet may contain a first token, and the processor may be further arranged to: receive a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identify the first LoRaWAN gateway as the gateway from which the first packet containing the first token was received; and forward the first acknowledgement to the first LoRaWAN gateway.

[0132] The first packet may contain a timestamp, and the processor may be further arranged to: receive a second packet from the first LNS, the second packet containing a second timestamp and a second LoRaWAN frame; determine, from the first timestamp and the second timestamp, whether the second packet is for the first LoRaWAN gateway; and relay the second packet to the first LoRaWAN gateway if the second packet is for the first LoRaWAN gateway. The first packet contains a LoRaWAN frame and every packet exchanged between a gateway and an LNS (expect the acknowledgements) may contain a LoRaWAN frame. The second packet is determined to be for the first LoRaWAN gateway if the difference between the second timestamp and the first timestamp is an integer value. [0133] The second packet may be triggered by the first packet. The method may comprise identifying the LoRaWAN gateway that sent the first packet by using the second timestamp and the first timestamp. The identifying may comprise determining that the difference in values of the second timestamp and the first timestamp comprises an integer value of seconds. The method may comprise sending the second packet to the identified LoRaWAN gateway.

[0134] Note that several gateways may have sent a first packet that triggered the second packet but only one of these first packets contains a first timestamp that gives an integer result after being subtracted from the second timestamp. In other words: The LNS may receive multiple first packets from different gateways. The LNS selects one of these gateways and then creates the second timestamp (in the second packet) based on the first timestamp of the selected gateway.

[0135] The processor may be further arranged to: receive a second acknowledgement from first LoRaWAN gateway, the second acknowledgement acknowledging the second packet and comprising a second token; and forward the second acknowledgment to the first LNS if the second token matches the first token.

[0136] When an LNS sends an acknowledgment containing a token, the method may comprise forwarding the acknowledgment to a gateway that has sent a request containing the same token. When a gateway sends an acknowledgment containing a token, the method may comprise forwarding the acknowledgment to an LNS that has sent a request containing the same token.

[0137] The processor may be further arranged to: send a device address request message to a function, the device address request message comprising a device identity and information defining the LNS; and receive a response message containing the device address. The device address request message may be sent after the LoRaWAN Forwarding Function identifies that a new LoRaWAN end device has joined an LNS.

[0138] The function may comprise either the NEF or an AF. The context information may store not only the permanent identities (DevEUIs) of the end devices served by the LNS, but also the temporary identities (DevAddrs) of these devices.

[0139] Figure 10 illustrates a method 1000 in a first network node in a wireless communication network, the method 1000 comprising: creating 1010 context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receiving 1020 a first packet from a first LoRaWAN gateway; selecting 1030 a first LNS from the first set of LoRaWAN network servers using the context information; and forwarding 1040 the first packet to the first LNS.

[0140] In certain embodiments, the method 1000 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0141] Such an arrangement advantageously allows a mobile network operator to identify and appropriately manage LoRaWAN backhaul traffic being carried in the network. For example, such traffic may be assigned particular Quality-of-Service requirements.

[0142] The first network node may comprise a LoRaWAN Forwarding Function. The context information may comprise an LoRaWAN Network Server (LNS) Context. The first packet may comprise Push_Data. The first LoRaWAN gateway may be shared by several LNSs in the first set. The first packet contains a first timestamp and a first LoRaWAN frame. A LoRaWAN frame may comprise a PHY payload.

[0143] The method may further comprise: receiving a context request message from a function, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; wherein the context information is created using the received first set of parameters associated with an LNS and the list of LoRaWAN end devices served by the LNS; and sending a response message to the function, the response message containing an identity for the created context information.

[0144] The function may comprise either the NEF or an AF. The first packet may contain a first token, and the method may further comprise: receiving a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identifying the first LoRaWAN gateway based on the first token; and forwarding the first acknowledgement to the first LoRaWAN gateway.

[0145] The first packet may contain a first token, and the method may further comprise: receiving a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identifying the first LoRaWAN gateway as the gateway from which the first packet containing the first token was received; and forwarding the first acknowledgement to the first LoRaWAN gateway.

[0146] The first packet may contain a timestamp and the method may further comprise: receiving a second packet from the first LNS, the second packet containing a second timestamp and a second LoRaWAN frame; determining, from the first timestamp and the second timestamp, whether the second packet is for the first LoRaWAN gateway; and relaying the second packet to the first LoRaWAN gateway if the second packet is for the first LoRaWAN gateway.

[0147] The second packet may be triggered by the first packet. The method may comprise identifying the LoRaWAN gateway that sent the first packet by using the second timestamp and the first timestamp. The identifying may comprise determining that the difference in values of the second timestamp and the first timestamp comprises an integer value of seconds. The method may comprise sending the second packet to the identified LoRaWAN gateway. Note that several gateways may have sent a first packet that triggered the second packet but only one of these first packets contains a first timestamp that gives an integer result after being subtracted from the second timestamp. In other words: The LNS may receive multiple first packets from different gateways.

The LNS selects one of these gateways and then creates the second timestamp (in the second packet) based on the first timestamp of the selected gateway.

[0148] The method may further comprise: receiving a second acknowledgement from first LoRaWAN gateway, the second acknowledgement acknowledging the second packet and comprising a second token; and forwarding the second acknowledgment to the first LNS if the second token matches the first token.

[0149] When an LNS sends an acknowledgment containing a token, the method may comprise forwarding the acknowledgment to a gateway that has sent a request containing the same token. When a gateway sends an acknowledgment containing a token, the method may comprise forwarding the acknowledgment to an LNS that has sent a request containing the same token.

[0150] The method may further comprise: sending a device address request message to a function, the device address request message comprising a device identity and information defining the LNS; and receiving a response message containing the device address.

[0151] The function may comprise either the NEF or an AF. The context information may store not only the permanent identities (DevEUIs) of the end devices served by the LNS, but also the temporary identities (DevAddrs) of these devices.

[0152] There is further provided an application function in a wireless communication network, the application function comprising a processor and a memory coupled with the processor. The processor is configured to cause the application function to: send a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; and receive a response message from the first network node, the response message containing an identity for the created context information.

[0153] The processor may be further arranged to: receive a device address request message from the first network node, the device address request message comprising a device identity and information defining the LNS; and send a response message containing the device address to the first network node.

[0154] Figure 11 illustrates a method 1100 in an application function in a wireless communication network, the method 1100 comprising: sending 1110 a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; and receiving 1120 a response message from the first network node, the response message containing an identity for the created context information.

[0155] In certain embodiments, the method 1100 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0156] The method may further comprise: receiving a device address request message from the first network node, the device address request message comprising a device identity and information defining the LNS; and sending a response message containing the device address to the first network node.

[0157] Accordingly, there is provided herein a new network function in a 5G mobile network (i.e., the LoRaWAN Forwarding Function), which enables communication between a set of LoRaWAN gateways deployed in the 5G mobile network and one or more LoRaWAN Network Servers (LNSs).

[0158] There is also provided a definition of an Application Function (AF), which enables a LoRaWAN Network Server (LNS) to communicate with the LoRaWAN Forwarding Function and to create context information in the LoRaWAN Forwarding Function for routing LoRaWAN traffic between LoRaWAN end devices and the one or more LNSs.

[0159] Accordingly, there is provided a method in a first network node in a mobile communication network, the method comprising: Creating context information [LNS Context] containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; Receiving a first packet from a first LoRaWAN gateway [Push_Data], the first packet containing a first token; Selecting a first LNS from the first set of LoRaWAN network servers using the context information; and Forwarding the first packet to the first LNS.

[0160] The method of may further comprise: Receiving a request message [either from the NEF or directly from an AF] comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; Creating a context information by storing the first set of parameters associated with the LNS; and Sending a response message [to NEF or directly to AF] containing an identity for the created context information.

[0161] The method may further comprise: Receiving a second packet from the first LNS, the second packet containing a second token; and relaying the second packet to the first LoRaWAN gateway, if the second token is equal to the first token.

[0162] It should be noted that the above-mentioned methods and apparatus illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0163] Further, while examples have been given in the context of particular communication standards, these examples are not intended to be the limit of the communication standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system, and indeed any communication system which uses routing rules.

[0164] The method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods.

[0165] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A first network node in a wireless communication network, the first network node comprising: a processor; and a memory coupled with the processor, the processor configured to cause the first network node to: create context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receive a first packet from a first LoRaWAN gateway; select a first LNS from the first set of LoRaWAN network servers using the context information; and forward the first packet to the first LNS.

2. The first network node of claim 1, wherein the processor is further arranged to: receive a context request message from a function, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; wherein the context information is created using the received first set of parameters associated with an LNS and the list of LoRaWAN end devices served by the LNS; and send a response message to the function, the response message containing an identity for the created context information.

3. The first network node of claim 1 or 2, wherein the first packet contains a first token and wherein the processor is further arranged to: receive a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identify the first LoRaWAN gateway based on the first token; and forward the first acknowledgement to the first LoRaWAN gateway.

4. The first network node of claim 1 or 2, wherein the first packet contains a first token, and wherein the processor is further arranged to: receive a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identify the first LoRaWAN gateway as the gateway from which the first packet containing the first token was received; and forward the first acknowledgement to the first LoRaWAN gateway.

5. The first network node of any preceding claim, wherein the first packet contains a timestamp, and wherein the processor is further arranged to: receive a second packet from the first LNS, the second packet containing a second timestamp; determine, from the first timestamp and the second timestamp, whether the second packet is for the first LoRaWAN gateway; and relay the second packet to the first LoRaWAN gateway if the second packet is for the first LoRaWAN gateway.

6. The first network node of claim 5, wherein the second packet contains a second token, and wherein the processor is further arranged to: receive a second acknowledgement from first LoRaWAN gateway, the second acknowledgement containing the second token; identify the first LNS as the LNS from which the second packet containing the second token was received; and forward the second acknowledgment to the first LNS.

7. The first network node of any preceding claim, wherein the processor is further arranged to: send a device address request message to a function, the device address request message comprising a device identity for a first LoRaWAN end device and information defining the LNS; and receive a response message containing the device address for the first LoRaWAN end device.

8. A method in a first network node in a wireless communication network, the method comprising: creating context information containing information identifying each of a first set of LoRaWAN network servers and a list of LoRaWAN end devices served by each LoRaWAN Network Server (LNS) in the first set; receiving a first packet from a first LoRaWAN gateway; selecting a first LNS from the first set of LoRaWAN network servers using the context information; and forwarding the first packet to the first LNS.

9. The method of claim 8 further comprising: receiving a context request message from a function, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including the identity of the LNS and a list of LoRaWAN end devices served by the LNS; wherein the context information is created using the received first set of parameters associated with an LNS and the list of LoRaWAN end devices served by the LNS; and sending a response message to the function, the response message containing an identity for the created context information.

10. The method of claim 8 or 9, wherein the first packet contains a first token, the method further comprising: receiving a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identifying the first LoRaWAN gateway based on the first token; and forwarding the first acknowledgement to the first LoRaWAN gateway.

11. The method of claim 8 or 9, wherein the first packet contains a first token, the method further comprising: receiving a first acknowledgement from the first LNS, the first acknowledgement containing the first token; identifying the first LoRaWAN gateway as the gateway from which the first packet containing the first token was received; and forwarding the first acknowledgement to the first LoRaWAN gateway.

12. The method of any of claims 8 to 11, wherein the first packet contains a timestamp, the method further comprising: receiving a second packet from the first LNS, the second packet containing a second timestamp; determining, from the first timestamp and the second timestamp, whether the second packet is for the first LoRaWAN gateway; and relaying the second packet to the first LoRaWAN gateway if the second packet is for the first LoRaWAN gateway.

13. The method of claim 12, wherein the second packet contains a second token, the method further comprising: receiving a second acknowledgement from first LoRaWAN gateway, the second acknowledgement containing the second token; identifying the first LNS as the LNS from which the second packet containing the second token was received; and forwarding the second acknowledgment to the first LNS.

14. The method of any of claims 8 to 13, further comprising: sending a device address request message to a function, the device address request message comprising a device identity for a first LoRaWAN end device and information defining the LNS; and receiving a response message containing the device address for the first LoRaWAN end device.

15. An application function in a wireless communication network, the application function comprising: a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: send a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including information identifying the LNS and a list of LoRaWAN end devices served by the LNS; and receive a response message from the first network node, the response message containing an identity for the created context information.

16. The application function of claim 15, wherein the processor is further arranged to: receive a device address request message from the first network node, the device address request message comprising a device identity for a first LoRaWAN end device and information defining the LNS; and send a response message containing the device address for the first LoRaWAN end device to the first network node.

17. A method in an application function in a wireless communication network, the method comprising: sending a context request message to a first network node, the context request message comprising a first set of parameters associated with an LNS, the first set of parameters including information identifying the LNS and a list of LoRaWAN end devices served by the LNS; and receiving a response message from the first network node, the response message containing an identity for the created context information.

18. The method of claim 17, further comprising: receiving a device address request message from the first network node, the device address request message comprising a device identity for a first LoRaWAN end device and information defining the LNS; and sending a response message containing the device address for a first LoRaWAN end device to the first network node.