WO2019001713A1

WO2019001713A1 - A method of authentication of a long range radio device

Info

Publication number: WO2019001713A1
Application number: PCT/EP2017/066134
Authority: WO
Inventors: Patrik Salmela; Anupma Grover; Mikael Eriksson; Fredrik Svensson; Carlos Jaramillo
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-06-29
Filing date: 2017-06-29
Publication date: 2019-01-03

Abstract

A method (30) of authentication of a long range radio, LoRa, device (2) is provided. The method (30) is performed by a LoRa network controller (4) and comprises receiving (31), from the LoRa device (2), a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device (2), obtaining (32), based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server (7), ABS, for use in authenticating the received join request message, obtaining (33) a verified join accept message from the ABS (7), the ABS (7) being identified based on the obtained information on the ABS (7), and forwarding (34) the verified join accept message to the LoRa device (2), enabling the LoRa device (2) to derive a network session key, NwkSKey, and an application session key, AppSKey. Methods in a authentication and bootstrapping server 7, and an application server, and corresponding devices are also provided.

Description

A method of authentication of a long range radio device Technical field

The technology disclosed herein relates generally to the field of Long Range technology, and in particular to a method of authentication of a long range radio, to devices, nodes, computer programs and computer program products.

Background

LoRa (LongRange) is a low power radio solution aimed mainly at Internet of Things (IoT) and constrained devices. Until recently, most machine-to-machine (M2M) and IoT services have largely relied on licensed cellular, wireline and satellite networks for their wide area connectivity requirements. However, for many low bandwidth IoT applications, traditional cellular networks are deemed too expensive due to excessive power consumption and complex protocols that lower battery lifetime of the IoT devices. As a result, a number of Low Power Wide Area (LPWA) alternatives, such as LoRa, have emerged that specifically seek to address these concerns.

LPWA networks are optimized to provide wide area coverage with minimal power consumption. Typically being reliant on unlicensed frequencies, LPWA profile IoT devices have low data rates, long battery lives and can operate unattended for long periods of time. Licensed LPWA technologies such as narrow-band (NB)-IoT and Long Term Evolution Category Ml (LTE Cat-Mi) are also beginning to gain traction.

Already prevalent in IoT applications such as smart metering, lighting control and parking management, LPWA networks are expected to make a significant

contribution to the M2M and IoT ecosystem, with high service revenues expected.

With the recent completion of the NB-IoT, LTE Cat-Mi and Extended coverage (EC) Global System for Mobile communication (GSM) IoT standards by the 3GPP, mobile operators are aggressively investing in software upgrades to build their own carrier- grade LPWA networks.

There are challenges preventing large LoRa gateway deployments, with respect to authentication, that are perceived as market barriers by mobile operators and industry. For instance, there is a lack of standardization and at present the IoT sector is highly fragmented with a range of different LPWA networking technologies. This is forcing Original equipment manufacturers (OEMs) and service providers to invest in products for multiple and proprietary technologies, leading to higher product costs.

Mobile operators have invested heavily in building robust and reliable 3GPP networks and therefore it is important for them to be able to re-use as much as possible of the existing assets and resources for both 3GPP and LPWA networks and avoid network elements redundancy such as, for instance, different subscription data bases: one for 3GPP devices/subscriptions and another one for LoRa

devices/subscriptions. However, there are integration complexities in re-using existing assets and resources for LPWA networks. For instance, IoT is typically considered to be an enabling technology as it integrates into existing applications, and therefore it is important to have a scalable and cost efficient horizontal solution that would enable an easy and standardized procedure for LoRa Gateway and device integration with existing application regardless of the vertical solutions.

In the LoRa ecosystem there is an inadequate handling of credentials and Identity and Access Management (IAM) in a system of larger scale. At the moment there is no general solution for authentication within the LoRa echo system. These systems are often small with specific system set ups for each solution, resulting in a fragmented landscape when it comes to authentication. As a consequence of the fragmented ways of handling authentication, LoRa network providers must follow multiple specific rules for handling keys depending on each specific LoRa Wide Area Network (WAN) implementation.

For LoRa to be a viable solution in a somewhat larger scale over-the-air

authentication (OTAA) is a prerequisite, since it allows for handling of individual devices without pre-sharing information about the network structure and services. In many of the networks, pre-provisioned LoRa devices are used for practical reasons, but this is not a viable long term solution. Drawbacks of pre-provisioning comprise, for instance, the cost thereof, scalability and security.

Summary

An objective of the present teachings is to address and improve various aspects for deployment of LoRa networks. A particular objective is to enable an improved LoRa device authentication, allowing mobile operators to deploy LoRa networks in a cost efficient way while also providing a secure authentication. These objectives and others are achieved by the methods, devices, computer programs and computer program products according to the appended independent claims, and by the embodiments according to the dependent claims.

The objective is according to an aspect achieved by a method of authentication of a long range radio, LoRa, device. The method is performed by a LoRa network controller. The method comprises receiving, from the LoRa device, a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device; obtaining, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server, ABS, for use in authenticating the received join request message; obtaining a verified join accept message from the ABS, the ABS being identified based on the obtained information on the ABS; and forwarding the verified join accept message to the LoRa device, enabling the LoRa device to derive a network session key, NwkSKey, and an application session key, AppSKey.

The method provides a number of advantages. For instance, the method enables leveraging on existing 3GPP standard, interfaces and networks elements for device authentication based on/similar to Generic Bootstrapping Architecture (GBA). It is an authentication and key agreement mechanism that can be used as baseline to define an ABS procedure to enable LoRa device authentication. This would allow mobile operators to deploy and position LoRa networks in a cost efficient way while also providing strong device and service authentication for application data transmitted all the way from the LoRa device and Gateways to IoT applications.

The objective is according to an aspect achieved by a computer program for a network controller. The computer program comprises computer program code, which, when run on at processing circuitry of the network controller causes the network controller to perform the method as above.

The objective is according to an aspect achieved by a computer program product comprising a computer program as above and a computer readable means on which the computer program is stored.

The objective is according to an aspect achieved by a long range radio, LoRa, network controller for authentication of a LoRa device. The LoRa network controller is configured to: receive, from the LoRa device, a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device, obtain, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server, ABS, for use in authenticating the received join request message, obtain a verified join accept message from the ABS, the ABS being identified based on the obtained information on the ABS, and forward the verified join accept message to the LoRa device, enabling the LoRa device to derive a network session key, NwkSKey, and an application session key, AppSKey.

The objective is according to an aspect achieved by a method of authenticating a join request message for a long range radio, LoRa, device. The method is performed by an authentication and bootstrapping server and comprises: receiving, from a network controller of a LoRa network, a join request message relating to the LoRa device, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr, requesting, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database, receiving in response, from the subscriber database, the authentication vector, AppKey, and information on at least one application server providing a service requested in the join request message, verifying the join request message based on the received authentication vector, AppKey, and sending, to the network controller, a generated join accept message in response to the join request message.

The objective is according to an aspect achieved by a computer program for an authentication and bootstrapping server. The computer program comprises computer program code, which, when run on at processing circuitry of the authentication and bootstrapping server causes the authentication and bootstrapping server to perform the method as above.

The objective is according to an aspect achieved by an authentication and

bootstrapping server for authenticating a join request message for a long range radio, LoRa, device. The authentication and bootstrapping server is configured to: receive, from a network controller of a LoRa network, a join request message relating to the LoRa device, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr, request, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database, receive in response, from the subscriber database, the authentication vector, AppKey, and information on at least one application server providing a service requested in the join request message, verify the join request message based on the received authentication vector, AppKey, and send, to the network controller, a generated join accept message in response to the join request message.

The objective is according to an aspect achieved by a method of providing services to a long range radio, LoRa, device. The method is performed in an application server and comprises receiving, from a LoRa network controller, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server, ABS, and identifying the ABS based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS.

The objective is according to an aspect achieved by a computer program for an application server. The computer program comprises computer program code, which, when run on at processing circuitry of the application server causes the application server to perform the method as above.

