WO2022013601A1 - Provisioning drone flight in 5g networks - Google Patents

Abstract

Techniques and apparatus for provisioning drone flights in 5G networks. An example method for registering a flight certificate, in one or more network nodes acting as an application function, comprises obtaining (1010) a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone, and sending (1020), to a network exposure function in a telecommunications network, for registration in the network, drone flight information comprising at least the communication identifier and the flight certificate. Other techniques and apparatus include techniques for establishing packet data unit, PDU, sessions for drones and techniques for disconnecting and diverting drone flights.

Description

PROVISIONING DRONE FLIGHT IN 5G NETWORKS TECHNICAL FIELD The present disclosure is generally related to wireless communications networks and is more particularly related to the registration and handling of credentials associated with drone flights, including flight certificates, by wireless communications networks. BACKGROUND The concept of “exposure” is expected to be increasingly important in the 5^th-generation (5G) wireless networks under development by members of the 3^rd-Generation Partnership Project (3GPP). Network exposure functions (NEFs) and service capability exposure functions (SCEFs) deployed by 5G network operators allow application service providers operating outside the 5G wireless network itself to enhance their applications by accessing wireless network capabilities. An NEF acts as a service-aware gateway that allows application servers (ASs) external to the network to communicate with 5G network functions in a secure manner, while the SCEF provides these ASs with access to information about network operations as well as the capability of communicating small amounts of data, e.g., data associated with internet-of-things (IoT) and machine-type-communications (MTC) devices, without the establishment of dedicated user plane connections. The SCEF exposes network services and capabilities to the ASs via a set of application programming interfaces (APIs) referred to as “Northbound APIs,” which are standardized in 3GPP TS 29.122, of which the most recent version is version 16.5.0 (March 2020). Figure 1 is an example view of the 5G reference architecture as defined by 3GPP, for a non-roaming scenario. For the purposes of the present disclosure, the relevant architectural aspects include: • the Application Function (AF); • the Network Exposure Function (NEF); • the Policy Control Function (PCF); • the Session Management Function (SMF); • the User Plane Function (UPF); and • the Application Function (AF). The Application Function (AF) interacts with the 3GPP Core Network, and specifically in the context of this IvD, to provision information to the network operator and to subscribe to certain events happening in operator´s network. The Network Exposure Function (NEF), as discussed briefly above, supports different functionality and acts as the entry point into an operator´s network, so an external application server interacts with the 3GPP Core Network through the NEF. The Policy Control Function (PCF) supports unified policy framework to govern the network behavior. Specifically, the PCF provides Policy and Charging Control (PCC) rules to the SMF. The Session Management function (SMF) supports different functionality, including the configuring of the UPF, e.g. for event reporting. The User Plane function (UPF) supports handling of user plane traffic based on the rules received from SMF. This handling may include deep packet inspection and different enforcement actions, e.g., event detection and reporting). Certain 3GPP procedures for the operation of wireless devices in 5G are relevant to the present disclosure, including authentication procedures for subscribing devices, and packet data unit (PDU) session establishment procedures. Parameters relevant to these procedures include the following: • A Subscription Permanent Identifier (SUPI) is a 5G globally unique identifier allocated to each subscriber and defined in 3GPP specification 3GPP TS 23.501. The SUPI value is provisioned in the subscribers Universal Subscriber Identity Module (USIM) and in the 5G Core’s Unified Data Management/Unified Data Repository (UDM/UDR) function. A Valid SUPI can be either an International Mobile Subscriber Identifier (IMSI), as defined in 3GPP TS 23.503 for 3GPP Radio Access Technologies (RATs), or a user identification based on Network Access Identifier (NAI), as defined in RFC 4282, for non-3GPP RATs. A SUPI is usually a string of 15 decimal digits. The first three digits represent the Mobile Country Code (MCC) while the next two or three form the Mobile Network Code (MNC) identifying the network operator. The remaining (nine or ten) digits are known as Mobile Subscriber Identification Number (MSIN) and represent the individual user of that particular operator. SUPI is equivalent to the IMSI which uniquely identifies the mobile equipment (ME) and which is also a string of 15 digits • Subscription Concealed Identifier (SUCI) is a privacy-preserving identifier containing a concealed version of the SUPI. The UE generates a SUCI using a ECIES-based protection scheme with the public key of the Home Network that was securely provisioned to the USIM during the USIM registration. Only the MSIN part of the SUPI gets concealed by the protection scheme while the home network identifier i.e. MCC/MNC gets transmitted in plain-text. The data fields constituting the SUCI include the SUPI Type field, which contains a value in the range 0 to 7 and which identifies the type of the SUPI concealed in the SUCI. So far only types 0, for IMSI, and 1, for NAI, are defined; values 2 to 7 are reserved for future use. The SUCI also carries the Home Network Identifier, identifying the home network of the subscriber. When the SUPI Type is an IMSI, the Home Network Identifier is composed of MCC and MNC. When the SUPI type is a Network Access Identifier, the Home Network Identifier consists of a string of characters with a variable length representing a domain name. The SUCI also includes a Routing Indicator, which is 1 to 4 decimal digits assigned by the home network operator and provisioned within the USIM, as well as a Protection Scheme Identifier, which is a value in the range of 0 to 15, represented with 4 bits. The SUCI also includes the Home Network Public Key Identifier, which is a value in the range 0 to 255 and represents a public key provisioned by the HPLMN and it is used to identify the key used for SUPI protection, and a protection scheme output, which is a string of characters with a variable length or hexadecimal digits, and which is dependent on the used protection scheme. Authentication procedures for subscribers in 5G network are defined in 3GPP TS 33.501, v.16.1.0 (December 2019). Figure 2 illustrates the initiation of an authentication procedure by a user equipment (UE), which may be any wireless device seeking access to the services provided by the network, and the selection of authentication method by the network. Network functions involved in these procedures are the Security Anchor Function (SEAF), the Authentication Server Function (AUSF), and the Unified Data Management (UDM), Authentication Repository and Processing Function (ARPF), and Subscriber Identification De-concealing Function (SIDF) services in the 5G network. Each of these functions and services may be implemented on one or across several physical nodes in the 5G network; multiple functions or portions of these functions may be performed on the same or an overlapping set of physical nodes, in some instances. As shown in Figure 2, the authentication procedure begins with the UE sending an N1 message to the SEAF, via the Radio Access Network (RAN), which is not pictured. This N1 message includes a Subscription Concealed Identifier (SUCI) for the UE or a 5G globally unique temporary identity (5G-GUTI) for the UE. Both of these are intended to keep the subscriber’s actual identity confidential from outside observers during the procedures. As further seen in Figure 2, the SEAF then sends an authentication request to the AUSF, with this authentication request including the SUCI or a Subscription Permanent Identifier (SUPI) for the UE (retrieved by the AUSF using the 5G-GUTI), along with a serving network name (SN-name). The AUSF forwards this to the UDM which, using the ARPF and SIDF, performs de-concealment of the SUCI, if applicable, to obtain the SUPI, and selects an authentication method. Figure 3 illustrates steps in an example authentication procedure according to so-called EAP-AKA’ variant of the Extensible Authentication Protocol Authentication and Key Agreement method defined in RFC 5448. This procedure, like the procedure shown in Figure 2, utilizes the SUCI or SUCI, and requires the UE to calculate an authentication response that proves its identity to the AUSF, which indicates the success of the authentication procedure to the SEAF. Other 5G procedures that are relevant to the present disclosure include the packet data unit (PDU) session establishment procedure, as standardized in 3GPP TS 23.502, v.16.4.0. Figure 4 illustrates an example UE-requested PDU session establishment procedure, details of which can be found in Section 4.3.2.2.1 of 3GPP TS 23.502. SUMMARY The use and capabilities of remotely piloted drone aircraft are rapidly increasing. These drones will often be equipped with 5G communications capabilities, such that a drone’s operator will require network operators to provide radio coverage in the areas where the drone will fly. Depending on where the flights occur, some flights will need permission from a government agency, and drones will in many cases be restricted from specific areas. Currently, while network operators can provide required radio coverage for UEs carried by drones, the network operators do not check whether the UE (with its associated drone) is allowed to be in the areas where it has radio coverage. The network, however, is uniquely positioned to track and monitor the location of the UE-equipped drone, using the same tools and procedures it currently uses to track UEs on the ground. 5G networks can play key roles in provisioning and authenticating communications associated with flights, and in monitoring and enforcing flight restrictions. However, current mechanisms for authenticating UEs and provisioning UE mobility patterns are not sufficient to determine how UEs associated with drones should connect to and/or behave in the network. The various techniques and apparatuses described below address these problems. Various embodiments of these techniques: • enable the provisioning of parameters required to support a drone flight from an administrative point of view; • validate permissions corresponding to a flight, e.g., by validating government-supplied permissions and credentials for flying, whether in restricted areas or more generally; and • provide for administratively controlled re-routing or disconnection of flights, according to flight zone parameters, flight certificates, etc. An example method for registering a flight certificate according to some embodiments of these techniques may be carried out by a network node acting as an application function, and comprises the steps of obtaining a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone, and sending drone flight information comprising at least the communication identifier and the flight certificate to a network exposure function in a telecommunications network, for registration in the network. A corresponding example method in one or more network nodes acting as NEF for a telecommunications network comprises receiving, from network equipment associated with a drone operator, drone flight information comprising at least a communication identifier for a drone and a flight certificate associated with the communication identifier, and sending at least the flight certificate to a regulating authority, for validation. This example method further comprises receiving, from the regulating authority, an indication of whether the flight certificate is valid, and, responsive to receiving an indication that the flight certificate is valid, sending the flight certificate to a repository function for storage. An example method in a wireless device associated with a drone comprises sending, to a network node in a telecommunications network, a communication identifier associated with the wireless device and a flight certificate, and receiving, in response to said sending, an acknowledgment message. This example method may further comprise, subsequent to receiving the acknowledgement message, requesting establishment of a PDU session with the telecommunications network and receiving a PDU session establishment request response. Another example method in one or more network nodes acting as a NEF comprises receiving, from a regulatory authority, a request for drone identifier, where the request includes or is associated with one or more parameters, the one or more parameters comprising any one or more of a drone operator identifier, a flight certificate, an indicator of a flight area, and a flight certificate. This example method further comprises sending, in response to the request, at least one drone identifier corresponding to the one or more parameters. Further details and variations of all these methods are described below. Also described below are apparatuses adapted to and/or configured to carry out these methods. As discussed in more detail below, the various techniques provide for network-based authentication and authorization of drone flights. Other features and advantages of the presently disclosed invention will be apparent from the attached figures and the detailed description below. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates an example reference architecture for the 5G network. Figure 2 illustrates the initiation of an authentication procedure in 5G. Figure 3 shows an example authentication procedure in 5G networks. Figure 4 illustrates details of a UE-requested PDU session establishment procedure. Figure 5 is a flow chart illustrating steps that a network operator may take to validate a new drone flight. Figure 6 is a sequence diagram illustrating a technique for provisioning flight certificates. Figure 7 is a sequence diagram illustrating a technique for presenting flight certificates during a UE’s registration phase. Figure 8 illustrates the establishment of a PDU session by a drone. Figure 9 illustrates example procedures for disconnecting or diverting a drone flight. Figure 10 is a process flow diagram illustrating an example method carried out by a drone operator. Figure 11 is a process flow diagram illustrating an example method carried out by a network node, such as a network node acting as an NEF. Figure 12 illustrates an example method carried out by a wireless device. Figure 13 illustrates another example method carried out by a network node acting as an NEF. Figure 14 illustrates an example method carried out by a network node acting as an SEAF. Figure 15 shows an example method carried out by a network node acting as an AUSF. Figure 16 is a block diagram illustrating an example wireless device. Figure 17 is a block diagram illustrating an example network node. DETAILED DESCRIPTION Note that for the purposes of the present disclosure, the term “drone” should be understood broadly as referring to an unmanned aerial vehicle (UAV), and in particular to UAVs having onboard wireless communications functionality. As noted above, current mechanisms for authenticating UEs and provisioning UE mobility patterns are not sufficient to determine how UEs associated with drones should connect to and/or behave in the network. The various techniques and apparatuses described below address these problems. Various embodiments of these techniques: • enable the provisioning of parameters required to support a drone flight from an administrative point of view; • validate permissions corresponding to a flight, e.g., by validating government-supplied permissions and credentials for flying, whether in restricted areas or more generally; and • provide for administratively controlled re-routing or disconnection of flights, according to flight zone parameters, flight certificates, etc. The various techniques described below may use one or several of the following novel features: • an Nnef_ParameterProvision service extension with new parameters related to the certification information of the pilot and certification information for the flight, for those cases where it is needed; • new parameters in the authentication process of 5G for including certifications of the drone; and • new services for providing information about drones and performing some actions over them. Figure 5 shows a flow chart including steps that the network operator must check to validate a new flight, in an example procedure. The drone operator must provision the characteristics of the flight for those flights that need specific permissions, e.g., due to flight and/or drone characteristics. The network operation can then check whether the flight fulfills all the needed requirements before assigning radio resources. Figure 6 is a sequence diagram illustrating an example solution for provisioning flight certificates and, optionally, pilot certificates, for drone flights. This procedure may be enabled by extending the CPProvisioning API defined in 3GPP TS 29.122 or creating a new one (e.g., FlightProvisioningAPI). The steps shown in Figure 6, all of which are new compared to current procedures, are described below. Step 1 - In the event that the flight needs to be driven by a licensed pilot, the pilot requests for a certification of its pilot license. A governmental office or agency like EASA (Europe) or ENAIRE (Spain), for example, can provide this certification towards the pilot. This pilot certificate may take the form of an X509 certificate, for example. The United States government’s Federal Aviation Agency (FAA) provides the Integrated Airman Certification and Rating Application (IACRA), for instance, to provide digitally signed certificates for pilots. (See, e.g., iacra.faa.gov/IACRA/Default.aspx.) It will be appreciated that not all flights may need pilot certification, depending on local rules. Step 2 – When and where needed, the pilot presents this certification to the Drone Operator. Note that the term “Drone Operator” is used here to refer to any entity, whether an individual, a business, or a government agency, that has total or partial responsibility for a given drone flight. Some or all of the operations attributed in this document to a “Drone Operator” may be performed by a third party on behalf of the drone owner, in some embodiments, or by the drone owner. Step 3 – The Drone Operator requests a flight permission towards the government, via an appropriate government agency interface, here represented by the box labeled “Air Regulator.” As discussed above, a drone’s flight may need specific permissions, depending on the flight and/or drone characteristics. In the event that a pilot certificate is required, it is presented towards the corresponding authority along with the request for flight permission. The Drone Operator will generally be required to provide certain information, which may vary depending on the regulating authority. Non-limiting examples include any of the following: • a drone identifier (ID), e.g., the IMSI (4G) or SUPI of the drone that is going to fly using mobile networks; • drone characteristics: weight, maximum speed, camera type (if it is video HD, standard video, only audio, etc.), etc.; • flight characteristics, such as type of flight (VLOS, BVLOS, etc.), time of day, area of the flight, etc.; and • the pilot certificate for those cases where it is needed. Step 4 – In response, to the request, the government air regulator expends a certificate for this flight, e.g., after checking the pilot certificate and/or the other information provided by the Drone Operator. The issued fight certificate may be bound to the drone ID. The flight certificate identifies the flight univocally. Like other certificates, the flight certificate can be revoked by air regulator if needed. It is suggested to use X.509 certificates, but others can be employed too. Step 5 – The Drone Operator, acting as an external application function (AF) and using an extended CP Parameter Provisioning API, submits the issued flight certificate to the wireless network’s Network Exposure Function (NEF). It includes some or all of the following: • Drone-Id: identifier of the drone. This may be the SUPI or IMSI of a wireless device in or coupled to the drone. • Drone Operator: owner of the drone flight. • Flight certificate: certificate of the flight given by the air regulator. • Pilot certificate: certificate of the pilot given by the air regulator. This is optional, in the event that it is needed, e.g., according to the flight characteristics. • Flight Area: area of the flight or a flight route. • Optionally, other characteristics of the flight such as a time of day for the flight. This is optional, due to the fact that certificates can have a validation period. Step 6 – The network exposure function (NEF) sends the main characteristics of the flight to be checked towards the air regulator. The NEF may send some or all of the following information: • Drone-Id: The NEF provides the IMSI (4G) or SUPI of the drone that is going to fly while using mobile network(s). • Flight Certificate • Pilot Certificate, if needed it presents the pilot certificate • Flight Area: Area and/or route of the flight • Optionally, the NEF may include other characteristics of the flight like time of day, the date of the flight, equipment onboard the drone, etc. Step 7 – The air regulator answers (successful response acknowledging the request). The response may include the flight area and optionally the time of day to the operator when it is needed to be checked. Step 8 – Alternatively, the air regulator returns a message indicating a failure, i.e., that something has gone wrong with the checking of the flight information and/or certificate. This response may indicate a possible cause of the failure, such as: • Invalid flight certificate • Invalid pilot certificate • Invalid area Step 9 – If the validation of the flight request in steps 6 and 7 is successful, the NEF stores, in the ARPF, the certificates of the pilot and the flight. Step 10 – The ARPF responds by acknowledging the storage request and indicating that it was successful. Similar steps to some of those shown in Figure 6 can be used by an air regulator to revoke those certificates that are not valid including those certificates that are not valid towards the operator. Figure 7 illustrates an example procedure whereby the UE in the drone presents a certificate for the flight and, optionally, a certificate for the pilot, during or in association with the UE registering with the network. Once an authentication procedure has been carried out, e.g., according to the 5G authentication procedure illustrated in Figure 2, the new procedure shown in Figure 7 is performed. Following are details of this procedure. Step 1 – The UE, using the SUCI as identifier, for example, sends the flight certificate and the pilot certificate (if needed) towards the SEAF. Note that in the procedure shown in Figure 6, the UE was provisioned with the Drone-Id, which in the case of 5G is the SUPI. The SUCI is an encrypted version of the SUPI. Before this procedure is carried out, the certificates have been provisioned in the drone/UE by the drone operator. The certificates have been provisioned in the network by the drone operator as discussed above, e.g., using the procedure shown in Figure 6. Step 2 – Using the Nausf_Authentication_Authenticate_request, the SEAF sends the certificate information towards AUSF. This may include the flight certificate and the pilot certificate (if needed) obtained in the previous step. Step 3 – The AUSF checks the received certificates against the certificates provisioned previously in the ARPF. (See Figure 6, step 9.) To do so, the AUSF sends the flight certificate and the pilot certificate (if needed) received from the SEAF towards the ARPF Step 4 – The ARPF validates the certificates and sends a message confirming the validation. Step 5 – The AUSF sends the validation towards SEAF. Step 6 - The SEAF sends this information to the UE. Once the UE is registered with the corresponding certificates, the UE requests a PDU Session Establishment, e.g., according to the procedure shown in Figure 8. This is analogous to the PDU session establishment procedure discussed above and illustrated in Figure 4. The steps in the PDU session establishment procedure shown in Figure 8 include the following. Step 1 – The end user, in this case a UE aboard a drone, sends a Session Establishment Request to the network, with this request including the certificates of the flight and optionally of the pilot. As was the case in the procedure shown in Figure 7, the drone-Id is the SUCI. Step 2 – The AMF selects a SMF. The AMF sends a Session Create message towards the selected SMF. The AMF sends the certificates it received in the previous step. Step 3 – The SMF registers to the UDM. It includes the certification information of the pilot and the flight. The SMF sends the certificates of the previous step. Step 4 – The UDM answers the SMF. The UDM checks the SUCI and the certificates and allows or not the drone (UE) to have a PDU Session Establishment. Step 5 – The SMF asks for a subscription profile for this Drone-Id (identifies by the SUPI or SUCI) and including the flight and pilot (optional) certificates. Step 6 – The UDM answers with the subscription profile that includes the area of the flight and the time of day, if needed. Step 7 – The SMF selects a PCF and establishes a connection. Step 8 – The PCF responds to the SMF. The PCF tracks information regarding the areas of the flight registration, for example. It may do so using the Location-Report event of Namf_EventExposure Service defined in 3GPP TS 29.518, for example. The PCF can enforce policies according to the location of the flight and/or the time of day. For instance, if the area of the flight is not allowed, e.g., for a particular time of day, the PCF might trigger a PDU session release (as in step 5 of Figure 9, discussed below), or inform the NEF and/or air regulator that the flight is out of bounds, after which the air regulator might force a PDU session release, as in Figure 9. Step 9 – The SMF, based on any of various criteria, selects the best UPF for this subscriber. The SMF establishes a connection to the selected UPF. Step 10 – The UPF answers to the SMF. Step 11 – The SMF answers to the AMF. Step 12 – The AMF answers to the UE. As of this moment, the UE has a PDU session established. The techniques and procedures described above facilitate the use of other procedures, to manage flights. For example, Figure 9 illustrates an example procedure whereby an air regulator requests an interception of a drone, so that the flight can be diverted or discontinued. This example includes the following steps. Step 1 – The air regulator asks for one or more drone-Ids, corresponding to one or more respective flights. This request may utilize one or several of the following parameters: • a specific flight zone; • a pilot certificate; • a drone operator; • a flight certificate. Step 2 - The NEF provides a list of drones that fulfills the query requested in step 1. Step 3 – The air regulator requests the NEF to perform an action towards a list of drone- ids. That action may be a drone disconnection or flight deviation, for example, but other actions can be provisioned. Step 4 – In the event that a disconnect action is requested by the air regulator, the NEF informs the drone operator that a disconnection request has been submitted for the drone-id. The information provided to the drone operator may specify the air regulator as the cause/reason for the disconnection. Step 5 - The NEF sends a PDU Session Release message to the PCF, including the drone- ID/UE ID. The PCF will release the PDU session according to the procedure defined in 3GPP TS 23.502, section 4.3.4 (Pdu Session Release). Step 6 - In the event that a flight deviation is requested by the air regulator, the NEF informs to the drone operator that a divert request has been requested for the drone-id, including Air Regulator as the cause reason. Then, the drone operator must divert the flight. Step 7 – The NEF answers to the air regulator, indicating the result of the actions requested by the air regulator in Step 3. As noted above, the air regulator can revoke those certificates that are not valid. The procedure shown in Figure 9 can be used, for example, after checking those certificates that are not valid and intercepting or diverting those flights for which it has revoked certificates. In view of the example techniques and procedures described above, it will be appreciated that Figure 10 illustrates an example method for registering a flight certificate, in network equipment acting as an application function (AF), e.g., as operated by or for a drone operator. Note that the method shown in Figure 10 may be understood as a generalization of some of the steps in the certificate provisioning procedure illustrated in Figure 6. Where different terms are used in the following description for items or data elements that are similar to those used in the above discussion of Figure 6, it should be understood that the terms are interchangeable or that the more general term includes the other, where appropriate. The method shown in Figure 10 includes, as shown at block 1010, the step of obtaining a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone. As shown at block 1020, the method further includes the step of sending drone flight information comprising at least the communication identifier and the flight certificate to a network exposure function in a telecommunications network, for registration in the network. As was discussed above, the communication identifier may be an IMSI or a SUPI, in various embodiments. The flight certificate may take the form of an X.509 certificate, for example, but other certificates formats are possible. Subscription Permanent Identifier, SUPI. In some embodiments, obtaining the flight certificate, as illustrated generally at block 1010, includes sending flight information to the regulating authority, where the flight information comprises the communication identifier for the drone and flight characteristics for a flight. These flight characteristics may include one or more of any one or more of the following: a type of flight; a time of day for the flight; and a flight path or flight area. In some embodiments, the flight information may further comprise one or more drone characteristics, such as any of a drone type; a drone weight; a drone maximum speed; a camera type and/or camera parameter for a camera carried by the drone; and a parameter for an audio recorder carried by the drone. In some embodiments, the flight information sent to the regulating authority may comprise a pilot certificate. This may be required in some jurisdictions. Figure 11 illustrates a corresponding method carried out in network equipment acting as an NEF for a telecommunications network. Again, the method shown in Figure 11 may be understood as a generalization of some of the steps in the certificate provisioning procedure illustrated in Figure 6. Once more, where different terms are used in the following description for items or data elements that are similar to those used in the above discussion of Figure 6, it should be understood that the terms are interchangeable or that the more general term includes the other, where appropriate. As shown at block 1110, this example method includes the step of receiving, from network equipment associated with a drone operator, drone flight information comprising at least a communication identifier for a drone and a flight certificate associated with the communication identifier. The method further comprises the step of sending at least the flight certificate to a regulating authority, for validation, as shown at block 1120. As shown at block 1130, the method further includes receiving, from the regulating authority, an indication of whether the flight certificate is valid. In response to receiving an indication that the flight certificate is valid, the flight certificate is then sent to a repository function for storage, as shown at block 1140. Once again, the communication identifier may be an IMSI or a SUPI, in various embodiments. In some embodiments, the flight certificate is an X.509 certificate. Again, the flight information may further comprise flight characteristics for a flight, in some embodiments, the flight characteristics comprising one or more of any of a type of flight, a time of day for the flight, and a flight path or flight area. In these embodiments, the method may comprise sending the flight characteristics to the regulating authority with the flight certificate. Likewise, in some embodiments the flight information may further comprise a pilot certificate, in which case the pilot certificate may be sent to the regulating authority along with the flight certificate. Figure 12 illustrates an example method carried out in a wireless device, e.g., a UE, associated with a drone. This method involves registering the drone’s flight certificate with the network, for authentication, and may be understood as a generalization of at least some of the steps of the procedure shown in Figure 7. The terms used in the following description should be understood as commensurate with or comprehending any different terms used in the description of Figure 7 to describe similar things. As shown at block 1210, the method of Figure 12 includes the step of sending, to a network node in a telecommunications network, a communication identifier associated with the wireless device and the flight certificate. The network node may be an SEAF, for example, as shown in Figure 7. As with the other methods discussed above, the flight certificate may be an X.509 certificate, in some embodiments. As shown at block 1220, the wireless device receives an acknowledgment message, in response. In some embodiments, the communication identifier may be a Subscription Concealed Identifier. The network node to which the flight certificate and communication identifier are sent may be an SEAF in the telecommunications network, in some embodiments. In some embodiments, the method may comprise sending a pilot certificate to the network node along with the flight certificate. After receiving the acknowledgment message, the wireless device may continue by requesting establishment of a protocol data unit, PDU, session with the telecommunications network, in some instances or embodiments. This is shown at block 1230. As shown at block 1240, the method may further comprise receiving a PDU session establishment request response. Requesting the PDU session may comprise sending, to an AMF in the telecommunications network, a communication identifier for the wireless device and the flight certificate. The communication identifier here may be a SUPI or a SUCI, in various embodiments. The wireless device may send a pilot certificate to the AMF along with the flight certificate, in some embodiments. Figure 13 illustrates a method, in network equipment acting as a NEF for a telecommunications network, for facilitating actions taken by a regulatory authority with respect to active drone flights. This method may be understood as corresponding to at least parts of the procedure illustrated in Figure 9, and the same caveat with respect to different terms for similar items given above applies. The method shown in Figure 13 begins with receiving, from a regulatory authority, a request for drone identifier, as shown at block 1310. This request includes or is associated with one or more parameters, the one or more parameters comprising any one or more of a drone operator identifier, a flight certificate, an indicator of a flight area, and a flight certificate. The method continues, as shown at block 1320, with sending, in response to the request, at least one drone identifier corresponding to the one or more parameters. The illustrated method further comprises, as shown at block 1330, the step of receiving, from the regulatory authority, a request to intercept a drone, the request to intercept a drone comprising at least one drone identifier and an indication of an action. The indication of an action may indicate one of disconnecting the drone and diverting the drone, in some embodiments. As shown at block 1340, the method further comprises taking action according to the indication action. When the indication of an action indicates disconnecting the drone, for example, the method may comprise sending a PDU session release message to a PCF in the telecommunications network. When the indication of an action indicates diverting the drone, as another example, the method may comprise sending, to a drone operator corresponding to the drone, a request to divert the drone. Figure 14 is a process flow diagram illustrating an example method carried out in a first network node of a telecommunications network, such as an SEAF. The method shown in Figure 14 complements the method of Figure 12, and, like the method shown in Figure 12, may be understood as a generalization of at least some of the steps of the procedure shown in Figure 7, for registering a flight certificate in association with a drone. The method shown in Figure 14 begins with the step of receiving, from a wireless device, a communication identifier associated with the wireless device and a flight certificate, as shown at block 1410. This communication identifier may be a SUCI, for example. In some embodiments or instances, a pilot certificate may be included with the flight certificate. As shown at block 1420, the method continues with sending the communication identifier and the flight certificate (and, in some cases, the pilot certificate) to a second network node, in or in association with an authentication request. This second network node may be an AUSF, for example. As shown at block 1430, the method continues with receiving, in response to the authentication request, an authentication response indicating that the flight certificate is authenticated. Finally, as shown at block 1440, the first network node sends an acknowledgement message to the wireless device, in response to the authentication response. Figure 15 is a process flow diagram illustrating a method complementing those of Figures 12 and shows a method carried out in a second network node of a telecommunications network, such as an AUSF. As shown at block 1510, the method comprises receiving, from a first network node of the telecommunications network, a communication identifier for a wireless device and a flight certificate, in or in association with an authentication request. The first network node may be an SEAF, for example. In some embodiments or instances, a pilot certificate may also be received. The method further comprises validating the flight certificate (and the pilot certificate, if present), as shown at block 1520. As shown at block 1530, the method further comprises sending to the first network node, in response to the authentication request, an authentication response indicating that the flight certificate is authenticated. In some embodiments, validating the flight certificate comprises sending the flight certificate to an ARPF and receiving from the ARPF an indication that the certificate is valid. In some embodiments, the communication identifier is a SUCI. Figure 16 illustrates an example wireless device 50 (e.g., UE) that is configured to perform the techniques described herein for the wireless communication device. Wireless device 50 may also be considered to represent any wireless device that may operate in a network and that IS capable of communicating with a network node or another wireless device over radio signals. Wireless device 50 may also be referred to, in various contexts, as a radio communication device, a target device, a UE, a device-to-device (D2D) UE, a machine-type UE or UE capable of machine to machine (M2M) communication, a sensor-equipped UE, a PDA (personal digital assistant), a wireless tablet, a mobile terminal, a smart phone, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), a wireless USB dongle, a Customer Premises Equipment (CPE), etc. Wireless device 50 communicates with one or more radio nodes or base stations, such as one or more network nodes 30, via antennas 54 and a transceiver circuitry 56. Transceiver circuitry 56 may include transmitter circuits, receiver circuits, and associated control circuits that are collectively configured to transmit and receive signals according to a radio access technology, for the purposes of providing cellular communication services. Wireless device 50 also includes processing circuitry 52 that is operatively associated with and controls the radio transceiver circuit 56. Processing circuitry 52 comprises one or more digital processing circuits 62, e.g., one or more microprocessors, microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), Application Specific Integrated Circuits (ASICs), or any mix thereof. More generally, processing circuitry 52 may comprise fixed circuitry, or programmable circuitry that is specially adapted via the execution of program instructions implementing the functionality taught herein, or may comprise some mix of fixed and programmed circuitry. Processing circuitry 52 may be multi-core. Processing circuitry 52 also includes a memory 64. Memory 64, in some embodiments, stores one or more computer programs 66 and, optionally, configuration data 68. Memory 64 provides non-transitory storage for computer program 66 and it may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mix thereof. By way of non-limiting example, memory 64 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory, which may be in processing circuitry 52 and/or separate from processing circuitry 52. In general, memory 64 comprises one or more types of computer-readable storage media providing non-transitory storage of computer program 66 and any configuration data 68 used by wireless device 50. Wireless device 50 may be attached to or embedded into a drone, and its processing circuitry may be configured, e.g., with appropriate program code stored in memory 64, to carry out any of the operations, tasks, procedures, or methods described herein and attributed to a wireless device, UE, or drone. Thus, for example, wireless device 50 may be configured to carry out of the operations associated with the UE in Figures 2, 3, 4, 7, and 8, as well as the steps shown in Figure 12. Various aspects of the techniques described herein are carried out by each of several communications network nodes. For the purposes of the present description, the term “network node” may refer to a network server, a wireless communications network node, and the like. A given network node may be instantiated in multiple distinct hardware units, in some embodiments, and multiple network nodes may share or co-exist in a given hardware unit, in some embodiments. Each of the units described herein as an application server (AS), NEF, SEAF, AUSF, UDM, ARPF, AMF, SMF, PCF, UPF may be embodied in or as a network node. Figure 17 illustrates an example network node 30. Network node 30 may facilitate communication between wireless terminals, other network access nodes and/or the core network. Network node 30 may be a server in or connected to a wireless telecommunications network. Network node 30 includes communication interface circuitry 38 that includes circuitry for communicating with other network nodes for the purposes of providing data and/or cellular communication services. Network node 30 may be a radio base station or other wireless access node, in some embodiments, in which case the communication interface circuitry 38 may include transmitter circuits, receiver circuits, and associated control circuits that are collectively configured to transmit and receive signals according to a radio access technology, for the purposes of providing cellular communication services. Network node 30 also includes one or more processing circuits 32 that are operatively associated with communication interface circuitry 38. Processing circuitry 32 comprises one or more digital processors 42, e.g., one or more microprocessors, microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), Application Specific Integrated Circuits (ASICs), or any mix thereof. More generally, processing circuitry 32 may comprise fixed circuitry, or programmable circuitry that is specially configured via the execution of program instructions implementing the functionality taught herein, or may comprise some mix of fixed and programmed circuitry. Processor 42 may be multi-core, i.e., having two or more processor cores utilized for enhanced performance, reduced power consumption, and more efficient simultaneous processing of multiple tasks. Processing circuitry 32 also includes a memory 44. Memory 44, in some embodiments, stores one or more computer programs 46 and, optionally, configuration data 48. Memory 44 provides non-transitory storage for the computer program 46 and it may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mix thereof. Here, “non-transitory” means permanent, semi-permanent, or at least temporarily persistent storage and encompasses both long-term storage in non-volatile memory and storage in working memory, e.g., for program execution. By way of non-limiting example, memory 44 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory, which may be in processing circuitry 32 and/or separate from processing circuitry 32. Memory 44 may also store any configuration data 48 used by network access node 30. Processing circuitry 32 may be configured, e.g., through the use of appropriate program code stored in memory 44, to carry out one or more of the methods and/or signaling processes detailed hereinafter. More particularly, network node 30 may be configured, e.g., via appropriate program code stored in memory 44, to carry out any of the operations, tasks, procedures, or methods described herein and attributed to network nodes or servers described herein. Thus, for example, network node 30 may be configured to carry out of the operations associated with a node other than the UE in Figures 2-9, as well as the steps shown in any of Figures 10, 11, and 13-15.

Claims

CLAIMS What is claimed is: 1. A method for registering a flight certificate, in one or more network nodes acting as an application function, the method comprising: obtaining (1010) a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone; and sending (1020) to a network exposure function in a telecommunications network, for registration in the network, drone flight information comprising at least the communication identifier and the flight certificate.

2. The method of claim 1, wherein the communication identifier is an International Mobile Subscription Identifier, IMSI, or Subscription Permanent Identifier, SUPI.

3. The method of claim 1 or 2, wherein the flight certificate is an X.509 certificate.

4. The method of any one of claims 1-3, wherein obtaining (1010) the flight certificate comprises sending flight information to the regulating authority, the flight information comprising the communication identifier for the drone and flight characteristics for a flight, the flight characteristics comprising one or more of any of: a type of flight; a time of day for the flight; and a flight path or flight area.

5. The method of claim 4, wherein the flight information further comprises drone characteristics, the drone characteristics comprising one or more of any of: a drone type; a drone weight; a drone maximum speed; a camera type and/or camera parameter for a camera carried by the drone; and a parameter for an audio recorder carried by the drone.

6. The method of claim 4 or 5, wherein the flight information further comprises a pilot certificate.

7. A method, in one or more network nodes acting as a network exposure function, NEF, for a telecommunications network, the method comprising: receiving (1110), from network equipment associated with a drone operator, drone flight information comprising at least a communication identifier for a drone and a flight certificate associated with the communication identifier; sending (1120) at least the flight certificate to a regulating authority, for validation; receiving (1130), from the regulating authority, an indication of whether the flight certificate is valid; and, responsive to receiving an indication that the flight certificate is valid, sending (1140) the flight certificate to a repository function for storage.