The objective is according to an aspect achieved by an application server for providing services to a long range radio, LoRa, device. The application server is configured to: receive, from a LoRa network controller, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server, ABS, and identify the ABS based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS.

The methods according to the present teachings, enable the authentication and bootstrapping server (ABS) to be located and enables the ABS to be implemented as part or extension of Bootstrapping Server Function, BSF and existing 3GPP interfaces may be used, or interfaces based on existing 3GPP interfaces. Further, the methods provide functions for requesting authentication vectors to use for LoRa device authentication. Further yet, the method in the network controller enables it to create a modified DevAddr and define how the network controller and application server can use the modified DevAddr for requesting their respective keys and how the authentication and bootstrapping server can verify (i.e. using stored identities/certs of NC/AS) that those entities are allowed to get those keys.

Further features and advantages of the present disclosure will become clear upon reading the following description and the accompanying drawings.

Brief description of the drawings

Figure 1 illustrates an environment in which embodiments according to the present teachings may be implemented.

Figure 2 is a signaling diagram illustrating various embodiments according to the present teachings.

Figure 3 is a signaling diagram illustrating various embodiments according to the present teachings.

Figure 4 illustrates a flow chart over steps of a method in a network node in accordance with the present disclosure.

Figure 5 illustrates schematically a network node and means for implementing methods of the present disclosure.

Figure 6 illustrates a device comprising function modules/software modules for implementing methods of the present disclosure.

Figure 7 illustrates a flow chart over steps of a method in an authentication and bootstrapping server in accordance with the present disclosure.

Figure 8 illustrates schematically an authentication and bootstrapping server and means for implementing methods of the present disclosure.

Figure 9 illustrates an authentication and bootstrapping server comprising function modules/software modules for implementing methods of the present disclosure. Figure 10 illustrates a flow chart over steps of a method in an application server in accordance with the present disclosure.

Figure 11 illustrates an application server and means for implementing methods of the present disclosure.

Figure 12 illustrates an application server comprising function modules/software modules for implementing methods of the present disclosure.

Detailed description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.

Figure 1 illustrates an environment in which embodiments according to the present teachings may be implemented. In particular, a communications network 1 is shown comprising one or more LoRa networks 9, 9a, a service provider network 6 and e.g. a 3GPP network.

A LoRa device 2 comes pre-installed with a master secret (128 bit AppKey), a globally unique device identifier (64 bit DevEUI) that identifies each end LoRA device globally uniquely and an application identifier (64 bit AppEUI), identifying the application provider. The LoRa device 2 connects to a LoRa network 1 via a LoRa gateway (GW)

3, which forwards the traffic of the LoRa device 2 to a LoRa network controller (NC)

4. The NC 4 could be seen as just one function, but it could also be split into multiple functions, possibly implemented in different nodes. The NC 4 is therefore more like a LoRa core network. The NC 4 further communicates application data of the LoRa device 2 to an application server (AS) 5, which may be part of a cloud computing environment 6. The LoRa device 2 sends Media Access Control (MAC) frames to the GW 3, which forwards them, over Internet Protocol (IP), to the NC 4. The NC 4 further forwards the payload over IP to the AS 5. The NC 4 is responsible for identifying the AS 5 to which the payload should be sent. For this, the NC 4 can use the AppEUI, received in a Join message request from the LoRa device 2, and the LoRa device 2 can indicate different services/ASs by using different FPort values in the messages it sends. FPort is used for mapping messages from a device to different ASs. Hence, an application provider identified by AppEUI can have multiple services that are indicated by FPort values in the payload messages. A first LoRa network 9 is, in the figure 1, illustrated as comprising LoRa devices 2, 2a, gateways 3, 3a and a NC 4. It is noted that a LoRa network may comprise fewer or additional devices/entities. A second LoRa network 9a is also illustrated, comprising a gateway 3b and a network controller 4a. The first and second LoRa networks 9, 9a may be provided by the same network provider or by different network providers.

The LoRa device 2 connects to the LoRa network 9 by transmitting a Join request message, which contains unique device identifier DevEUI, AppEUI and a nonce and is signed with AppKey. The message might be heard by multiple GWs 3, 3a, 3b, which all forward the message to their NC 4, 4a. The NC 4 is responsible for handling duplicate messages from different GWs 3, 3a. Currently LoRa assumes that a LoRA device 2 cannot roam between LoRa network providers; if a Join request reaches an NC 4 that does not know the unique device identifier DevEUI, the NC 4 will drop the Join request. The NC 4 then generates DevAddr, which is a short (globally non- unique) identifier for the device 2, uniquely identifying the device 2 in the LoRa network 1 and can be seen as a Join/session identifier for the device 2. DevAddr has a 7-bit prefix identifying the communications network 1, for helping in roaming situations.

Currently, if a "visited" network controller receives a message with DevAddr with other than its own prefix, the network controller drops the packet. The network controller, possibly by itself or by utilizing a separate network server (not illustrated), authenticates the Join request. The network server may be one or more hosts providing the LoRa core network, which the network controller is also part of. The network controller or the network server also possesses the AppKey and has a mapping from DevEUI to the key. A mapping may be seen as a unique one-to-one pair, e.g. a key value pair. A particular example on the latter is the unique identifier, DevEUI being the key which identifies the value of the application key, AppKey.

Using the key, the received nonce and an application nonce (and other parameters) the NC 4 generates a network session key (NwkSKey) and an application session key (AppSKey). Finally the network controller generates the Join accept message, which includes the application nonce and DevAddr (received together with Join request from network controller if using a separate network server) and is encrypted with the AppKey. A Join accept message is sent back to the LoRa device 2, which can generate NwkSKey and AppSKey using the received parameters. After this, each payload packet sent by the LoRa device 2 will contain the DevAddr as identifier to the keys needed for verifying the messages.

In contrast to the above, the storage of AppKey and authentication of the Join request is handled by a trusted party. That is, this service is "outsourced" to an external party (external to the LoRa network), e.g. located in a mobile communications network (although the LoRa network and the entities handling the service externally may have same owner). This trusted party also provides the NwkSKey to the NC 4 for use in decrypting the traffic.

When the NC 4 receives the first payload message, it will see DevAddr and be able to map it to the device/session context (possibly) generated during the Join exchange. The NC 4, if not the one performing the authentication, contacts an

authentication/Join server over a secure session (typically certificate based Transport Layer Security (TLS) protocol) and requests NwkSKey using DevAddr. After authenticating the NC 4, the authentication server provides NwkSKey which the NC 4 can use for verifying integrity and decrypting network level protection of packets received from the device 2. Once the payload packet network level security is verified the NC 4 creates an IP packet containing the payload from the LoRa device 2 and forwards this to the AS 5, possibly over the Internet (it is noted that the AS 5 may be part of the NC 4).

The present teachings introduce an authentication and bootstrapping server (ABS) 7 for LoRa for defining procedures for LoRa devices 2, 2a leveraging on existing 3GPP elements, interfaces and procedures. The ABS 7 authenticates the described Join message. The ABS 7 interacts with a 3GPP subscriber database 8 (e.g. Home

Subscriber Server, HSS) and fetches LoRa specific authentication vectors for authenticating LoRa devices 2, 2a. The ABS 7 also provides keys for ASs 5. Further, the methods according to the present teachings also solve issues on how the AS 5 may identify the ABS 7 and query the AppSKey from it. A lookup service 12 is provided. The lookup service 12 may, for instance, be distributed hash table (DHT) based, which is a highly appropriate embodiment assuming the AppEUI remains as it is currently: an identifier in a flat identifier space (i.e. no structure in AppEUI for helping route to the correct ABS 7).

The lookup service 12 may be implemented similar to Domain Name System (DNS) if the AppEUI will have some structure which would make it possible to have a hierarchical lookup service. As an example, such hierarchical lookup service may be implemented in a way similar to International mobile subscriber identity (IMSI). In particular, in some embodiments, the structure of the AppEUI may be such that the AppEUI comprises a prefix identifying e.g. geographical area or operator, similar to IMSI. In other embodiments, a specific scheme may be implemented, e.g. wherein the first 8 bits identifies continent, 8 next bits identifies country etc.