8. The method of claim 7, wherein the communication identifier is an International Mobile Subscription Identifier, IMSI, or Subscription Permanent Identifier, SUPI.

9. The method of claim 7 or 8, wherein the flight certificate is an X.509 certificate.

10. The method of any one of claims 7-9, wherein the flight information further comprises flight characteristics for a flight, the flight characteristics comprising one or more of any of a type of flight, a time of day for the flight, and a flight path or flight area, and wherein the method comprises sending the flight characteristics to the regulating authority with the flight certificate.

11. The method of any one of claims 7-10, wherein the flight information further comprises a pilot certificate, and wherein the method comprises sending the pilot certificate to the regulating authority with the flight certificate.

12. A method, in a wireless device associated with a drone, the method comprising: sending (1210), to a network node in a telecommunications network, a communication identifier associated with the wireless device and a flight certificate; receiving (1220), in response to said sending, an acknowledgment message.

13. The method of claim 12, wherein the communication identifier is a Subscription Concealed Identifier, SUCI.

14. The method of claim 12 or 13, wherein the network node is a security anchor function, SEAF, in the telecommunications network.

15. The method of any one of claims 12-14, wherein the method comprises sending a pilot certificate to the network node along with the flight certificate.

16. The method of any one of claims 12-15, further comprising, subsequent to receiving the acknowledgement message, requesting (1230) establishment of a protocol data unit, PDU, session with the telecommunications network.