The lookup service 12 may be global or local to NC 4 with a full list of AppEUI to ABS 7 mappings. This is feasible as long as the number of ABSs 7 remains reasonably small and the list is more or less static

The LoRa specification does not define or defines poorly the AppSKey

communication to the AS 5 and seems to assume that the AS 5 is co-located with the NC 4 and Join/authentication server. However, as with roaming, these things are still unresolved. Even if not specified, it means that if a payload message is sent to an AS 5 outside the NC domain it must also contain some token that the AS 5 can use for requesting the AppSKey from Join/authentication server.

Figure 2 is a signaling diagram illustrating various embodiments according to the present teachings. In particular, figure 2 shows a LoRa Join flow that enables the interconnection of LoRa networks and 3GPP core networks.

At arrow Ai, the LoRa device 2 sends a Join message according to LoRa

specifications. The Join message comprises the device identifier (DevEUI), device owner/application identifier (AppEUI) and a device nonce, as described earlier.

At arrow A2, the Join message reaches the NC 4 according to LoRa specifications and the NC 4 tries to identify the ABS 7 (Join/authentication server) to use for

authenticating the Join message. If the information is not available locally at the NC 4, i.e. if there is no mapping from AppEUI to an ABS 7, the NC 4 queries the lookup service 12 using the AppEUI or the DevEUI as key. Examples on how to implement the lookup service 12 was given in relation to figure 1, and reference is made to the corresponding description.

At arrow A3, the response to the lookup is received in the NC 4. The response comprises all relevant ABS information. The relevant ABS information may comprise some reachability information, such as for instance IP address, Fully Qualified Domain Name (FQDN) etc. and a certificate for authenticating the ABS 7.

It is noted that the NC 4 may have the mappings from AppEUI to an ABS 7 locally, and therefore arrow A3 may be omitted in some embodiments, and arrow A2 may then comprise identifying the ABS 7 locally in the NC 4.

At box B4, the NC 4 stores the mapping of the AppEUI to ABS for use for later Join requests. Multiple devices can have the same AppEUI, thus the first device joining the network will result in the lookup service 12 being used, while the subsequent joins, from the same or other devices with the same AppEUI, can be served based on the cached AppEUI to ABS mapping. The NC 4 may, in some embodiments, add some timeout value for cached mappings so that the information can be re-fetched every now and again to guarantee updated mappings.

Still at box B4, the NC 4 generates all relevant LoRa parameters according to specification. This comprises, for instance, network ID (NetID) and DevAddr and radio specific parameters. DevAddr and other relevant parameters may be stored in a Join context (according to specification) together with ABS information (or pointer to ABS information) and DevEUI. DevEUI is needed for not ending up with multiple contexts in case the device does a new Join while the old context is still alive in NC 4. If there already is a context with the same DevEUI, it is linked from this new context for later deletion upon successful Join.

Further, the NC 4 creates an IP packet with the Join request and adds also other relevant parameters needed in the Join accept message, as it will be created and encrypted by the ABS 7, including DevAddr.

At arrow A5, based on the ABS information resolved for the AppEUI, the NC 4 establishes (if not already existing) a secure connection, e.g. a TLS connection, to the ABS 7 according to specification, and sends the IP packet comprising the Join request to the ABS 7.

At arrow A6, the ABS 7 requests an authentication vector from the subscriber database 8 (exemplified in the figure as being a 3GPP HSS) based on the device identifier DevEUI.

At arrow A7, the subscriber database 8 returns an authentication vector, which in the LoRa case may comprise just the subscription root key (AppKey). In addition, information about ASs may be included. In a basic case the information returned from the subscriber database 8 just identifies an AS 5 by IP address or a fully qualified domain name (FQDN) and also includes a certificate for authenticating the AS 5. However, it is noted that the present teachings may be applied also in scenarios where there are multiple ASs for a device 2; the information from the subscriber database 8 may include information for all ASs registered for the device 2, mapped to their associated FPort value. As noted earlier, FPort is used for mapping messages from a device 2 to different ASs.

At box B8, the ABS 7 verifies the Join message based on the received AppKey, according to LoRa specification. If the verification is successful the ABS 7 creates a context for the device 2 and stores AppKey and received AS info and relevant parameters received in Join message (mainly DevAddr). In addition, the ABS 7 stores the identity (e.g. public key from cert, or hash of public key) and/or certificate of the NC 4. This is needed so that no other NC can request NwkSKey of the device 2 from ABS 7. The ABS 7 then generates an application nonce and now, or later when the keys are needed, also generates NwkSKey and AppSKey. The ABS 7 generates the Join accept message according to LoRa specification.

At arrow A9, the ABS 7 sends the Join accept message to NC 4 over IP and a secure connection (e.g. TLS), according to LoRa specifications. This is in essence a reply to message at arrow A5.

At arrow A10, the NC 4 creates a MAC frame version of the Join accept message and forwards it to the device 2.

At box B11, the device 2 verifies the Join accept message and derives NwkSKey and AppSKey. Step 4 (i.e. box B4) above illustrates how DevAddr, the session identifier, is generated at the NC 4 and then communicated to the ABS 7. In other embodiments, the

DevAddr (similar to a Bootstrapping Temporary Identifier, B-TID, in GBA) is generated in the ABS 7 in step 8 (i.e. arrow A8) together with the nonce. In such embodiments, the DevAddr should be communicated to NC 4 in step 9 (i.e. arrow A9), since otherwise the NC 4 would not know it when getting payload messages; DevAddr is sent to the device 2 encrypted by the ABS 7 and then included in the payload messages from the device 2 to map to the session context in the NC 4, which means that the NC 4 needs to know the DevAddr before the first payload message arrives. A benefit is that if multiple NCs use the same ABS 7 in conventional LoRa manner, then there could be DevAddr collisions, i.e., multiple NCs select the same DevAddr which means that the ABS 7 will not (at least not easily) be able to distinguish between different contexts based on DevAddr. However, deriving

DevAddr in the ABS 7 would solve that problem. In particular, in case the DevAddr is generated by the ABS 7, the ABS 7 may include the DevAddr in plaintext together with the join accept message in the protected channel between the NC 4 and the ABS 7 (i.e. the DevAddr is protected) so that the NC 4 can learn it. The NC 4 does not forward DevAddr to the device 2 as DevAddr is already a part of the join accept message. In a similar way, NwkSKey and application server information may optionally be communicated to the NC 4 together with the join accept message over the protected channel so that the NC 4 would not have to request the key later when the device 2 sends its first payload message.

Figure 3 is a signaling diagram illustrating various embodiments according to the present teachings, more specifically LoRa payload communication. Thus, figure 3 shows how data is sent and handled in the modified LoRa system according to the various embodiments disclosed herein.

At arrow A101, the device 2 sends a payload message according to LoRa specification.

At box B102, the NC 4 locates the device context based on DevAddr in the received payload message. The NC 4 modifies the DevAddr to also include a pointer to ABS 7 (e.g. FQDN or IP address or the like). The NC 4 may, for instance, modify the

DevAddr by creating a new DevAddr looking like <DevAddr>@abs.com. Then the NC 4 creates a key request message with the modified DevAddr as DevAddr. The modified DevAddr thus comprises a pointer to the ABS 7. At arrow A103, the NC 4 creates, if not already existing, a secure session (TLS) with ABS 7 based on ABS information and certificate stored in device context in NC 4 and sends the key request message to the ABS 7.

A box B104, the ABS 7 locates the Join context based on the DevAddr received in the key request message and verifies that the key request came from the same identity as was used for communicating the original Join request. This verification may be performed by comparing the identity (e.g. public key or certificate) used for securing the key request and the identity stored in the Join context. If the identities match, then the ABS 7 verifies that it is the correct NC 4 that is requesting the key. The ABS 7 also recognizes that the key request is for NwkSKey, since the request came from the identity stored in the join context as the NC identity. Thus, if the NwkSKey is not already generated, the ABS 7 generates the key.