17. The method of claim 16, wherein requesting (1230) the PDU session comprises sending, to an access mobility function, AMF, in the telecommunications network, a communication identifier for the wireless device and the flight certificate.

18. The method of claim 17, wherein the communication identifier is a Subscription Permanent Identifier, SUPI, or a Subscription Concealed Identifier, SUCI.

19. The method of claim 17 or 18, wherein the method comprises sending a pilot certificate to the AMF along with the flight certificate.

20. The method of any one of claims 16-19, further comprising, in response to requesting establishment of the PDU session, receiving (1240) a PDU session establishment request response.

21. The method of any one of claims 12-20, wherein the flight certificate is an X.509 certificate.

22. A method, in one or more network nodes acting as a network exposure function, NEF, for a telecommunications network, the method comprising: receiving (1310), from a regulatory authority, a request for drone identifier, wherein the request includes or is associated with one or more parameters, the one or more parameters comprising any one or more of a drone operator identifier, a flight certificate, an indicator of a flight area, and a flight certificate; sending (1320), in response to the request, at least one drone identifier corresponding to the one or more parameters.

23. The method of claim 22, further comprising: receiving (1330), from the regulatory authority, a request to intercept a drone, the request to intercept a drone comprising at least one drone identifier and an indication of an action.

24. The method of claim 23, wherein the indication of an action indicates one of disconnecting the drone and diverting the drone.