At arrow A105, the ABS 7 sends the key NwkSKey to the NC 4 over the TLS protected channel, and also includes the relevant AS information (AS to FPort mapping) received in step 7 (i.e. arrow A7 of the Join flow, figure 2). AS-information may, in other embodiments, be communicated from the ABS 7 to the NC 4 in the join flow, step 9 (i.e. arrow A9 of the Join flow, figure 2).

At box B106, the NC 4 verifies the network level security of the payload message, after which it generates an IP packet with the payload message payload. In addition to the payload, the IP packet will contain the modified DevAddr parameter generated in step 2 (i.e. box B102).

At arrow A107, if there is only one AS record (received in step 5, i.e. arrow A105) in the device context in NC 4, the NC 4 sends the IP packet to the identified AS 5. If there are more than one AS records, the NC 4 may use the FPort value in the received payload message to map to the correct AS 5 and then forwards the message to that AS

5·

At box 108, the AS 5 uses the ABS info added to the modified DevAddr in order to identify the ABS 7 from which to fetch the AppSKey.

At arrow A109, by using the information about which ABS 7 to connect to, the AS 5 and ABS 7 create a TLS session secured and authenticated by each other's certificates. The AS 5 sends a key request over the TLS connection, including the modified

DevAddr.

At Box Bno, the ABS 7 locates the Join context based on DevAddr and verifies that the identity of AS 5 is also stored in the AS entry of the Join context. This may be done by comparing identities (e.g. public key or hash of public key or the like) of the certificates used by AS 5 and found in Join context. It is noted that this verification is similar to the NwkSKey request verification performed earlier (see Box B104). If the Join context has multiple AS records, the ABS 7 derives AS specific AppSKey for the AS 5 (if this has not already been done during the Join procedure described in relation to figure 2). AS specific AppSKey generation may then take as additional input some form of identifier of the AS 5, e.g. public key of the AS 5, or hash of the public key of the AS 5.

At arrow Am, the ABS 7 responds over the TLS session with the key AppSKey. At box B112, the AS 5 decrypts the payload message.

After the first payload message the keys and state are already available in the network, which means that steps 3, 4, 5, 8, 9, 10, 11 may be omitted. When the AS 5 receives the next payload message, it will still include the modified DevAddr, which can be used for locating the correct AppSKey in the AS 5 for decrypting the message.

The various embodiments described thus far and the various features thereof can be combined in many different ways, particular examples of which are given in the following.

Figure 4 illustrates a flow chart over steps of a method in a network node, in particular a network controller, in accordance with the present disclosure. The method 30 of authentication of a long range radio, LoRa, device 2 may be performed by a LoRa network controller 4.

The method 30 comprises receiving 31, from the LoRa device 2, a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device 2. The unique device identifier, DevEUI, may, for instance, be as defined in LoRa specifications. The application identifier, AppEUI, may, for instance, be as defined in LoRa specifications. The method 30 comprises obtaining 32, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an

authentication and bootstrapping server 7, ABS, for use in authenticating the received join request message. The ABS 7 is most conveniently located based on the

application identifier AppEUI, but it could alternatively be located based on the unique identifier DevEUI, or based on both identifiers. The information on the authentication and bootstrapping server 7 comprises, in various embodiments, one or both of: reachability information such as an IP address or FQDN and a certificate for authenticating the authentication and bootstrapping server 7.

The method 30 comprises obtaining 33 a verified join accept message from the ABS 7, the ABS 7 being identified based on the obtained information on the ABS 7. The obtaining 33 may, for instance and as described with reference e.g. to figure 2, comprise the LoRa network controller 4 sending the join request to the ABS 7, upon which the ABS 7 requests an authentication vector from a subscriber database 8 (e.g. HSS), and sends based thereon, a verified join accept message to the LoRa network controller 4. That is, the obtaining 33 then comprises sending the join request to the ABS 7 and receiving in response the verified join accept message from the ABS 7.

The method 30 comprises forwarding 34 the verified join accept message to the LoRa device 2, enabling the LoRa device 2 to derive a network session key, NwkSKey, and an application session key, AppSKey. The join request message may, and typically does, further comprise e.g. a device nonce.

The method 30 provides a number of advantages, as has already mentioned in the summary section. An important advantage of the method 30, in its various

embodiments, is to leverage on existing 3GPP standard, interfaces and networks elements for device authentication based on or similar to GBA. It is a network access authentication and key agreement mechanism used as baseline to define an ABS procedure to enable LoRa device authentication. This will allow mobile operators to deploy and position LoRa networks in a cost efficient way while also providing strong device and service authentication for application data transmitted all the way from LoRa device and Gateways to IoT applications. The ABS mechanism may be implemented as an enhancement or extension of existing elements defined by 3GPP, as illustrated in figure 5, described later. In an embodiment, the method 30 comprises, upon obtaining 32 the information on the ABS 7, generating LoRa parameters for the LoRa device 2 and storing these in a Join context together with the obtained information on the ABS 7 (which may comprise the ABS information as such or pointer to ABS information) and the unique device identifier, DevEUI, of the LoRa device 2. That is, a device specific context is created, which context comprises ABS information or pointer to ABS information. The LoRa parameters are according to specifications used by the LoRa network controller 4 and the LoRa device 2, e.g. network ID, DevAddr and radio specific parameters.

In some embodiments, the method 30 comprises, upon obtaining 32 the information on the ABS 7, storing the application identifier, AppEUI, linked to the obtained information. That is, the network controller 4 adds an entry to a list of entries on known ABS and adds a pointer from the AppEUI (stored in the Join context) to the ABS information, so that if the network controller 4 receives a new request comprising the same AppEUI, the ABS information can be located based on the AppEUI. That is, by linking the application identifier AppEUI with the obtained ABS information, the LoRa network controller 4 is later able to serve the same or other LoRA devices 2, 2a having the same AppEUI based on the cached AppEUI linked to the ABS information.

In various embodiments, the obtaining 32 comprises:

- querying a lookup service 12 for the information on the ABS 7 by using one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, as key, and

- receiving in response the information on the ABS 7.

In various embodiments, the obtaining 32 comprises fetching, from a storage 44, the information on the authentication and bootstrapping server 7 by using the received application identifier, AppEUI and/or the unique identifier, DevEUI. As noted, by storing the AppEUI linked to the ABS information in a storage 44, the LoRa network controller 4 can serve devices having the same AppEUI using the stored ABS information.

In the above two sets of embodiments, described also earlier, e.g. in relation to figure 2, two ways for the network controller 4 to obtain the necessary information on the ABS 7 are provided: if the information is not available locally at the LoRa network controller 4, i.e. if there is no mapping from the application identifier (e.g. AppEUI) to an ABS 7, the network controller 4 may instead query a lookup service 12 using the application identifier AppEUI and/or the unique identifier, DevEUI, as key.

In various embodiments, the method 30 comprises receiving, from the LoRa device 2, a payload message comprising a session identifier, DevAddr, for the LoRa device 2,

- obtaining a device context based on the session identifier, DevAddr,

- modifying the session identifier, DevAddr, such as to include a pointer to the ABS 7, and

- creating a key request message using the modified identifier. The modified identifier is the result of modifying the session identifier, DevAddr. The modified identifier, also denoted modified session identifier herein, may be a conventional session identifier, DevAddr, to which a pointer to the ABS 7 is included.

It is noted that in still other embodiments, the step of including the pointer to the ABS 7 is omitted. In particular, in other embodiments, the pointer to the ABS 7 may be provided as additional data together with DevAddr (i. e. not as part of DevAddr.

The LoRa network controller 4 may not need to fetch the key from the ABS 7 (i.e. send key request message) for the cases that the ABS 7 includes it earlier, e.g. in the join accept message or in a new non-standard LoRa message from the ABS 7, to the LoRa network controller 4. The key have to be sent in a way such that the LoRa network controller 4 knows to not forward it to the LoRa device 2, the join accept is encrypted end-to-end to device so the LoRa network controller 4 cannot access it. Thus key may be appended to the messages unencrypted so that the LoRa network controller 4 can read it, while still being protected by the TLS session between the LoRa network controller 4 and the ABS 7. However, in such embodiments, also the FPort value etc. would need to be sent to the LoRa network controller 4 together with the key.

Examples on how to modify the session identifier, DevAddr, has been given earlier, and may, for instance, comprise creating a new DevAddr in line with :

<DevAddr>@abs.com. It is however noted that the identifier may be modified to include the pointer to the ABS 7 in other ways as well. In a variation of the above embodiment, the method 30 comprises:

- sending the key request message to the ABS 7,

- receiving in response, from the ABS 7, a network session key, NwkSKey, and any relevant application server 5 information,

- verifying network level security of the payload message,

- generating a packet comprising the payload of the payload message and the modified identifier, and

- sending the packet to the identified application server 5.

Existing GBA architecture provides authentication based on 3GPP subscription credentials. When the UE with 3GPP credentials tries to access a GBA enabled service/Network Application Function (NAF), the NAF will reply with a HTTP 401 Unauthorized message, requesting the UE to authenticate itself. The UE will next run the bootstrapping procedure towards the Bootstrapping Function (BSF), BSF uses the 3GPP credentials (i.e. Internet Protocol Multimedia Subsystem, IMPI) when requesting the authentication vector (AV) and GBA User Security Settings (GUSS) from HSS via Zn interface, by which the UE and the BSF/network mutually authenticate each other. In addition, both parties generate a master key Ks, and the BSF provides the UE with an identifier (B-TID) for the bootstrapping usage procedure. Next, the device generates a NAF specific key (KsNAF) from the master key Ks, using also the FQDN of the NAF as input to the key derivation function (KDF). The UE replies to the 401 message received from the NAF, using the NAF specific key KsNAF as the password and the bootstrapping identifier B-TID as the username. The NAF, which has a trust relationship with the BSF/operator, queries the BSF (using the B-TID) for the NAF specific key KsNAF, which the BSF generates and provides to the NAF. The BSF also provides User Security Settings (USS) for the specific NAF, which can contain service specific policies and information related to the authenticated client. The NAF can now authenticate the device.

The various nodes and devices according to the present teachings may be integrated into this existing architecture. The method 30, in its various embodiments, is well suited for an architecture similar to the GBA. The ABS 7 may, for instance, be implemented as part of the BSF. That is, the ABS 7 may be a standalone function in the 3GPP core network, or it may be an enhanced functionality in the BSF.

The latter case has at least the following advantages:

• The BSF is an authentication function that performs more or less the same function as the ABS 7, even if the protocols etc. are different. Thus, adding ABS 7 to the BSF may be a first step in making the BSF 100 the go-to place for device authentication for multiple different systems when there is a need to interconnect them with 3GPP. In particular operators may benefit from this by removing duplicate functions (authentication, subscription management etc.) from their networks when operating multiple different networks.

• The BSF already has an interface towards the HSS which could be re-used and extended for the LoRa case.

• The BSF 100 is already reachable from the Internet, i.e. it is like a virtual gateway between the public network and the 3GPP core network.

The method 30 provides an interconnection between 3GPP and LoRa networks by, for instance, utilizing the 3GPP subscriber database (HSS) and implementing the ABS LoRa authentication function in the 3GPP core network, potentially as an extension to the BSF or as a standalone function. This makes it possible for an operator to manage its subscribers, both 3GPP and LoRa, in a unified way.

For example:

- The BSF may be updated such as to add ABS business logic needed to manage LoRa device join requests in addition to existing device bootstrapping requests from 3GPP devices.

- HSS and LoRa subscription data bases may be unified in one single repository entity that would be responsible to manage identifiers (DevEUI and IMPI), credentials and authentication vectors for both types of devices (UEs and LoRA devices).

- Back end operations support system/business support system (OSS/BSS) elements and operations would be also simplified by re-using existing Application

Programming Interfaces (APIs). Keeping the Operator community inside the IoT ecosystem is paramount for the success of IoT since the data providing networks are part of there balance sheets. A data service (DS) function built on top of their assets making data streams agnostic of radio technology accessible for the IT world in pull mode provide a valuable service. The DS acts as a SB funnel agnostic of technology providing the operator with capability to capitalize on its infrastructure.

To give the operator the means of leveraging their Home Location Register/ Home Subscriber Server (HRL/HSS) systems simplifies onboarding of technologies and subscribers. The ability to do value adds on data streams such as prominence and/or other metadata available only to the operator enables new business services that offers enhancement on one or many data sources.

Figure 5 illustrates schematically a network node, in particular a network controller 4, and means for implementing methods of the present disclosure.

The network controller 4 comprises processing circuitry 40, which may be any combination of one or more of a suitable central processing unit (CPU),

multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 41, e.g. in the form of a storage medium 41. The processing circuitry 40 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

The processing circuitry 40 is configured to cause the network controller 4 to perform a set of operations, or steps, e.g. as described in relation to one or more of figures 2-4. For example, the storage medium 41 may store the set of operations, and the processing circuitry 40 may be configured to retrieve the set of operations from the storage medium 41 to cause the network controller 4 to perform the set of operations. The set of operations may be provided as a set of executable instructions. The processing circuitry 40 is thereby arranged to execute methods as disclosed herein.

The network controller 4 may also comprise or otherwise have access to a storage or database 44 for storing of e.g. join context, ABS information (e.g. in a linked manner as has been described), and any other information. The network controller 4 also comprises an input/output means 43 (denoted I/O) for communicating wirelessly and/or in a wired manned with other entities and devices. The input/output means 43 may, for instance, comprise a protocol stack, for communication with other network nodes in a wired manner and/or with

communication devices in a wireless manner. The input/output means 44 may be used for receiving data input and for outputting data, e.g. conveying IP packets. The network controller 4 may comprise receiving circuitry and transmitting circuitry. The network controller 4 may also comprise or be connected to an antenna device (not shown), e.g. radio antenna, for wireless communication with the LoRa devices 2, 2a over a wireless link.

A long range radio, LoRa, network controller 4 is provided for authentication of a LoRa device 2. The LoRa network controller 4 is configured to:

- receive, from the LoRa device 2, a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device 2,

- obtain, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server 7, ABS, for use in authenticating the received join request message,

- obtain a verified join accept message from the ABS 7, the ABS 7 being identified based on the obtained information on the ABS 7, and

- forward the verified join accept message to the LoRa device 2, enabling the LoRa device 2 to derive a network session key, NwkSKey, and an application session key, AppSKey.

The network controller 4 may be configured to perform the above steps, and implement any of the described embodiments of e.g. the method 30, e.g. by

comprising one or more processors 40 (or processing circuitry) and memory 41, the memory 41 containing instructions executable by the processor 40, whereby the network controller 4 is operative to perform the steps.

In an embodiment thus, a network controller 4 is provided, for authentication of a LoRa device 2. The network controller 4 comprises one or more processors 40 and memory 41, the memory 41 containing instructions executable by the processor 40, whereby the network controller 4 is operative to: receive, from the LoRa device, a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device, obtain, based on one or both of the

application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server, ABS, for use in authenticating the received join request message, obtain a verified join accept message from the ABS, the ABS being identified based on the obtained information on the ABS, and forward the verified join accept message to the LoRa device , enabling the LoRa device to derive a network session key, NwkSKey, and an application session key, AppSKey.

In an embodiment, the LoRa network controller 4 is configured to, upon obtaining the information on the ABS 7, generate LoRa parameters for the LoRa device 2 and store these in a Join context together with the obtained information on the ABS and the unique device identifier, DevEUI, of the LoRa device 2.

In various embodiments, the LoRa network controller 4 is configured to, upon obtaining the information on the authentication and bootstrapping server 7, store the application identifier, AppEUI, linked to the obtained information.

In various embodiments, the LoRa network controller 4 is configured to obtain by:

- querying a lookup service 12 for the information on the authentication and bootstrapping server 7 by using one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, as key, and

- receiving in response the information on the authentication and bootstrapping server 7.

In various embodiments, the LoRa network controller 4 is configured to obtain by fetching, from a storage 44, the information on the authentication and bootstrapping server 7 by using one or both of the received application identifier, AppEUI and the unique identifier, DevEUI.

In various embodiments, the LoRa network controller 4 is configured to: receive, from the LoRa device 2, a payload message comprising a session identifier, DevAddr, for the LoRa device 2, obtain a device context based on the session identifier,

DevAddr, modify the session identifier, DevAddr, such as to include a pointer to the ABS 7, and create a key request message using the modified identifier. In various embodiments, the LoRa network controller 4 is configured to: send the key request message to the ABS 7, receive in response, from the ABS 7, a network session key, NwkSKey, and any relevant application server 5 information, verify network level security of the payload message, generate a packet comprising the payload of the payload message and the modified identifier, and send the packet to the identified application server 5.

Figure 6 illustrates a device comprising function modules/software modules for implementing methods of the present disclosure. The function modules can be implemented using software instructions such as computer program executing in a processor and/or using hardware, such as application specific integrated circuits (ASICs), field programmable gate arrays, discrete logical components etc., and any combination thereof. Processing circuitry may be provided, which may be adaptable and in particular adapted to perform any of the steps of the method 30 that has been described in various embodiments.

A network controller 4 is provided for authentication of a long range radio, LoRa, device 2.

The network controller 4 comprises a first module 51 for receiving, from the LoRa device 2, a join request message comprising at least an application identifier,

AppEUI, and a unique identifier, DevEUI, of the LoRa device 2. Such first module may, for instance, comprise processing circuitry adapted to receive service requests. In other embodiments, the first module 51 may comprise receiving circuitry for receiving wireless communication from the LoRa device 2.

The network controller 4 comprises a second module 52 for obtaining, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server, ABS, for use in

authenticating the received join request message. Such second module may, for instance, comprise processing circuitry adapted for obtaining such information.

The network controller 4 comprises a third module 53 for obtaining a verified join accept message from the ABS, the ABS being identified based on the obtained information on the ABS. Such third module may, for instance, comprise processing circuitry adapted for obtaining such information. The third module 53 may, as a particular example, comprise transmitting circuitry for sending a join request to a ABS and receiving circuitry for receiving in response a verified joint accept message.

The network controller 4 comprises a fourth module 54 for forwarding the verified join accept message to the LoRa device, enabling the LoRa device to derive a network session key, NwkSKey, and an application session key, AppSKey. The fourth module 54 may, for instance, comprise processing circuitry adapted to forward verified join accept messages.

It is noted that one or more of the modules 51, 52, 53, 54 may be replaced by units.

A method 60 of authenticating a join request message for a long range radio, LoRa, device 2 is provided. The method 60 is performed by an authentication and bootstrapping server 7.

The method 60 comprises receiving 61, from a network controller 4 of a LoRa network 9, a join request message relating to the LoRa device 2, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr.

The method 60 comprises requesting 62, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database 8.

The method 60 comprises receiving 63 in response, from the subscriber database 8, the authentication vector, AppKey, and information on at least one application server 5 providing a service requested in the join request message. That is, in response to requesting 62 an authentication vector from the subscriber database 8 (e.g. HSS), the subscriber database 8 sends the authentication vector, which the ABS 7 receives.

The method 60 comprises verifying 64 the join request message based on the received authentication vector, AppKey.

The method 60 comprises sending 65, to the network controller 4, a generated join accept message in response to the join request message. In some embodiments, the authentication vector is simply the AppKey, but it is noted that in other embodiments also other parameters may be included. In preferred embodiments, the subscriber database 8 is a 3GPP HSS. This enables a convenient way of providing an interconnection between a 3GPP network and a LoRa network by utilizing the 3GPP subscriber database (HSS) and implementing the ABS 7 LoRa authentication function in the 3GPP core, potentially as an extension to the BSF or as a standalone function. This in turn makes it possible for an operator to manage its subscribers, both 3GPP and LoRa subscribers, in a unified way.

In an embodiment, the method 60 comprises storing one or more of the

authentication vector, AppKey, and an identity of the network controller 4. The AppKey may then be used for generating NwkSKey and AppSKey, and the network controller identity may be used for verifying the network controller during key requests. The identity on the network controller 4 is stored for later verification of the network controller 4 identity when it requests NwkSKey. The identity of the network controller 4 may, for instance, comprise a certificate, a public key, a raw public key or hash of public key or yet some other authenticatable identifier.

In various embodiments, the method 60 comprises creating a context for the LoRa device 2 and storing at least the authentication vector, AppKey, and the received information on the at least one application server 5.

In various embodiments, the method 60 comprises storing information for all application servers 5 registered for the LoRa device 2 linked to a respective associated port field value, FPort.

In various embodiments, the method 60 comprises:

- establishing a secure and authenticated session to the at least one application server 5, and

- verifying identity of the application server 5 using information in a context stored for the LoRa device 2.

An example of such establishing and verifying has been described earlier, e.g. in relation to figure 2 (box B8). The ABS 7 may also store the identity (e.g. public key from cert, or hash of public key) and/or certificate of the network controller 4. This is advantageous, since no other network controller can request the network session key of the LoRa device 2 from the ABS 7.

In various embodiments, the method 60 comprises deriving an application server specific key, AppSKey, for the application server 5.

The authentication and bootstrapping server 7 comprises processing circuitry 70, which may be any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 71, e.g. in the form of a storage medium 71. The processing circuitry 70 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

The processing circuitry 70 is configured to cause the ABS 7 to perform a set of operations, or steps, e.g. as described in relation to one or more of figures 2, 3 and 8. For example, the storage medium 71 may store the set of operations, and the processing circuitry 70 may be configured to retrieve the set of operations from the storage medium 71 to cause the ABS 7 to perform the set of operations. The set of operations may be provided as a set of executable instructions. The processing circuitry 70 is thereby arranged to execute methods as disclosed herein.

The ABS 7 may also comprise or otherwise have access to a storage or database 75 for storing various information, such as, for instance, on the network controller 4 (e.g. network controller identity) and any other information.

The ABS 7 also comprises an input/output means 73 (denoted I/O) for

communicating wirelessly and/or in a wired manned with other entities and devices. The input/output means 73 may, for instance, comprise a protocol stack, for communication with other network nodes in a wired manner and/or with

communication devices in a wireless manner. The input/output means 73 may be used for receiving data input and for outputting data, e.g. conveying IP packets. The ABS 7 may comprise receiving circuitry and transmitting circuitry. An authentication and bootstrapping server 7 is provided for authenticating a join request message for a long range radio, LoRa, device 2. The authentication and bootstrapping server 7 is configured to:

- receive, from a network controller 4 of a LoRa network 9, a join request message relating to the LoRa device 2, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr,

- request, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database 8,

- receive in response, from the subscriber database 8, the authentication vector, AppKey, and information on at least one application server 5 providing a service requested in the join request message,

- verify the join request message based on the received authentication vector,

AppKey, and

- send, to the network controller 4, a generated join accept message in response to the join request message.

The ABS 7 may be configured to perform the above steps, and implement any of the described embodiments of e.g. the method 60, e.g. by comprising one or more processors 70 (or processing circuitry) and memory 71, the memory 71 containing instructions executable by the processor 70, whereby the ABS 7 is operative to perform the steps.

In an embodiment thus, an ABS 7 is provided, for authentication of a join request message of a LoRa device 2. The ABS 7 comprises one or more processors 70 and memory 71, the memory 71 containing instructions executable by the processor 70, whereby the ABS 7 is operative to: receive, from a network controller of a LoRa network, a join request message relating to the LoRa device, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr, request, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database, receive in response, from the subscriber database, the authentication vector, AppKey, and information on at least one application server providing a service requested in the join request message, verify the join request message based on the received authentication vector, AppKey, and send, to the network controller, a generated join accept message in response to the join request message.

In an embodiment, the ABS 7 is configured to store one or more of the authentication vector, AppKey, and an identity of the network controller 4. As noted earlier, the AppKey may be used for generating NwkSKey and AppSKey, and the network controller identity may be used for verifying the network controller during key requests.

In various embodiments, the ABS 7 is configured to create a context for the LoRa device 2 and storing at least the authentication vector, AppKey, and the received information on the at least one application server 5.

In various embodiments, the ABS 7 is configured to store information for all application servers 5 registered for the LoRa device 2 linked to a respective associated port field value, FPort.

In various embodiments, the ABS 7 is configured to:

- establish a secure and authenticated session to the at least one application server 5, and

- verify identity of the application server 5 using information in a context stored for the LoRa device 2.

In various embodiments, the ABS 7 is configured to derive an application server specific key, AppSKey, for the application server 5.

Figure 9 illustrates an authentication and bootstrapping server comprising function modules/software modules for implementing methods of the present disclosure. The function modules can be implemented using software instructions such as computer program executing in a processor and/or using hardware, such as application specific integrated circuits (ASICs), field programmable gate arrays, discrete logical components etc., and any combination thereof. Processing circuitry may be provided, which may be adaptable and in particular adapted to perform any of the steps of the method 60 that has been described in various embodiments.

An authentication and bootstrapping server 7 is provided for authenticating a joint request message for a long range radio, LoRa, device 2. The ABS 7 comprises a first module 8i for receiving, from a network controller of a LoRa network, a join request message relating to the LoRa device, the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr. Such first module 8i may, for instance, comprise processing circuitry adapted to receive join request messages.

The ABS 7 comprises a second module 82 for requesting, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database. Such second module 82 may, for instance, comprise processing circuitry adapted for requesting such information.

The ABS 7 comprises a third module 83 for receiving in response, from the subscriber database, the authentication vector, AppKey, and information on at least one application server providing a service requested in the join request message. Such third module 83 may, for instance, comprise processing circuitry adapted for receiving such information.

The ABS 7 comprises a fourth module 84 for verifying the join request message based on the received authentication vector, AppKey. The fourth module 84 may, for instance, comprise processing circuitry adapted to verify join accept messages.

The ABS 7 comprises a fifth module 85 for sending, to the network controller, a generated join accept message in response to the join request message. The fifth module 85 may, for instance, comprise processing circuitry adapted to send join accept messages generated by the ABS 7. The fifth module 85 may, as a particular example, comprise transmitting circuitry.

It is noted that one or more of the modules 81, 82, 83, 84, 85 may be replaced by units.

Figure 10 illustrates a flow chart over steps of a method in an application server in accordance with the present disclosure.

A method 90 of providing services to a long range radio, LoRa, device 2 is provided. The method 90 is performed in an application server 5, which may be a software framework that provides e.g. web applications and a server environment to run them.

The method 90 comprises: - receiving 91, from a LoRa network controller 4, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server 7, ABS, and

- identifying 92 the ABS 7 based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS 7.

In an embodiment, the method 90 comprises:

- establishing a secure and authenticated session to the ABS 7, and

- requesting, from the ABS 7, an application specific key, AppSKey for use in decrypting a payload message from the LoRa device 2. The request is made based on the DevAddr, so that the ABS 7 is able to find applicable context for use in deriving the AppSKey.

The application server 5 comprises processing circuitry 120, which may be any combination of one or more of a suitable central processing unit (CPU),

multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 121, e.g. in the form of a storage medium 121. The processing circuitry 120 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

The processing circuitry 120 is configured to cause the application server 5 to perform a set of operations, or steps, e.g. as described in relation to one or more of figures 2, 3 and 11. For example, the storage medium 121 may store the set of operations, and the processing circuitry 120 may be configured to retrieve the set of operations from the storage medium 121 to cause the application server 5 to perform the set of operations. The set of operations may be provided as a set of executable instructions. The processing circuitry 120 is thereby arranged to execute methods as disclosed herein.

The application server 5 also comprises an input/output means 123 (denoted I/O) for communication with other entities and devices. The input/output means 73 may, for instance, comprise a protocol stack, for communication with other network nodes in a wired manner and/or with communication devices in a wireless manner. An application server 5 for providing services to a long range radio, LoRa, device 2 is provided. The application server 5 is configured to:

- receive, from a LoRa network controller 4, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server 7, ABS, and

- identify the ABS 7 based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS 7.

The application server 5 may be configured to perform the above steps, and implement any of the described embodiments of e.g. the method 90, e.g. by comprising one or more processors 120 (or processing circuitry) and memory 121, the memory 121 containing instructions executable by the processor 120, whereby the application server 5 is operative to perform the steps.

In an embodiment thus, an application server 5 is provided, for providing services to a long range radio, LoRa, device 2. The application server 5 comprises one or more processors 120 and memory 121, the memory 121 containing instructions executable by the processor 120, whereby the application server 5 is operative to: receive, from a LoRa network controller, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server, ABS, and identify the ABS based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS.

In an embodiment, the application server 5 is configured to:

- establish a secure and authenticated session to the ABS 7, and

- request, from the ABS 7, an application specific key, AppSKey for use in decrypting a payload message from the LoRa device 2.

Figure 12 illustrates an application server comprising function modules/software modules for implementing methods of the present disclosure. The function modules can be implemented using software instructions such as computer program executing in a processor and/or using hardware, such as application specific integrated circuits (ASICs), field programmable gate arrays, discrete logical components etc., and any combination thereof. Processing circuitry may be provided, which may be adaptable and in particular adapted to perform any of the steps of the method 90 that has been described in various embodiments.

An application server 5 is provided for providing services to a long range radio, LoRa, device 2.

The application server 5 comprises a first module 131 for receiving, from a LoRa network controller 4, a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server 7, ABS. Such first module 131 may, for instance, comprise processing circuitry adapted to receive modified session identifiers.

The application server 5 comprises a second module 132 for identifying the ABS 7 based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS 7. Such second module 132 may, for instance, comprise processing circuitry adapted for performing such identifying.

The invention has mainly been described herein with reference to a few

embodiments. However, as is appreciated by a person skilled in the art, other embodiments than the particular ones disclosed herein are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

1. A method (30) of authentication of a long range radio, LoRa, device (2), the method (30) being performed by a LoRa network controller (4), the method (30) comprising:

- receiving (31), from the LoRa device (2), a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device (2),

- obtaining (32), based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server (7), ABS, for use in authenticating the received join request message,

- obtaining (33) a verified join accept message from the ABS (7), the ABS (7) being identified based on the obtained information on the ABS (7), and

- forwarding (34) the verified join accept message to the LoRa device (2), enabling the LoRa device (2) to derive a network session key, NwkSKey, and an application session key, AppSKey.

2. The method (30) as claimed in claim 1, comprising, upon obtaining (32) the information on the ABS (7), generating LoRa parameters for the LoRa device (2) and storing these in a Join context together with the obtained information on the ABS and the unique device identifier, DevEUI, of the LoRa device (2).

3. The method (30) as claimed in claim 1 or 2, comprising, upon obtaining (32) the information on the authentication and bootstrapping server (7), storing the application identifier, AppEUI, linked to the obtained information.

4. The method (30) as claimed in any of claims 1-3, wherein the obtaining (32) comprises:

- querying a lookup service (12) for the information on the authentication and bootstrapping server (7) by using one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, as key, and

- receiving in response the information on the authentication and bootstrapping server (7).

5. The method (30) as claimed in any of claims 1-3, wherein the obtaining (32) comprises fetching, from a storage (44), the information on the authentication and bootstrapping server (7) by using one or both of the received application identifier, AppEUI and the unique identifier, DevEUI,.

6. The method (30) as claimed in any of the preceding claims, comprising:

- receiving, from the LoRa device (2), a payload message comprising a session identifier, DevAddr, for the LoRa device (2),

- obtaining a device context based on the session identifier, DevAddr,

- modifying the session identifier, DevAddr, such as to include a pointer to the ABS (7), and

- creating a key request message using the modified identifier.

7. The method (30) as claimed in claim 6, comprising:

- sending the key request message to the ABS (7),

- receiving in response, from the ABS (7), a network session key, NwkSKey, and any relevant application server (5) information,

- verifying network level security of the payload message,

- sending the packet to the identified application server (5).

8. A computer program (42) for a network controller (4), the computer program (42) comprising computer program code, which, when run on at processing circuitry of the network controller (4) causes the network controller (4) to perform the method (30) according to any of claims 1-7.

9. A computer program product (41) comprising a computer program (42) as claimed in claim 8 and a computer readable means on which the computer program (42) is stored.

10. Along range radio, LoRa, network controller (4) for authentication of a LoRa device (2), the LoRa network controller (4) being configured to:

- receive, from the LoRa device (2), a join request message comprising at least an application identifier, AppEUI, and a unique identifier, DevEUI, of the LoRa device (2),

- obtain, based on one or both of the application identifier, AppEUI, and the unique identifier, DevEUI, information on an authentication and bootstrapping server (7), ABS, for use in authenticating the received join request message,

- obtain a verified join accept message from the ABS (7), the ABS (7) being identified based on the obtained information on the ABS (7), and

- forward the verified join accept message to the LoRa device (2), enabling the LoRa device (2) to derive a network session key, NwkSKey, and an application session key, AppSKey.

11. The LoRa network controller (4) as claimed in claim 10, configured to, upon obtaining the information on the ABS (7), generate LoRa parameters for the LoRa device (2) and store these in a Join context together with the obtained information on the ABS and the unique device identifier, DevEUI, of the LoRa device (2).

12. The LoRa network controller (4) as claimed in claim 10 or 11, configured to, upon obtaining the information on the authentication and bootstrapping server (7), store the application identifier, AppEUI, linked to the obtained information.

13. The LoRa network controller (4) as claimed in any of claims 10-12, configured to obtain by:

- querying a lookup service (12) for the information on the authentication and bootstrapping server (7) by using one or both of the application identifier, AppEUI and the unique identifier, DevEUI, as key, and

14. The LoRa network controller (4) as claimed in any of claims 10-12, configured to obtain by fetching, from a storage (44), the information on the authentication and bootstrapping server (7) by using one or both of the received application identifier, AppEUI and the unique identifier, DevEUI.

15. The LoRa network controller (4) as claimed in any claims 10-14, configured to:

- receive, from the LoRa device (2), a payload message comprising a session identifier, DevAddr, for the LoRa device (2),

- obtain a device context based on the session identifier, DevAddr,

- modify the session identifier, DevAddr, such as to include a pointer to the ABS (7), and

- create a key request message using the modified identifier.

16. The LoRa network controller (4) claimed in claim 15, configured to:

- send the key request message to the ABS (7),

- receive in response, from the ABS (7), a network session key, NwkSKey, and any relevant application server (5) information,

- verify network level security of the payload message,

- generate a packet comprising the payload of the payload message and the modified identifier, and

- send the packet to the identified application server (5).

17. A method (60) of authenticating a join request message for a long range radio, LoRa, device (2), the method (60) being performed by an authentication and bootstrapping server (7) and comprising:

- receiving (61), from a network controller (4) of a LoRa network (9), a join request message relating to the LoRa device (2), the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr,

- requesting (62), based on the unique device identifier, DevEUI, an authentication vector from a subscriber database (8), - receiving (63) in response, from the subscriber database (8), the authentication vector, AppKey, and information on at least one application server (5) providing a service requested in the join request message,

- verifying (64) the join request message based on the received authentication vector, AppKey, and

- sending (65), to the network controller (4), a generated join accept message in response to the join request message.

18. The method (60) as claimed in claim 17, comprising storing one or more of the authentication vector, AppKey, and an identity of the network controller (4).

19. The method (60) as claimed in claim 17 or 18, comprising creating a context for the LoRa device (2) and storing at least the authentication vector, AppKey, and the received information on the at least one application server (5).

20. The method (60) as claimed in any of claims 17-19, comprising storing

information for all application servers (5) registered for the LoRa device (2) linked to a respective associated port field value, FPort.

21. The method (60) as claimed in any of claims 17-20, comprising:

- establishing a secure and authenticated session to the at least one application server (5), and

- verifying identity of the application server (5) using information in a context stored for the LoRa device (2).

22. The method (60) as claimed in any of claims 17-21, comprising deriving an application server specific key, AppSKey, for the application server (5).

23. A computer program (72) for an authentication and bootstrapping server (7), the computer program (72) comprising computer program code, which, when run on at processing circuitry of the authentication and bootstrapping server (7) causes the authentication and bootstrapping server (7) to perform the method (60) according to any of claims 17-22.

24. A computer program product (71) comprising a computer program (72) as claimed in claim 23 and a computer readable means on which the computer program (72) is stored.

25. An authentication and bootstrapping server (7) for authenticating a join request message for a long range radio, LoRa, device (2), the authentication and

bootstrapping server (7) being configured to:

- receive, from a network controller (4) of a LoRa network (9), a join request message relating to the LoRa device (2), the join request message comprising a unique device identifier, DevEUI, and a session identifier DevAddr,

- request, based on the unique device identifier, DevEUI, an authentication vector from a subscriber database (8),

- receive in response, from the subscriber database (8), the authentication vector, AppKey, and information on at least one application server (5) providing a service requested in the join request message,

- verify the join request message based on the received authentication vector, AppKey, and

- send, to the network controller (4), a generated join accept message in response to the join request message.

26. The authentication and bootstrapping server (7) as claimed in claim 17, configured to store one or more of the authentication vector, AppKey, and an identity of the network controller (4).

27. The authentication and bootstrapping server (7) as claimed in claim 25 or 26, configured to create a context for the LoRa device (2) and storing at least the authentication vector, AppKey, and the received information on the at least one application server (5).

28. The authentication and bootstrapping server (7) as claimed in any of claims 25- 27, configured to store information for all application servers (5) registered for the LoRa device (2) linked to a respective associated port field value, FPort.

29. The authentication and bootstrapping server (7) as claimed in any of claims 25-

28, configured to:

- establish a secure and authenticated session to the at least one application server (5), and

- verify identity of the application server (5) using information in a context stored for the LoRa device (2).

30. The authentication and bootstrapping server (7) as claimed in any of claims 25-

29, configured to derive an application server specific key, AppSKey, for the application server (5).

31. A method (90) of providing services to a long range radio, LoRa, device (2), the method (90) being performed in an application server (5) and comprising:

- receiving (91), from a LoRa network controller (4), a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server (7), ABS, and

- identifying (92) the ABS (7) based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS (7).

32. The method (90) as claimed in claim 31, comprising:

- establishing a secure and authenticated session to the ABS (7), and

- requesting, from the ABS (7), an application specific key, AppSKey for use in decrypting a payload message from the LoRa device (2).

33. A computer program (122) for an application server (5), the computer program (122) comprising computer program code, which, when run on at processing circuitry of the application server (5) causes the application server (5) to perform the method (90) according to claim 31 or 32.

34. A computer program product (121) comprising a computer program (122) as claimed in claim 33 and a computer readable means on which the computer program (122) is stored.

35. An application server (5) for providing services to a long range radio, LoRa, device (2), the application server (5) being configured to:

- receive, from a LoRa network controller (4), a modified session identifier, DevAddr, for identifying an authentication and bootstrapping server (7), ABS, and

- identify the ABS (7) based on the received modified session identifier, DevAddr, the modified session identifier, DevAddr, comprising a pointer to the ABS (7).

36. The application server (5) as claimed in claim 35, configured to:

- establish a secure and authenticated session to the ABS (7), and

- request, from the ABS (7), an application specific key, AppSKey for use in

decrypting a payload message from the LoRa device (2).