25. The method of claim 24, wherein the indication of an action indicates disconnecting the drone, and wherein the method further comprises sending a protocol data unit, PDU, session release message to a policy control function, PCF, in the telecommunications network.

26. The method of claim 24, wherein the indication of an action indicates diverting the drone, and wherein the method further comprises sending, to a drone operator corresponding to the drone, a request to divert the drone.

27. A network node adapted to act as an application function, wherein the network node is adapted to: obtain a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone; and send to a network exposure function in a telecommunications network, for registration in the network, drone flight information comprising at least the communication identifier and the flight certificate.

28. The network node of claim 27, further adapted to carry out a method according to any of claims 2-6.

29. A network node configured to act as an application function, the network node comprising: processing circuitry; and memory operatively coupled to the processing circuitry and storing program instructions for execution by the processing circuitry, whereby the network node is configured to: obtain a flight certificate from a regulating authority, the flight certificate being associated with a communication identifier for a drone; and send to a network exposure function in a telecommunications network, for registration in the network, drone flight information comprising at least the communication identifier and the flight certificate.

30. The network node of claim 29, wherein the network node is further configured to carry out a method according to any of claims 2-6.

31. A network node adapted to act as a network exposure function, wherein the network node is adapted to: receive, from network equipment associated with a drone operator, drone flight information comprising at least a communication identifier for a drone and a flight certificate associated with the communication identifier; send at least the flight certificate to a regulating authority, for validation; receive, from the regulating authority, an indication of whether the flight certificate is valid; and, responsive to receiving an indication that the flight certificate is valid, send the flight certificate to a repository function for storage.

32. The network node of claim 31, further adapted to carry out a method according to any of claims 8-11.

33. A network node configured to act as a network exposure function, the network node comprising: processing circuitry; and memory operatively coupled to the processing circuitry and storing program instructions for execution by the processing circuitry, whereby the network node is configured to: receive, from network equipment associated with a drone operator, drone flight information comprising at least a communication identifier for a drone and a flight certificate associated with the communication identifier; send at least the flight certificate to a regulating authority, for validation; receive, from the regulating authority, an indication of whether the flight certificate is valid; and, responsive to receiving an indication that the flight certificate is valid, send the flight certificate to a repository function for storage.

34. The network node of claim 33, wherein the network node is further configured to carry out a method according to any of claims 8-11.

35. A wireless device adapted to: send, to a network node in a telecommunications network, a communication identifier associated with the wireless device and a flight certificate; receive, in response to said sending, an acknowledgment message.

36. The wireless device of claim 35, wherein the wireless device is adapted to carry out a method according to any of claims 13-21.

37. A wireless device, comprising: transceiver circuitry configured to communicate with a wireless network; processing circuitry operatively coupled to the transceiver circuitry; and memory operatively coupled to the processing circuitry and storing program instructions for execution by the processing circuitry, whereby the wireless device is configured to: send, to a network node in a telecommunications network, a communication identifier associated with the wireless device and a flight certificate; receive, in response to said sending, an acknowledgment message.

38. The wireless device of claim 37, wherein the wireless device is configured to carry out a method according to any of claims 13-21.

39. A network node adapted to act as a network exposure function, the network node being adapted to: receive, from a regulatory authority, a request for drone identifier, wherein the request includes or is associated with one or more parameters, the one or more parameters comprising any one or more of a drone operator identifier, a flight certificate, an indicator of a flight area, and a flight certificate; send, in response to the request, at least one drone identifier corresponding to the one or more parameters.

40. The network node of claim 39, wherein the network node is adapted to carry out a method according to any of claims 23-26.

41. A network node configured to act as a network exposure function, the network node comprising: processing circuitry; and memory operatively coupled to the processing circuitry and storing program instructions for execution by the processing circuitry, whereby the network node is configured to: receive, from a regulatory authority, a request for drone identifier, wherein the request includes or is associated with one or more parameters, the one or more parameters comprising any one or more of a drone operator identifier, a flight certificate, an indicator of a flight area, and a flight certificate; send, in response to the request, at least one drone identifier corresponding to the one or more parameters.

42. The network node of claim 41, wherein the network node is adapted to carry out a method according to any of claims 23-26.