Authentication method and communication device

Abstract

The present application relates to the technical field of communications. Provided are an authentication method and a communication apparatus. The authentication method is applied to a scenario where an uncrewed aerial vehicle switches from a source server to a target server. The method comprises: a first device acquiring a first identification corresponding to a target server, wherein the first identification is used for identifying an uncrewed aerial vehicle; and the first device sending the first identification to the target server, wherein the first identification is used by the target server to authenticate or re-authenticate the uncrewed aerial vehicle. The authentication method provided in the present application can solve the problem of how to make the target server authenticate the uncrewed aerial vehicle in a switching scenario, thereby ensuring the continuity of flight services of the uncrewed aerial vehicle, and improving the safety of the flight of the uncrewed aerial vehicle.

Description

Authentication method and communication device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 30, 2024, with application number 202410385920.3 and application name “A Method for Authentication and Communication Device”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to an authentication method and a communication device. Background Art

[0003] In recent years, the use of uncrewed aerial vehicles (UAVs) has become increasingly popular, based on fifth-generation (5G) communication systems. When flying within the service area of ​​a UAS service provider (USS), a drone can send an authentication request to the USS via the 5G network. The USS authenticates the drone based on the Civil Aviation Administration-level UAV identification (CAA-Level UAV ID) carried in the request. Upon successful authentication, the USS provides services to the user or drone, enabling better drone management.

[0004] Previous standard discussions assumed that drones only flew within a single USS service area and therefore only needed to request authentication from the USS corresponding to that service area. However, with the improvement of drone performance and the development of communication technology, multiple USS service areas may exist along a drone's flight path. This means that a drone may switch from its original service area to a new one. Since a USS is responsible for only one service area, switching USSs during flight is a common scenario.

[0005] In the scenario where the USS providing services for a drone switches from a source USS to a target USS, how to enable the target USS to authenticate and authorize the drone to ensure the continuity of the drone's flight service becomes a technical problem to be solved. Summary of the Invention

[0006] The embodiments of the present application provide an authentication method and a communication device, which can solve the problem of how to enable the target server to authenticate the drone in a switching scenario, ensure the continuity of the drone flight service, and improve the safety of the drone flight.

[0007] In the first aspect, an authentication method is provided, which is applied in a scenario where a drone switches from a source server to a target server, including: a first device obtains a first identifier corresponding to the target server, and the first identifier is used to identify the drone; the first device sends the first identifier to the target server, and the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0008] The drone in the embodiment of the present application corresponds to multiple servers, and the drone can be connected to or switched to different servers, and different servers will provide flight services for the drone in turn. When the drone switches from the source server to the target server, the target server first needs to authenticate the drone, and only after the authentication is successful will it provide the corresponding flight service. It is easy to understand that drones usually correspond to different drone identifiers in different servers. The target server must use the identifier of the drone corresponding to the drone in the target server (i.e., the first identifier) ​​to authenticate the drone before the authentication is successful. Here, the identifiers of multiple drones, including the first identifier, are used to identify the drone. The identifier of the drone can, for example, be the CAA-Level UAV ID, the identifier of the drone at the Civil Aviation Administration level, but is not limited to this. The identifier of the drone is assigned to the drone by the server, which at least ensures that the drone is uniquely identified within the scope of one server.

[0009] On this basis, according to the authentication method provided in the embodiment of the present application, when the drone switches from the source server to the target server, the first device in the network can obtain the first identifier corresponding to the target server, and the first identifier is used to identify the drone. For example, the first identifier can be the CAA-Level UAV ID assigned to the drone by the target server, and the first identifier is sent to the target server so that the target server can authenticate or re-authenticate the drone in a timely manner based on the first identifier, so that the drone can obtain the flight service provided by the target server in a timely manner, ensure the continuity of the drone flight service, and improve the safety of the drone flight.

[0010] Optionally, the server here may be an application server or an application function network element, for example, in one possible implementation, it may be the aforementioned USS. Therefore, the source server may be a source USS (source USS, S-USS), and the target server may be a target USS (target USS, T-USS). In one possible implementation, the server here may also be a UAS traffic management (UTM) server, for example, the source server may be a source UTM (source UTM, S-UTM), and the target server may be a target UTM (target USS, T-UTM). It is understandable that the server here indicates an application server or application function network element that can assign a drone identifier to a drone and optionally provide drone services. In another possible implementation, the server here may also only provide drone services to the drone without assigning an identifier. In this case, the drone identifier of the drone may be assigned or provided by other servers or devices.

[0011] Optionally, the first device may be any device that can obtain the first identifier and can send the first identifier to the target server. For example, the first device may be any device on the link between the drone and the server. For example, the first device may be an access and mobility management function (AMF) network element, and the first device may also be a session management function (SMF) network element S. The first device may also be an uncrewed aerial system network function (UAS NF) network element or a network exposure function (NEF) network element. In addition, the first device may also be the drone itself. That is to say, after any device on the link between the drone and the server determines or learns that the server of the drone has been switched, it may obtain the first identifier and send the first identifier to the target server, so that the target server can authenticate the drone based on the first identifier.

[0012] Optionally, a drone may have multiple drone identifiers, each of which is used to identify the drone. These multiple drone identifiers may correspond one-to-one with multiple servers, and different servers may use their corresponding drone identifiers to successfully authenticate the drone. The first identifier may be the identifier of the drone corresponding to or used by the target server, and the target server must use the first identifier to successfully authenticate the drone. Therefore, when the drone switches from a source server to a target server, the first device may obtain the first identifier and send it to the target server, enabling the target server to authenticate the drone.

[0013] Optionally, the drone identifier here can be a CAA-Level UAV ID, but is not limited thereto. For example, the drone identifier corresponding to each server can be the CAA-Level UAV ID assigned to the drone by the server. Multiple servers correspond to multiple CAA-Level UAV IDs, and the first identifier is the CAA-Level UAV ID assigned to the drone by the target server.

[0014] Optionally, the first device can obtain the first identifier corresponding to the target server in any way, for example, the first device can request the first identifier from other devices through the network, or obtain the first identifier from local storage. This application does not specifically limit the acquisition method.

[0015] Optionally, the first device sends a first identifier to the target server, which may be the first device sending an authentication request (e.g., an authentication authorization request) message to the target server, wherein the request message carries the first identifier. After receiving the request message, the target server responds to the request message and uses the first identifier to authenticate or re-authenticate the drone.

[0016] In one possible implementation, the authentication method further includes: the first device receiving first indication information, the first indication information being used to instruct the drone to switch from the source server to the target server, or to instruct the drone to move out of a service area of ​​the source server and / or move into a service area of ​​the target server; or, the first indication information being used to indicate the drone's current target server. The first device obtaining a first identifier corresponding to the target server includes: the first device obtaining the first identifier corresponding to the target server based on the first indication information.

[0017] In one possible manner, the first device may receive first indication information from other devices, where the first indication information is used to instruct the drone to switch from the source server to the target server, or to instruct the drone to move out of the service area of ​​the source server and / or move into the service area of ​​the target server; or, the first indication information is used to indicate the current target server of the drone. After the first device receives the first indication information, it can determine that the server providing services for the drone has switched based on the first indication information. In this way, the first device will obtain the first identifier corresponding to the target server and send the first identifier to the target server. The above settings enable the first device to promptly learn that the drone's server has switched, so that the first device can promptly send the first identifier to the target server, and thus enable the target server to promptly authenticate the drone.

[0018] Optionally, the first indication information may be carried in the authentication notification message. For example, the system or protocol may stipulate that the first indication information may be "0" or "1" on a specific bit in the message. After the first device receives the authentication notification message, it reads the value on the specific bit, that is, determines that the drone switches from the source server to the target server based on the value (for example, "0" or "1").

[0019] Optionally, the first indication information may include a reason value for authentication or re-authentication, which may be "0" or "1" on a specific bit in the message. For example, when the value on the bit is "1", it indicates that the authentication or re-authentication process is triggered due to server switching (that is, the reason for authentication or re-authentication is due to server switching), and when the value on the bit is "0", it indicates that the authentication or re-authentication process is triggered by other reasons. For example, at this time, no server switching occurs but the authentication or re-authentication process is triggered by the source server.

[0020] In a possible implementation, before the first device obtains the first identifier corresponding to the target server, the method further includes: the first device determining that the drone is switched from the source server to the target server.

[0021] That is to say, the first device can determine on its own that the server of the drone has switched without the need for instructions from other devices, that is, the first device can actively initiate the authentication process for the drone, which is also conducive to sending the first identifier to the target server more timely (that is, initiating an authentication request to the target server), thereby enabling the target server to authenticate the drone in a timely manner.

[0022] In one possible implementation, the first device determines that the drone switches from the source server to the target server, including: the first device obtains location information of the drone; the first device determines that the drone switches from the source server to the target server based on the location information and the service area corresponding to the target server.

[0023] In one possible approach, the first device may first obtain the location information of the drone, and then, based on the location information and the service area corresponding to the target server, determine whether the drone is switched from the source server to the target server. The source server and the target server each correspond to a different service area. When the first device determines, based on the drone's location information, that the drone has flown from the service area of ​​the source server to the service area of ​​the target server, it may determine that the server providing service for the drone has switched from the source server to the target server, i.e., the drone has switched from the source server to the target server.

[0024] Optionally, the first device can be the drone itself. In this case, the first device knows its own location information and can determine, based on its own location information, whether the drone switches from the service area corresponding to the source server to the service area corresponding to the target server, and thus can determine whether the drone switches from the source server to the target server.

[0025] Optionally, the first device can be AMF / SMF, in which case the AMF / SMF itself may store the location information of the drone, or the AMF / SMF can obtain (request) location information from the drone, or the AMF / SMF can subscribe to the location information of the drone, and then determine that the drone is switched from the service area corresponding to the source server to the service area corresponding to the target server based on the location information, that is, it can be determined that the drone is switched from the source server to the target server.

[0026] Optionally, the first device may also be a UAS NF / NEF, in which case the UAS NF / NEF may subscribe to the location information of the drone. In one possible implementation, the location information of the drone may be subscribed to the AMF. The UAS NF / NEF uses the location information of different servers as different areas of interest (AoI), and subscribes to the AMF to determine whether the drone is in the area of ​​interest, that is, subscribes to the AMF for UE presence in AoI. When the UAV moves out of / into the corresponding area of ​​interest, the AMF initiates a notification to the UAS NF / NEF, instructing the UAV to move out (out) / into (in) the corresponding area of ​​interest. Thus, the UAS NF / NEF can determine whether the drone has moved out of the service area corresponding to the source server and entered the service area corresponding to the target server based on the location information of the drone. For example, the UAS NF / NEF can determine whether the drone has switched from the source server to the target server.

[0027] In a possible implementation manner, the first indication information includes an identifier of the target server.

[0028] Through the above configuration, the first device can determine, based on the first indication information, that the drone is switching from the source server to the target server, and / or can determine, based on the first indication information, which specific server to switch to (i.e., the target server). For the first device, in one possible implementation, the first device does not need to determine the specific target server using other information (e.g., the drone's location information), which helps the first device obtain the first identifier corresponding to the target server more efficiently and promptly.

[0029] In a possible implementation, the first device obtains the first identifier corresponding to the target server, including: the first device sends first information to the second device, where the first information is used to request the first identifier; and the first device receives the first identifier from the second device.

[0030] In a possible implementation, the first information includes an identifier of the target server and / or second indication information, where the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0031] Through the above settings, the second device can directly determine which server (i.e., the target server) is switched based on the first information. At this time, the second device does not need to use other information (such as the location information of the drone) to determine which target server is. This helps the second device to obtain and send the first identifier corresponding to the target server to the first device more efficiently and timely.

[0032] Optionally, the identifier of the target server may be any information that can uniquely identify the server, and the first device or the second device can clearly know which of the multiple servers the target server is based on the identifier. For example, the identifier of the target server may be the address of the target server, such as an Internet Protocol (IP) address, or a fully qualified domain name (FQDN), but is not limited thereto.

[0033] Optionally, the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identifier information of the drone.

[0034] In a possible implementation, the first device obtains the first identifier corresponding to the target server, including: the first device determines the first identifier based on the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0035] Optionally, the first mapping relationship is used to indicate the correspondence between the identifiers of multiple servers and the identifiers of multiple drones, the identifiers of the multiple drones are used to identify the drone, the multiple servers are used to provide services for the drone and include a target server, and any one of the multiple servers must use the identifier of the drone corresponding to itself to authenticate the drone before the authentication is successful. Exemplarily, there can be a one-to-one correspondence between the identifiers of multiple servers and the identifiers of multiple drones, but this application does not exclude the situation where multiple (for example, two or three) servers share the identifier of a drone (that is, multiple servers correspond to the identifier of one drone), and does not exclude the situation where a server can use the identifiers of multiple (for example, two or three) different drones to authenticate the drone (that is, one server corresponds to the identifiers of multiple drones).

[0036] Optionally, the first mapping relationship may include a correspondence between the identifiers of multiple USSs (i.e., USS lists) and multiple CAA-Level UAV IDs. That is, the identifiers of multiple drones may be multiple CAA-Level UAV IDs, and the identifier of the drone corresponding to each USS is the CAA-Level UAV ID assigned by the USS to the drone. The first identifier is the CAA-Level UAV ID assigned by the target server (T-USS) to the drone.

[0037] Optionally, in some cases, the CAA-Level UAV ID may include identification information of its corresponding USS, that is, the CAA-Level UAV ID may include or indicate the correspondence between the UAV ID and the identification of the USS, or in other words, the USS corresponding to the UAV ID can be determined based on the CAA-Level UAV ID (that is, the corresponding USS identification is determined). Therefore, the first mapping relationship in this application may, for example, include multiple CAA-Level UAV IDs, and configuring the first mapping relationship may be configuring multiple CAA-Level UAV IDs of the drone (that is, there is no need to additionally configure the corresponding multiple USSs).

[0038] Optionally, the first device may be the drone itself, and the first mapping relationship may be pre-configured by the manufacturer before the drone leaves the factory; or the first mapping relationship may be configured through the application layer (application software).

[0039] Optionally, the first device may be an AMF / SMF, or may be a UAS NF / NEF. In this case, the first device may obtain the first mapping relationship in advance from the drone or from the application server, for example, through a UUAA-MM process or a UUAA-SM process.

[0040] In one possible implementation, the first device is the drone, the access and mobility management function AMF network element, the session management function SMF network element, the drone aviation system network function UAS NF network element or the network open function NEF network element.

[0041] In the second aspect, an authentication method is provided, which is applied to a scenario where a drone switches from a source server to a target server, including: a second device receives first information from a first device, the first information is used to request a first identifier corresponding to the target server, and the first identifier is used to identify the drone; in response to the first information, the second device sends the first identifier to the first device, wherein the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0042] According to the authentication method provided in this application, in a scenario where a drone switches from a source server to a target server, after the second device receives the first information from the first device, the second device can send a first identifier to the first device based on the first information. The first identifier is used to identify the drone, and the first identifier can be used by the target server to authenticate or re-authenticate the drone. Thus, after the first device receives the first identifier from the second device, it can continue to send the first identifier to the target server, so that the target server can promptly authenticate or re-authenticate the drone based on the first identifier, allowing the drone to promptly obtain flight services provided by the target server, thereby improving the safety of the drone's flight.

[0043] In one possible implementation, before the second device sends the first identifier to the first device, the authentication method further includes: the second device determines the first identifier based on the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0044] In one possible implementation, the first information includes the identifier of the target server and / or second indication information, and the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0045] In one possible implementation, the second device is an access and mobility management function AMF network element or a session management function SMF network element, and the first device is an unmanned aerial vehicle system network function UAS NF network element or a network open function NEF network element or a UAS service provider USS or a UAS traffic management UTM; or, the second device is the drone, and the first device is the AMF network element, the SMF network element, the UAS NF network element or the NEF network element.

[0046] In a third aspect, a communication device is provided, which is used in a scenario where a drone switches from a source server to a target server, and includes: a processing unit, used to obtain a first identifier corresponding to the target server, and the first identifier is used to identify the drone; a sending unit, used to send the first identifier to the target server, and the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0047] In one possible implementation, the communication device also includes: a receiving unit, used to receive first indication information, wherein the first indication information is used to instruct the drone to switch from the source server to the target server, or to instruct the drone to move out of the service area of ​​the source server and / or the drone to move into the service area of ​​the target server, or the first indication information is used to indicate the current target server of the drone; the processing unit is specifically used to: obtain a first identifier corresponding to the target server according to the first indication information.

[0048] In a possible implementation, the processing unit is further configured to: determine that the drone is switched from the source server to the target server.

[0049] In a possible implementation, the processing unit is specifically configured to: obtain location information of the drone; and determine, based on the location information and a service area corresponding to the target server, whether the drone is switched from the source server to the target server.

[0050] In a possible implementation manner, the first indication information includes an identifier of the target server.

[0051] In a possible implementation, the sending unit is further configured to send first information to the second device, where the first information is used to request the first identifier; and the communication apparatus further comprises a receiving unit configured to receive the first identifier from the second device.

[0052] In one possible implementation, the first information includes the identifier of the target server and / or second indication information, and the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0053] In a possible implementation, the processing unit is specifically configured to determine the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0054] In one possible implementation, the communication device is the drone, the access and mobility management function AMF network element, the session management function SMF network element, the drone aviation system network function UAS NF network element or the network open function NEF network element.

[0055] In a fourth aspect, a communication device is provided, which is used in a scenario where a drone switches from a source server to a target server, and includes: a receiving unit for receiving first information from a first device, wherein the first information is used to request a first identifier corresponding to the target server, and the first identifier is used to identify the drone; a sending unit for sending the first identifier to the first device according to the first information, wherein the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0056] In a possible implementation, the communication device further includes: a processing unit, configured to determine the first identifier based on the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0057] In one possible implementation, the first information includes the identifier of the target server and / or second indication information, and the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0058] In one possible implementation, the communication device is an access and mobility management function AMF network element or a session management function SMF network element, and the first device is an unmanned aerial vehicle system network function UAS NF network element or a network open function NEF network element or a UAS service provider USS or a UAS traffic management UTM; or, the communication device is the unmanned aerial vehicle, and the first device is the AMF network element, the SMF network element, the UAS NF network element or the NEF network element.

[0059] In a fifth aspect, a communication device is provided, comprising at least one processor, wherein the at least one processor is used to couple with a memory, read and execute instructions in the memory, so as to implement the method executed by any one of the implementation modes in the aforementioned first aspect.

[0060] Optionally, the communication device further includes the memory.

[0061] In a sixth aspect, a communication device is provided, comprising at least one processor, wherein the at least one processor is used to couple with a memory, read and execute instructions in the memory, so as to implement the method executed by any one of the implementation modes in the second aspect.

[0062] Optionally, the communication device further includes the memory.

[0063] In the seventh aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is run on a computer, the computer executes the method executed by any one of the implementation methods of the first or second aspect above.

[0064] In an eighth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method executed by any one of the implementations of the first or second aspects above.

[0065] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately from the processor, and this application does not make any specific restrictions on this.

[0066] In the ninth aspect, a chip system is provided, comprising a processor for calling and running a computer program from a memory, so that a communication device equipped with the chip system executes a method executed by any one of the implementation modes in the first or second aspect above.

[0067] In a tenth aspect, a communication system is provided, which includes the communication device provided in the third aspect and / or the communication device provided in the fourth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] FIG1 shows a schematic diagram of the architecture of a communication system applicable to an embodiment of the present application.

[0069] FIG2 shows a schematic diagram of the architecture of another communication system applicable to an embodiment of the present application.

[0070] FIG3 is a flow chart of an example of a UAV authentication and authorization method in the prior art.

[0071] FIG4 is a flow chart of another example of a UAV authentication and authorization method in the prior art.

[0072] FIG5 is a flow chart of another example of a UAV authentication and authorization method in the prior art.

[0073] FIG6 is a schematic diagram of a flow chart of a UAV re-authentication process within a 5GS in the prior art.

[0074] FIG7 shows a schematic diagram of an application scenario to which an embodiment of the present application is applicable.

[0075] FIG8 is a schematic flowchart of an example of an authentication method provided in an embodiment of the present application.

[0076] FIG9 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0077] FIG10 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0078] FIG11 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0079] FIG12 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0080] FIG13 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0081] FIG14 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0082] Figure 15 is a schematic flowchart of another example of the authentication method provided in an embodiment of the present application.

[0083] FIG16 is a schematic structural diagram of an example of a communication device provided in an embodiment of the present application.

[0084] Figure 17 is a structural diagram of another example of a communication device provided in an embodiment of the present application.

[0085] FIG18 is a structural diagram of another example of a communication device provided in an embodiment of the present application.

[0086] Figure 19 is a structural diagram of another example of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0087] The technical solution in this application will be described below with reference to the accompanying drawings.

[0088] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as: fifth generation (5G) mobile communication systems or new radio (NR) systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided by the present application can also be applied to future communication systems, such as sixth generation (6G) mobile communication systems. The technical solutions of the embodiments of the present application can also be applied to device to device (D2D) communication, vehicle-to-everything (V2X) communication, machine to machine (M2M) communication, machine type communication (MTC), and Internet of Things (IoT) communication systems or other communication systems.

[0089] To facilitate understanding of the embodiments of the present application, a communication system to which the embodiments of the present application are applicable is first briefly introduced with reference to FIG1 and FIG2 .

[0090] As an exemplary illustration, FIG1 shows a schematic diagram of the architecture of a communication system applicable to an embodiment of the present application. The communication system shown in FIG1 includes a 5G network architecture based on a service-oriented interface. As shown in FIG1 , the network architecture may include, but is not limited to, the following network elements:

[0091] User equipment (UE), 5G radio access network (NG-RAN), access and mobility management function (AMF) network element, session management function (SMF) network element, user plane function (UPF) network element, application function (AF) network element, policy control function (PCF) network element, unified data management (UDM) network element, network exposure function (NEF) network element, network data analytics function (NWDAF) network element, authentication server function (AUSF) network element, network repository function (NRF) network element, data network (DN), etc.

[0092] The following is a brief introduction to each network element or device shown in Figure 1:

[0093] 1. UE: A terminal that communicates with the (R)AN. It may also be called terminal equipment, access terminal, subscriber unit, subscriber station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. A terminal device can be a device that provides voice / data connectivity to a user, such as a handheld device or vehicle-mounted device with wireless connectivity. At present, some examples of terminals may include: mobile phones, tablet computers, computers with wireless transceiver functions (such as laptops, PDAs, etc.), mobile internet devices (MIDs), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication functions, computing devices or other processing devices connected to wireless modems, vehicle-mounted devices, wearable devices, terminal devices in 5G networks or future evolved public land mobile communication networks (PLMNs). terminal equipment in network, PLMN, etc.

[0094] Furthermore, terminal devices can also be end devices in IoT systems. IoT is a crucial component of future information technology development. Its primary technical feature is connecting objects to the internet through communication technologies, thereby enabling intelligent networks that interconnect humans and machines, and objects and things. IoT technology, for example, utilizes narrowband (NB) technology to achieve massive connectivity, deep coverage, and power-saving terminals.

[0095] It should be understood that the terminal device can be any device that can access the network. The terminal device and the access network device can communicate with each other using a certain air interface technology.

[0096] Alternatively, a user device can function as a base station. For example, a user device can act as a dispatching entity, providing sidelink signals between user devices in V2X or D2D scenarios. For example, a cell phone and a car can communicate with each other using sidelink signals. A cell phone and a smart home device can also communicate without relaying the communication signal through a base station.

[0097] 2. NG-RAN: It is used to provide network access for authorized user devices in a specific area and can use transmission tunnels with different service qualities based on the level of user devices and business requirements.

[0098] NG-RAN can manage wireless resources, provide access services for user devices, and then complete the forwarding of control signals and user device data between user devices and the core network. NG-RAN can also be understood as a base station in a traditional network.

[0099] Exemplarily, the access network device in the embodiment of the present application may be any communication device with wireless transceiver functions for communicating with user equipment. The access network equipment includes but is not limited to: evolved Node B (eNB), radio network controller (RNC), Node B (NB), base station controller (BSC), base transceiver station (BTS), home evolved Node B (HeNB, or home Node B, HNB), baseband unit (BBU), access point (AP) in wireless fidelity (WIFI) system, wireless relay node, wireless backhaul node, transmission point (TP) or transmission and reception point (TRP), etc., and can also be a gNB in ​​5G, such as NR, system, or a transmission point (TRP or TP), one or a group of (including multiple antenna panels) antenna panels of a base station in a 5G system, or a network node constituting a gNB or a transmission point, such as a baseband unit (BBU) or a distributed unit (DU), etc.

[0100] In some deployments, a gNB may include a centralized unit (CU) and a DU. The gNB may also include an active antenna unit (AAU). The CU implements some gNB functions, while the DU implements some gNB functions. For example, the CU is responsible for processing non-real-time protocols and services, implementing the functions of the radio resource control (RRC) and packet data convergence protocol (PDCP) layers. The DU is responsible for processing physical layer protocols and real-time services, implementing the functions of the radio link control (RLC), media access control (MAC), and physical (PHY) layers. The AAU implements some physical layer processing functions, RF processing, and active antenna-related functions. Because RRC layer information ultimately becomes PHY layer information, or is converted from PHY layer information, in this architecture, higher-layer signaling, such as RRC layer signaling, can also be considered to be sent by the DU, or by both the DU and the AAU. It is understood that an access network device can be a device that includes one or more of a CU node, a DU node, or an AAU node. In addition, the CU may be classified as an access network device in an access network (radio access network, RAN), or the CU may be classified as an access network device in a core network (core network, CN), which is not limited in this application.

[0101] 3. UPF: The main functions are packet routing and forwarding, mobility anchor, uplink classifier to support routing service flows to data networks, branch point to support multi-homing protocol data unit (PDU) sessions, etc.

[0102] In a 5G communication system, the user plane network element may be a UPF network element. In future communication systems, the user plane network element may still be a UPF network element, or may have other names, which are not limited in this application.

[0103] 4. DN: Data network, such as operator services, Internet access, or third-party services.

[0104] In a 5G communication system, the data network may be a DN. In future communication systems, the data network may still be a DN, or may have other names, which are not limited in this application.

[0105] 5. AUSF: Mainly includes the following functions: authentication server function, interacting with the unified data management network element to obtain user information, and performing authentication-related functions, such as generating intermediate keys.

[0106] In a 5G communication system, the authentication server function network element may be an AUSF network element. In future communication systems, the authentication server function network element may still be an AUSF network element, or may have other names, which are not limited in this application.

[0107] 6. AMF: Mainly used for the attachment, mobility management, and tracking area update processes of terminals in mobile networks. The access management network element terminates the non-access stratum (NAS) messages, completes registration management, connection management, and reachability management, allocates tracking area lists (TA lists) and mobility management, and transparently routes session management (SM) messages to the session management network element.

[0108] In a 5G communication system, the access management network element may be an AMF network element. In future communication systems, the access management network element may still be an AMF network element, or may have other names, which are not limited in this application.

[0109] 7. SMF: Mainly used for session management, Internet protocol (IP) address allocation and management of terminal devices, selection of endpoints for manageable user plane functions, policy control and charging function interfaces, and downlink data notification.

[0110] In a 5G communication system, the session management network element may be an SMF network element. In future communication systems, the session management network element may still be an SMF network element, or may have other names, which are not limited in this application.

[0111] 8. PCF: includes user contract data management, policy control, charging policy control, quality of service (QoS) control, etc.

[0112] In a 5G communication system, the policy control network element may be a PCF network element. In future communication systems, the policy control network element may still be a PCF network element, or may have other names, which are not limited in this application.

[0113] 9. UDM: This is the name for the unified data management (UDM) network element in the 5G architecture. It primarily includes the following functions: unified data management, support for authentication credentials processing in the 3rd Generation Partnership Project (3GPP) authentication and key agreement mechanism, user identity processing, access authorization, registration and mobility management, contract management, and short message management.

[0114] 10. NEF: Mainly includes the following functions: secure open 3GPP network function to provide services and capabilities, some of which are open internally or open to third parties; conversion or translation of information interacting with AF and information interacting with internal network functions, such as AF service identifier and internal 5G core network information such as data network name (DNN), single network slice selection assistance information (S-NSSAI), etc.

[0115] 11. NRF: Mainly includes the following functions: service discovery function, maintaining the NF context of available network function (NF) instances and the services they support.

[0116] 12. NWDAF: It can collect data from various NFs, such as policy control network elements, session management network elements, user plane network elements, access management network elements, and application function network elements (through network capability exposure function network elements), and perform analysis and prediction.

[0117] In a 5G communication system, the data analysis network element may be an NWDAF network element. In future communication systems, the data analysis network element may still be an NWDAF network element, or may have other names, which are not limited in this application.

[0118] 13. AF: Mainly includes the following functions: connection management, mobility management, registration management, access authentication and authorization, reachability management, security context management and other access and mobility related functions.

[0119] As can be seen from FIG1 , the interfaces between the various control plane network elements in FIG1 are service-oriented interfaces.

[0120] For example, in Figure 1, Nnef, Nnrf, Nnwdaf, Namf, Npcf, Nsmf, and Nudm are service-oriented interfaces provided by the NEF, NRF, NWDAF, AMF, PCF, SMF, and UDM, respectively, for invoking corresponding service-oriented operations. N1, N2, N3, N4, N6, and N9 are interface serial numbers. The meaning of these interface serial numbers can be found in the 3GPP standard protocol and is not limited here.

[0121] Service-oriented development enables the 5G core network to form a flat architecture. Through the control plane signaling bus, the control plane network function entities of the same network slice can discover each other through the NRF network element, obtain each other's access address information, and then communicate directly with each other through the control plane signaling bus.

[0122] It should be noted that the interfaces between the control plane network elements in FIG1 may also be point-to-point interfaces, which will not be described in detail here.

[0123] It is understandable that the above-mentioned network elements or functions can be network elements in hardware devices, software functions running on dedicated hardware, or virtualized functions instantiated on a platform (for example, a cloud platform).

[0124] The above "network element" may also be referred to as a "functional network element," "functional entity," "entity," "node," "device," or "apparatus," etc., and this application does not impose any limitation thereto. In actual deployment, network elements may be co-located. When two network elements are co-located, the interaction between the two network elements provided in the embodiments of this application becomes an internal operation of the co-located network element or may be omitted.

[0125] For ease of explanation, this application will be described later using the access and mobility management function network element as the AMF network element and the session management function network element as the SMF network element as an example. Furthermore, the AMF network element will be referred to as AMF, and the SMF network element will be referred to as SMF. That is, the AMF described later in this application can be replaced with the access and mobility management function network element, and the SMF can be replaced with the session management function network element.

[0126] It should be noted that the names of the various network elements and the communication interfaces between network elements involved in Figure 1 are simply described using the current protocol as an example, but do not limit the application of the embodiments of this application to only currently known communication systems. Therefore, the standard names that appear when describing the current protocol as an example are all functional descriptions. This application does not limit the specific names of network elements, interfaces, or signaling, but only represents the functions of network elements, interfaces, or signaling, which can be correspondingly extended to other systems, such as 5G or future communication systems.

[0127] In addition, it should be noted that in some network architectures, network function network element entities such as AMF network elements, SMF network elements, PCF network elements, AF network elements and UDM network elements are all called network function (NF) network elements; or, in other network architectures, the collection of network elements such as AMF network elements, SMF network elements, PCF network elements, AF network elements, UDM network elements, etc. can all be called control plane function network elements.

[0128] Figure 1 illustrates a communication system applicable to an embodiment of the present application. In recent years, based on the communication system shown in Figure 1, the use of uncrewed aerial vehicles (UAVs) has become increasingly popular. For example, in the civilian sector, there are a wide variety of drones, ranging from small drones for personal entertainment to a variety of economically valuable drones (e.g., plant protection drones, disaster relief drones, firefighting drones, and delivery drones).

[0129] Furthermore, drones can also provide temporary communication services, carrying wireless access nodes. This is often used for major events such as live football matches or emergencies such as earthquakes and tsunamis. 3GPP is currently discussing UAV networking, which can address issues such as identification, authorization, and tracking when remotely controlling UAVs.

[0130] In one possible approach, an unmanned aerial vehicle (UAS) service provider (USS) provides services for the safe and efficient use of airspace by UAVs, including authentication and authorization of UAVs, authentication and authorization of command and control (C2) communications, and identification and tracking of UAVs. A UAV is a type of user equipment (UE), and a UAS stands for uncrewed aerial system (UAS).

[0131] For ease of understanding, the following introduces UAV, USS, UAS, etc. with reference to Figure 2.

[0132] As an example, Figure 2 shows a schematic diagram of the architecture of another communication system applicable to the embodiment of the present application. Figure 2 is also a schematic diagram of the logical architecture of the drone in the 5G system and the 4G system. The network architecture may include but is not limited to the following network elements (or functional network elements, functional entities, nodes, devices, etc.):

[0133] UAV (i.e. UE), 4G access network ((R)AN), 5G access network NG-RAN, 5G core network (5G core, 5GC), 4G core network (evolved packet core, EPC), USS, UAS network function (UAS network function, UAS NF), DN and third party authorized entity (third party authorized entity, TPAE).

[0134] The following is a brief introduction to the relevant network elements or devices shown in Figure 2:

[0135] 1. UAV: ​​A drone, also known as an unmanned aircraft or aerial robot, is an unmanned aircraft that utilizes a radio remote control device and self-contained programmable control system. It can perform aerial missions and various payload tasks without a human pilot. The drones described in the embodiments of this application may include unmanned helicopters, fixed-wing aircraft, multi-rotor aircraft, unmanned airships, and unmanned paragliders. They may also include near-space aircraft such as stratospheric airships, high-altitude balloons, and solar-powered drones. They may also include various types of drones, including quadcopter, hexcopter, single-axis, and vector-controlled. The drones described in the embodiments of this application can be used in industrial, civil, agricultural, construction, film and television, environmental protection, and other fields, as well as specialized industries requiring drone operations. For example, drones are used for patrols, aerial photography, environmental monitoring, border surveillance, express delivery, power inspections, property rights confirmation, flood control and drought relief, and post-disaster rescue. A drone can also be considered a type of UE. The embodiments of this application do not limit the name or form of the drone.

[0136] It should be understood that this document does not limit the specific types of drones. With the advancement of intelligent technology, the names of devices with drone functionality may vary to suit different scenarios or fulfill different aerial missions. For ease of description, in all embodiments of this application, the aforementioned devices capable of drone functionality are collectively referred to as drones.

[0137] 2. UAS: An unmanned aerial vehicle system (UAS) may include one or more uncrewed aerial vehicle controllers (UAVCs) and one or more drones. For example, a UAV controller may control one or more drones, a drone may be controlled by one or more UAV controllers, or multiple UAV controllers may collaboratively control multiple drones. This is not limited in this embodiment of the present application.

[0138] 3. USS: An unmanned aerial vehicle system service provider (UAS) is an entity that provides services to UAV operators or pilots to meet UAV operational requirements and support the safe and efficient use of airspace. A USS can provide any subset of functions to meet the provider's business objectives. For example, a USS can be responsible for UAV authentication and authorization, C2 communication authentication and authorization, and UAV identification and tracking.

[0139] It should be noted that the naming of USS is only for the convenience of indicating its function and should not constitute any limitation to this application. This application does not exclude the possibility of adopting other names in future standards.

[0140] 4. UTM: UTM is a system that can safely and effectively integrate flying drones with other airspace users. It is a set of functions and services for managing a series of automatic equipment operations (such as drone authentication, drone service authorization, drone policy management, airspace drone traffic control, etc.). USS and UTM can be the same network element or entity, and can be in a containment or contained relationship, or a parallel relationship. This application does not limit this. In the embodiments of this application, USS, UTM, USS / UTM refer to the same network element or the same entity, and its name may be a server, application server, or service entity, etc.

[0141] 5. UAS NF: UAS network functions are supported by the NEF and are used for USS external services. The UAS NF leverages existing NEF business exposure services for drone authentication / authorization, drone flight authorization, drone-drone pairing authorization, and related re-authentication / re-authorization and revocation; and for location reporting, status monitoring, obtaining a list of aerial photography terminals within a geographic area, and QoS / traffic filtering control for C2 communications.

[0142] In addition, a dedicated NEF can be deployed to provide UAS NF functions, that is, to support UAS-specific features / application programming interfaces (APIs) and NEF-specific features / APIs for providing capability exposure services to the USS. In the embodiments of the present application, UAS NF, NEF, and UAS NF / NEF refer to the same network element or the same entity, which may be named network function entity, etc.

[0143] 6. TPAE: A third-party authorized entity that can identify and / or track UAVs and check for illegal UAVs within a certain range.

[0144] As shown in Figure 2, taking the 5G system as an example, the USS can communicate with the 5GC through the UAS NF / NEF on the one hand, and can also connect to the UPF through the N6 interface to transmit data on the other hand.

[0145] If a UAV wishes to connect to the internet and communicate with a UAVC, it must first be authenticated and authorized. This involves determining the legality of the UAV itself. Then, C2 communication authorization and management are required, determining whether communication between the UAV and the UAVC is permitted, along with other possible authorizations, such as the legality of the flight path. The decision makers for both UAV authentication and C2 communication authorization are the USS / UTM. In other words, in current technology, a single USS (UTM) manages and controls the drone, managing its C2 communications and related authentication and authorization. UAV authentication and authorization can be performed during either the registration process or the session establishment process.

[0146] Figure 3 is a flow chart of an example of a UAV authentication and authorization method in the prior art. As shown in Figure 3, the process includes steps 1 to 6, wherein the steps involved in the dotted boxes or dotted arrows indicate that the steps are optional steps.

[0147] Step 1: The UAV (ie, UE) sends a registration request message to the AMF, which carries the UAV's current civil aviation administration level UAV identification (CAA-Level UAV ID).

[0148] A UAV needs to be assigned a CAA-Level UAV ID within a flight domain (such as the USS). This identification information is used for remote identification and tracking of the drone. The CAA-Level UAV ID is a 3GPP network external identifier, issued by the Civil Aviation Administration of China to uniquely identify a UAV. For example, the CAA-Level UAV ID can be independently assigned by the USS / UTM, or it can be assigned by the 3GPP system with the assistance of the USS / UTM, or it can be assigned by other means.

[0149] Optionally, the registration request message may also include USS identification information (e.g., USS address), which is used by the core network to find the USS corresponding to the UAV for USS UAV authorization / authentication (UUAA) process. In some cases, the registration request message may not include USS identification information (e.g., USS address), in which case the core network can find the corresponding USS based on the CAA-Level UAV ID. For example, the USS address here can be the IP address of the USS.

[0150] In step 2, the AMF initiates a primary authentication process to register the UAV with the network. The main purpose is to verify whether the UAV can join the network. This process may require multiple information exchanges between the UAV, AMF, and UDM to complete. This process is prior art and will not be repeated here.

[0151] Step 3: AMF determines whether to initiate the UUAA process of the UAV, that is, determines whether the UAV can perform the UUAA process.

[0152] For example, the AMF may determine whether to initiate the UUAA procedure for the UAV based on factors such as whether the registration request message carries the CAA-Level UAV ID and / or whether the UAV has aerial subscription information. For example, if the registration request message from the UAV carries the CAA-Level UAV ID and the AMF determines that the UAV has aerial subscription information (and is not expired), the UUAA procedure for the UAV may be initiated.

[0153] In step 4a, the AMF sends a registration accept message to the UAV.

[0154] In step 4b, the UAV sends a registration complete message to the AMF.

[0155] Step 5: This step is an optional step. If the UAV indicates that it supports the network slice authentication and authorization (NSSAA) process, and its request message includes the slice information of the requested S-NSSAI, and the requested slice information has not been successfully authenticated, then execute step 5. This process may require multiple information interactions between the UAV, AMF, network slice authentication and authorization function (NSSAAF) entity, and authentication, authorization, accounting proxy (AAA-P) / authentication, authorization, accounting server (AAA-S) and other network elements before it can be completed. This application solution does not involve this process.

[0156] Step 6: Execute the UUAA process. The UUAA process is detailed in Figure 4 below.

[0157] The authentication and authorization of a UAV during the registration process with the 5GS is commonly referred to as UUAA mobility management (UUAA-MM). Figure 4 is a flowchart illustrating another example of a UAV authentication and authorization method in the prior art, and is also a flowchart illustrating UUAA-MM. The flowchart includes the following steps 1 to 11, where step 1 in Figure 4 connects to step 3 or step 6 in Figure 3 .

[0158] Step 1: If it is determined that the UAV can perform UUAA authentication and authorization, the AMF triggers or initiates the corresponding UUAA-MM process.

[0159] Step 2: The AMF sends an authentication authorization (Nnef_Authentication_AuthenticateAuthorize) request message to the corresponding UAS NF / NEF. The message carries the UAV's Generic Public Subscription Identity (GPSI) and CAA-Level UAV ID. Optionally, it can also carry the USS address.

[0160] Step 3: The UAS NF / NEF continues to send an authentication authorization (Naf_Authentication_AuthenticateAuthorize) request message to the corresponding USS / UTM, which carries the GPSI and CAA-Level UAV ID of the UAV.

[0161] Step 4 is optional. Depending on the authentication method used by the USS / UTM, multiple round-trip messages may be sent between the USS / UTM and the UAV (via the UAS NF / NEF and AMF). In this embodiment, steps 4a-4f exchange a total of six authentication messages. However, more or fewer messages may be exchanged, depending on the authentication method used by the USS / UTM. In one possible approach, step 4 includes the following steps:

[0162] In step 4a, the USS / UTM sends an authentication authorization response (Naf_Authentication_AuthenticateAuthorize Response) message to the UAS NF / NEF, which carries the GPSI of the UAV and the authentication message. In step 4b, the UAS NF / NEF sends an authentication authorization response (Nnef_Authentication_AuthenticateAuthorize Response) message to the AMF, which carries the GPSI of the UAV and the authentication message. In step 4c, the AMF sends a NAS_MM Transport message to the UAV, which carries the authentication message. In step 4d, the UAV returns a NAS_MM Transport message to the AMF, which carries the authentication message. In step 4e, the AMF sends an authentication authorization request message to the UAS NF / NEF, which carries the GPSI, CAA-Level UAV ID and the authentication message of the UAV. In step 4f, the UAS NF / NEF sends an authentication authorization request message to the USS / UTM, which carries the GPSI, CAA-Level UAV ID and the authentication message of the UAV.

[0163] Step 5. Once the result of the UUAA-MM is determined (e.g., success or failure), the USS / UTM may send an authentication authorization response message to the UAS NF / NEF, which carries or includes the GPSI of the UAV, the CAA-Level UAV ID, the authentication message, and the result of the UUAA-MM (e.g., success or failure).

[0164] Step 6: The UAS NF / NEF sends an authentication authorization response message to the AMF, which carries the GPSI, CAA-Level UAVID, and the authentication result (e.g., success or failure).

[0165] Step 7a, optional step, UAS NF / NEF sends an event exposure subscription request (Namf_EventExposure_Subscribe Request) message to AMF.

[0166] Step 7b is an optional step and is a parallel step with step 7a. The UAS NF / NEF sends an event exposure unsubscribe request (Namf_EventExposure_Unsubscribe Request) message to the AMF, which carries the subscription correlation ID.

[0167] Step 8a is an optional step and corresponds to step 7a. The AMF sends an event exposure subscription response (Namf_EventExposure_Subscribe Response) message to the UAS NF / NEF, which carries the subscription association identifier.

[0168] Step 8b, an optional step, is a parallel step with step 8a and corresponds to step 7b. The AMF sends an event exposure unsubscribe response (Namf_EventExposure_Unsubscribe Response) message to the UAS NF / NEF.

[0169] Step 9: AMF sends a NAS_MM transfer message to the UAV, which carries the authentication result (e.g., success or failure).

[0170] Step 10, an optional step, performs a UAV configuration update procedure between the UAV and the AMF.

[0171] Step 11, optional step, performs a network-initiated deregistration procedure between the UAV and the AMF.

[0172] In actual applications, UAV can also perform authentication and authorization during the establishment of the PDU session. We call this process the UUAA session management (UUAA-SM) process. The difference between the UUAA-SM process and the UUAA-MM process is that the network element that performs the message forwarding operation is changed from AMF to SMF, and the signaling carried by the message is different (because the execution network element is changed). Figure 5 is a flowchart of another example of the UAV authentication and authorization method in the prior art, and is also a flowchart of UUAA-SM. The process includes the following steps 0 to 8.

[0173] In step 0, the UAV initiates a PDU session establishment request, which includes a service level device identity, such as the UAV's current CAA-Level UAV ID. Optionally, the request may also include USS identification information, such as the USS address. Optionally, the request may also include authentication data, such as the UUAA aviation payload (which contains application layer information provided by the UAS to the USS and is transparent to the 3GPP system).

[0174] The SMF determines the UUAA (i.e., UUAA-SM) that needs to initiate a PDU session establishment request to the UAS based on the DNN / S-NSSAI and CAA-Level UAV ID in the session request. In some cases, if there is no CAA-Level UAV ID in the request, the SMF will reject the session establishment request.

[0175] Step 1: SMF calls the Nnef_Authentication_AuthenticateAuthorize service operation and sends an authentication authorization request message to the UAS NF / NEF. The message includes the CAA-Level UAV ID, DNN, and S-NSSAI. It may also include the authentication server address (i.e., USS address) and UUAA aviation payload (if it is provided by the UAV), GPSI, and UAV location (optional), PEI (if available), and UAV IP address (if available). The UAV location is the user location information provided by the AMF (e.g., cell ID). The UAS NF / NEF selects the corresponding USS based on the CAA-Level UAV ID or the authentication server address (i.e., USS address).

[0176] Step 2: The UAS NF / NEF calls the Naf_Authentication_AuthenticateAuthorize service operation and forwards the authentication authorization request message received from the SMF to the corresponding USS.

[0177] Step 3 is optional. Depending on the authentication method used by the USS / UTM, multiple round-trip messages may be sent between the USS / UTM and the UAV (via the UAS NF / NEF and AMF). In one possible approach, Step 3 includes the following steps:

[0178] In step 3a, USS / UTM sends an authentication authorization response message to UAS NF / NEF; in step 3b, UAS NF / NEF forwards the authentication authorization response message to AMF; in step 3c, N1 N2 message transmission (Namf_communication_N1 N2 message transfer) is performed between ANF and SMF; in step 3d, AMF sends a NAS_MM transmission message to UAV, which carries the authentication message; in step 3e, UAV returns a NAS_MM transmission message to AMF, which carries the authentication message; in step 3f, ANF and SMF exchange PDU session update SM context information - N1 SM message (Nsmf_PDUsession_UpdateSMcontext (N1 SM message)); in step 3g, SMF sends an authentication authorization request message to UAS NF / NEF; in step 3h, UAS NF / NEF forwards the authentication authorization request message to USS / UTM.

[0179] In step 4, the USS calls the Naf_Authentication_AuthenticateAuthorize service operation and sends an authentication authorization response message to the UAS NF / NEF, which includes the GPSI, CAA-Level UAV ID, and the authentication result (e.g., success or failure). In addition, the response message can also indicate whether the network resources related to the UAS service can be released in the event of a UUAA failure. Optionally, the message can also include the requested policy information and the UUAA authorization payload. The policy information requested from the USS can include the DN authorization profile index and / or the DN authorization session aggregate maximum bit rate (AMBR).

[0180] In step 5, the UAS NF / NEF confirms that the authentication / authorization of the PDU session is successful. The UAS NF / NEF stores the UUAA result together with the GPSI. The UAS NF / NEF sends an Authentication Authorization Response message to the SMF, which carries the GPSI, CAA-Level UAVID, and the authentication result (e.g., success or failure).

[0181] Step 6: Optionally, PDU session subscription process.

[0182] Step 7: Continue the PDU session establishment process. In this process, the SMF sends the authentication result (e.g., success or failure), CAA-Level UAV ID, and authorization receipt (i.e., UUAA authorization payload) to the UAV.

[0183] Step 8: Optionally, PDU session subscription result notification process.

[0184] After the UUAA process is successful, in some cases, the UAV may need to perform a re-authentication process in the 5GS. Figure 6 is a schematic diagram of the process of UAV re-authentication in the 5GS in the prior art. As shown in Figure 6, the process includes steps 0 to 6.

[0185] Step 0: After the UUAA-MM or UUAA-SM process is successful, the UAS NF / NEF may store the UAV's UUAA context. The UAV UUAA context may include any one or more of the following: GPSI, CAA-Level UAV ID, UAV IP address, and the corresponding AMF and SMF identifiers.

[0186] Step 1: The USS / UTM sends an authentication notification (Naf_Authentication_Notification) request message to the UAS NF / NEF to request re-authentication of the UAV. The request message can carry any one or more information such as GPSI, CAA-Level UAV ID, PDU session IP address, etc.

[0187] Step 2: The UAS NF / NEF determines the corresponding AMF / SMF. At this point, the UAS NF / NEF can first obtain the stored UUAA context, and then determine the corresponding AMF / SMF from the UUAA context based on the GPSI or CAA-Level UAV ID carried in the request message, that is, determine the target AMF / SMF.

[0188] In step 3a, the UAS NF / NEF sends an Nnef_Authentication_Notification message to the target AMF, instructing the AMF to initiate a re-authentication process for the UAV. For example, the request message may carry any one or more of the following information: GPSI, re-authentication data, and UUAA authorization payload.

[0189] In step 3b, the UAS NF / NEF sends an authentication notification (Nnef_Authentication_Notification) message to the target SMF, instructing the SMF to initiate the re-authentication process for the UAV. For example, the request message may carry any one or more of the following information: GPSI, PDU session identifier, re-authentication data, and UUAA authorization payload.

[0190] Step 4: The UAS NF / NEF sends an authentication notification response message to the USS / UTM, indicating that the re-authentication request is successfully initiated.

[0191] Step 5, optional step, if the UAV is currently in CM-IDLE state, the target AMF / SMF initiates (triggers) the service request process.

[0192] Step 6a, corresponding to the aforementioned step 3a, the AMF initiates the re-authentication (UUAA-MM) process of the UAV.

[0193] Step 6b, corresponding to the aforementioned step 3b, the SMF initiates the re-authentication (UUAA-SM) process of the UAV.

[0194] Previous standard discussions assumed that drones only flew within a single USS service area and therefore only needed to request authentication from the USS corresponding to that service area. However, with the improvement of drone performance and the development of communication technology, multiple USS service areas may exist along a drone's flight path. This means that a drone may switch from its original service area to a new one. Since a USS is responsible for only one service area, switching USSs during flight is a common scenario.

[0195] Figure 7 shows a schematic diagram of an application scenario applicable to an embodiment of the present application. As an example, as shown in Figure 7, a drone may fly from service area #1, which is managed by USS#1, to service area #2, which is managed by USS#2. Accordingly, the USS providing services to the drone is also switched from USS#1 to USS#2. Within service area #2, if the drone needs to obtain the corresponding services provided by USS#2, USS#2 needs to authenticate and authorize the drone.

[0196] In the scenario where the USS providing services for a drone switches from the source USS (i.e., USS#1) to the target USS (i.e., USS#2), how to enable the target USS to authenticate and authorize the drone in a timely manner to ensure the continuity of the drone's flight service has become a technical problem to be solved.

[0197] In view of this, an embodiment of the present application provides an authentication method, which is applied in a scenario or process in which a drone switches from a source server (e.g., a source USS) to a target server (e.g., a target USS). According to the authentication method, when a drone switches from a source server to a target server, a first device in the network (e.g., the drone itself, AMF / SMF, or UAS NF / NEF) first obtains a first identifier corresponding to the target server. The first identifier is used to identify the drone. For example, the first identifier can be a CAA-Level UAV ID assigned to the drone by the target server. The first identifier is then sent to the target server so that the target server can authenticate or re-authenticate the drone in a timely manner based on the first identifier. The authentication method provided in the embodiment of the present application enables the target server to authenticate and authorize the drone in a timely manner, so that the drone can obtain the flight service provided by the target server in a timely manner, ensure the continuity of the drone flight service, and improve the safety of the drone flight.

[0198] For example, as shown in Figure 7, when a drone flies from service area #1, which is managed by USS#1, to service area #2, which is managed by USS#2, or in other words, when the USS providing services for the drone switches from USS#1 to USS#2, the AMF that provides access and mobility management for the drone can obtain the first identifier corresponding to USS#2, which can be, for example, the CAA-Level UAV ID previously assigned to the drone by USS#2, and send the first identifier to USS#2. In this way, USS#2 can authenticate or re-authenticate the drone in a timely manner based on the first identifier, so that the drone can obtain the flight service provided by USS#2 in a timely manner, ensure the continuity of the drone flight service, and improve the safety of the drone flight.

[0199] The following is a more detailed description of the authentication method provided in the embodiment of the present application with reference to the accompanying drawings. The drone in the embodiment can be the UE or UAV in Figures 1-6; the first device in the embodiment can be the UE or UAV in Figures 1-6 (that is, the first device is the drone itself), or it can be the AMF or SMF in Figures 1-6, and it can also be the UAS NF or NEF in Figures 1-6.

[0200] FIG8 is a schematic flow chart of an authentication method 100 provided in an embodiment of the present application. The following describes the authentication method 100 provided in an embodiment of the present application in conjunction with FIG8 . The method 100 is applied in a scenario where a drone switches from a source server to a target server, specifically including:

[0201] In step 110, the first device obtains a first identifier corresponding to the target server, where the first identifier is used to identify the drone.

[0202] Among them, drones correspond to multiple servers, and drones can connect to or switch to different servers, with different servers providing flight services for the drone in turn. For example, when the drone is flying within the service area of ​​the source server, the source server can provide flight services for the drone, while when the drone is flying within the service area of ​​the target server, the target server can provide flight services for the drone. In other words, when the drone flies from the service area of ​​the source server to the service area of ​​the target server, the server providing services for the drone will switch, that is, the drone will switch from the source server to the target server.

[0203] Among them, the first identifier can be the identifier of the drone. Optionally, the first identifier can be assigned to the drone by the target server and can uniquely identify the drone within the aviation domain corresponding to the target server. For example, the first identifier can be the CAA-Level UAV ID assigned to the drone by the target server, but is not limited to this.

[0204] Among them, the server can be an application server or an application function network element, for example, it can be the aforementioned USS. Therefore, the source server can be a source USS (source USS, S-USS), and the target server can be a target USS (target USS, T-USS). In one possible implementation, the server here can also be a UTM, for example, the source server can be a source UTM (source UTM, S-UTM), and the target server can be a target UTM (target USS, T-UTM). It can be understood that the server here indicates an application server or application function network element that can assign a drone identifier to a drone and optionally provide drone services. In another possible implementation, the server here can also only provide drone services to the drone without assigning an identifier. In this case, the drone identifier can be assigned or provided by other servers or devices.

[0205] The first device can be any device that can obtain the first identifier and send the first identifier to the target server. Alternatively, the first device can be any device on the link connecting the drone and the server. For example, the first device can be the AMF in the UUAA-MM process in Figure 4, or the SMF in the UUAA-SM process in Figure 5. The first device can also be a UAS NF or NEF. In addition, the first device can also be the drone itself.

[0206] Among them, the first device can obtain the first identifier corresponding to the target server in any way, for example, the first device can request the first identifier from other devices through the network, or obtain the first identifier from local storage. This application does not specifically limit the acquisition method.

[0207] In step 120, the first device sends the first identifier to the target server, and the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0208] Accordingly, the target server receives the first identifier from the first device. Further, the target server can authenticate or re-authenticate the drone based on the first identifier.

[0209] Among them, the first device sends a first identifier to the target server, which may be the first device sending an authentication request (such as the aforementioned authentication authorization request) message to the target server, and the request message carries the first identifier. After the target server receives the request message, it responds to the request message and uses the first identifier to authenticate or re-authenticate the drone. Among them, the drone can have multiple identifiers, and the multiple identifiers are all used to identify the drone. Optionally, the identifiers of multiple drones can correspond one-to-one with multiple servers. For example, the identifier of a drone corresponding to a certain server can be assigned to the drone by the server, and can uniquely identify the drone within the aviation domain corresponding to the server. For example, the multiple identifiers of a drone can be multiple CAA-Level UAV IDs assigned to the drone by multiple servers, but is not limited to this.

[0210] The drone in the embodiment of the present application corresponds to multiple servers, and the drone can be connected to or switched to different servers, and different servers will provide flight services for the drone in turn. When the drone switches from the source server to the target server, the target server first needs to authenticate the drone, and only after the authentication is successful will it provide the corresponding flight service. It is easy to understand that different servers for drones usually correspond to different drone identifiers, and the target server must use the identifier of the drone corresponding to the drone in the target server (i.e., the first identifier) ​​to authenticate the drone before the authentication is successful. Here, the identifiers of multiple drones, including the first identifier, are used to identify the drone. The identifier of the drone can, for example, be the CAA-Level UAV ID, the identifier of the Civil Aviation Administration-level drone, but is not limited to this. The identifier of the drone is assigned to the drone by the server, which at least ensures that the drone is uniquely identified within the scope of one server.

[0211] On this basis, according to the authentication method 100 provided in the embodiment of the present application, when the drone switches from the source server to the target server, the first device can obtain the first identifier corresponding to the target server, which is used to identify the drone, and send the first identifier to the target server, so that the target server can promptly authenticate or re-authenticate the drone based on the first identifier, so that the drone can promptly obtain the flight service provided by the target server, ensure the continuity of the drone flight service, and improve the safety of the drone flight.

[0212] Figure 9 is a schematic flow chart of an authentication method 200 provided in an embodiment of the present application. Method 200 can be viewed as a more specific and lower-level implementation of the aforementioned method 100. Compared to method 100 shown in Figure 8 , method 200 provided in this embodiment exemplifies how the first device determines that the drone has been switched from the source server to the target server, and provides a possible method for the first device to obtain the first identifier.

[0213] According to the method 200 provided in this embodiment, a first device may receive first indication information from another device, the first indication information being used to instruct a drone to switch from a source server to a target server. The first device may determine that a switch has occurred based on the first indication information, and in response to the determination or the receipt of the first indication information, the first device may send a first message to a second device requesting a first identifier, and then send the first identifier from the second device to the target server, so that the target server can authenticate or re-authenticate the drone based on the first identifier.

[0214] 9 , an authentication method 200 provided in an embodiment of the present application is described below. The method 200 includes:

[0215] In step 210, the first device receives first indication information, where the first indication information is used to instruct the drone to switch from the source server to the target server.

[0216] Step 220, in response to the first indication information, the first device sends the first information to the second device, or the first device sends the first information to the second device according to the first indication information, the first information is used to request the first identifier corresponding to the target server, and the first identifier is used to identify the drone.

[0217] Accordingly, in step 220 , the second device receives the first information from the first device.

[0218] Step 230: In response to the first information, the second device sends a first identifier to the first device.

[0219] Accordingly, in step 230, the first device receives the first identifier from the second device, and the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0220] Step 240: The first device sends the first identifier to the target server.

[0221] Accordingly, in step 240 , the target server receives the first identifier from the first device.

[0222] In one possible manner, the first device receives first indication information from other devices, and the first indication information is used to instruct the drone to switch from the source server to the target server, or to instruct the drone to move out of the service area of ​​the source server and / or move into the service area of ​​the target server; or, the first indication information is used to indicate the current target server of the drone. After the first device receives the first indication information, it can determine that the server providing services for the drone has switched based on the first indication information. In this way, the first device will obtain the first identifier corresponding to the target server. In an embodiment of the present application, the first device can request the first identifier from the second device. That is, the first device can send the first information for requesting the first identifier to the second device, and the second device sends the first identifier to the first device based on the first information. After obtaining the first identifier, the first device sends the first identifier to the target server so that the target server uses the first identifier to authenticate or re-authenticate the drone.

[0223] In this embodiment, upon receiving the first indication information, the first device obtains the first identifier corresponding to the target server. In other words, the first device obtains the first identifier corresponding to the target server based on the first indication information. Steps 220 and 230 in method 200 can be considered substeps of step 110, specifically, a specific implementation of obtaining the first identifier.

[0224] In an embodiment of the present application, a first device may receive first indication information from a third device and, based on the first indication information, send first information to a second device to request a first identifier corresponding to a target server. Here, the second device and the third device may be any network element or device related to drone flight management in a network system. For example, the second device and the third device may be other devices other than the first device on a link connecting the drone to the server. For example, the second device may be a drone and the third device may be a target server.

[0225] Optionally, in combination with the relevant content of Figures 3 to 6 above, the first device can be AMF / SMF, the second device can be a drone, and the third device can be a UAS NF / NEF or a target server (such as T-USS). For example, when the third device is the target server, the target server can send the first indication information to AMF / SMF through UAS NF / NEF, and AMF / SMF determines that the drone switches from the source server to the target server based on the first indication information, and then requests the first identifier from the drone. Among them, UAS NF / NEF can transparently forward the first indication information, that is, UAS NF / NEF sends the first indication information to AMF / SMF by transparent transmission (UAS NF / NEF does not perceive the first indication information). The first indication information can be carried in the authentication notification message.

[0226] Optionally, in combination with the relevant content of Figures 3 to 6 above, the first device may be a UAS NF / NEF, the second device may be an AMF / SMF or a drone, and the third device may be a target server (e.g., T-USS). For example, the target server may send a first indication message to the UAS NF / NEF, and the UAS NF / NEF determines, based on the first indication message, that the drone switches from the source server to the target server, and then requests the first identifier from the AMF / SMF or the drone. The UAS NF / NEF may send a first message to the AMF / SMF to request the first identifier, and the AMF / SMF returns the first identifier to the UAS NF / NEF based on the request message (i.e., the second device is the AMF / SMF). Alternatively, the UAS NF / NEF may also send a first message to the drone through AMF / SMF to request a first identifier, and the AMF / SMF may transparently forward the first message, that is, the AMF / SMF sends the first information to the drone through transparent transmission (the AMF / SMF does not perceive the first information), and the drone returns the first identifier to the UAS NF / NEF through AMF / SMF in a transparent transmission manner based on the first information.

[0227] Optionally, the first indication information may be carried in the authentication notification message. For example, the system or protocol may stipulate that the first indication information may be "0" or "1" on a specific bit in the message. After the first device receives the authentication notification message, it reads the value on the specific bit, that is, determines that the drone switches from the source server to the target server based on the value (for example, "0" or "1").

[0228] Optionally, the first indication information may include a reason value for authentication or re-authentication, which may be "0" or "1" on a specific bit in the message. For example, when the value on the bit is "1", it indicates that the authentication or re-authentication process is triggered due to server switching (that is, the reason for authentication or re-authentication is due to server switching), and when the value on the bit is "0", it indicates that the authentication or re-authentication process is triggered by other reasons. For example, at this time, no server switching occurs but the source server triggers the authentication or re-authentication process due to other reasons.

[0229] Optionally, the first indication information includes an identifier of the target server.

[0230] Through the above settings, the first device can determine that the drone switches from the source server to the target server based on the first indication information, and / or can determine which specific server (i.e., the target server) is after switching based on the first indication information. For the first device, in one possible implementation, the first device does not need to use other information (such as the location information of the drone) to determine which specific target server is. This helps the first device to obtain the first identifier corresponding to the target server more efficiently and timely.

[0231] Optionally, the identifier of the target server may be any information that can uniquely identify the server, and the first device or the second device can clearly know which of the multiple servers the target server is based on the identifier. For example, the identifier of the target server may be the address of the target server, such as an Internet Protocol (IP) address, or a fully qualified domain name (FQDN), but is not limited thereto.

[0232] Optionally, the first information includes the identifier of the target server and / or the second indication information, and the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0233] Through the above settings, the second device can determine the specific server after switching (i.e., the target server) based on the first information. At this time, the second device does not need to use other information (such as the location information of the drone) to determine the specific target server. This helps the second device to obtain and send the first identifier corresponding to the target server to the first device more efficiently and timely.

[0234] Figure 10 is a schematic flow chart of an authentication method 300 provided in an embodiment of the present application. Method 300 can be viewed as a more specific and lower-level implementation of the aforementioned method 100. Compared to method 100 shown in Figure 8 , method 300 provided in this embodiment exemplifies how the first device determines that the drone has been switched from the source server to the target server, and provides a possible method for the first device to obtain the first identifier.

[0235] In addition, compared to the method 200 shown in FIG9 , the first device in the embodiment of the present application does not need to determine that the drone is switched from the source server to the target server through the first indication information sent by other devices, and does not need to obtain the first identifier with the help of other devices. The solution of the aforementioned method 200 mainly reflects that the first device passively initiates the (re)authentication process for the drone under the instruction of other devices, while the solution of the method 300 provided in this embodiment mainly reflects that the first device can actively initiate the (re)authentication process for the drone.

[0236] According to the method 300 provided in this embodiment, the first device determines or senses that the drone is switched from the source server to the target server, and determines the first identifier corresponding to the target server based on the identifier of the target server and a pre-stored first mapping relationship. The first mapping relationship includes a correspondence between the identifier of the target server and the first identifier. For example, the first mapping relationship may include a correspondence between multiple servers and identifiers of multiple drones, for example, the first mapping relationship may include a correspondence between multiple USSs and multiple CAA-Level UAV IDs.

[0237] The following describes an authentication method 300 provided in an embodiment of the present application with reference to FIG10 . The method 300 includes:

[0238] In step 310 , the first device determines that the drone is switched from the source server to the target server.

[0239] In one possible approach, the first device can independently determine that the drone is switched from the source server to the target server without resorting to the aforementioned first indication information. This application does not limit the specific implementation method for the first device to determine that the drone is switched from the source server to the target server. For example, the first device can determine that the drone is switched from the source server to the target server based on the drone's location information, but is not limited to this.

[0240] In one possible approach, the first device may first obtain the location information of the drone, and then, based on the location information and the service area corresponding to the target server, determine whether the drone is switched from the source server to the target server. The source server and the target server each correspond to a different service area. When the first device determines, based on the drone's location information, that the drone has flown from the service area of ​​the source server to the service area of ​​the target server, it may determine that the server providing service for the drone has switched from the source server to the target server, i.e., the drone has switched from the source server to the target server.

[0241] Optionally, the first device can be the drone itself. In this case, the first device knows its own location information and can determine, based on its own location information, whether the drone switches from the service area corresponding to the source server to the service area corresponding to the target server, and thus can determine whether the drone switches from the source server to the target server.

[0242] Optionally, the first device can be AMF / SMF, in which case the AMF / SMF itself may store the location information of the drone, or the AMF / SMF can obtain (request) location information from the drone, or the AMF / SMF can subscribe to the location information of the drone, and then determine that the drone is switched from the service area corresponding to the source server to the service area corresponding to the target server based on the location information, that is, it can be determined that the drone is switched from the source server to the target server.

[0243] Optionally, the first device may also be a UAS NF / NEF, in which case the UAS NF / NEF may subscribe to the location information of the drone. In one possible implementation, the location information of the drone may be subscribed to the AMF. The UAS NF / NEF uses the location information of different servers as different areas of interest (AoI), and subscribes to the AMF to determine whether the drone is in the area of ​​interest, that is, subscribes to the UE presence in AoI to the AMF. When the UAV moves out of / into the corresponding area of ​​interest, the AMF initiates a notification to the UAS NF / NEF, instructing the UAV to move out (out) / into (in) the corresponding area of ​​interest. Thus, the UAS NF / NEF can determine that the drone has moved out of the service area corresponding to the source server and entered the service area corresponding to the target server based on the location information of the drone. For example, the UAS NF / NEF can determine that the drone has switched from the source server to the target server.

[0244] In step 320, the first device determines a first identifier based on the identifier of the target server and the first mapping relationship. The first mapping relationship includes a correspondence between the identifier of the target server and the first identifier. The first identifier is used to identify the drone, and details can be found in the aforementioned related description.

[0245] In one possible approach, the first device may pre-store or configure a first mapping relationship locally, the first mapping relationship including a correspondence between the identifier of the target server and the first identifier. In this way, the first device may first obtain the identifier of the target server and then determine the first identifier based on the identifier of the target server.

[0246] Alternatively, the target server identifier can be determined based on the drone's location information. The first device can determine the drone's current service area based on the drone's location information. The server corresponding to the service area is the target server, and the target server identifier can be determined. Alternatively, the target server identifier can be proactively sent to the first device by another device, or obtained by the first device through a request from another device.

[0247] Optionally, the first mapping relationship can also be used to indicate the correspondence between the identifiers of multiple servers and the identifiers of multiple drones, where the identifiers of the multiple drones are used to identify the drone, and the multiple servers are used to provide services for the drone and include the target server. Any one of the multiple servers must use the identifier of the drone corresponding to itself to authenticate the drone before the authentication is successful. Exemplarily, there can be a one-to-one correspondence between the identifiers of multiple servers and the identifiers of multiple drones, but this application does not exclude the situation where multiple (for example, two or three) servers share the identifier of a drone (that is, multiple servers correspond to the identifier of one drone), and does not exclude the situation where a server can use the identifiers of multiple (for example, two or three) different drones to authenticate the drone (that is, one server corresponds to the identifiers of multiple drones).

[0248] Optionally, the first mapping relationship may include a correspondence between the identifiers of multiple USSs (i.e., USS lists) and multiple CAA-Level UAV IDs. That is, the identifiers of multiple drones may be multiple CAA-Level UAV IDs, and the identifier of the drone corresponding to each USS is the CAA-Level UAV ID assigned by the USS to the drone. The first identifier is the CAA-Level UAV ID assigned by the target server (T-USS) to the drone.

[0249] Optionally, the first device may be the drone itself, and the first mapping relationship may be pre-configured by the manufacturer before the drone leaves the factory; or the first mapping relationship may be configured through the application layer (application software).

[0250] Optionally, the first device may be an AMF / SMF, or may be a UAS NF / NEF. In this case, the first device may obtain the first mapping relationship in advance from the drone or from the application server, for example, through a UUAA-MM process or a UUAA-SM process.

[0251] In step 330, the first device sends the first identifier to the target server. The first identifier is used by the target server to authenticate or re-authenticate the drone.

[0252] Accordingly, in step 330, the target server receives the first identifier from the first device. For details, please refer to the above description of steps 120 and 240.

[0253] It is worth noting that the method 300 provided in the embodiment of the present application can be combined with the aforementioned method 200. For example, the first device can determine that the drone is switching from the source server to the target server based on the received first indication information, and then the first device can determine the first identifier based on the identifier of the target server and the first mapping relationship. For another example, the first device can also independently determine that the drone is switching from the source server to the target server without the need for instructions from other devices, and then send the first information to the second device to request the first identifier.

[0254] Figure 11 is a schematic flow chart of an authentication method 400 provided in an embodiment of the present application. Method 400 can be viewed as a more specific and lower-level implementation of methods 100-300 described above. In method 400, the AMF corresponds to the first device in methods 100-300, the UAV corresponds to the second device in methods 100-300, and the T-USS or UAS NF / NEF corresponds to the third device in methods 100-300.

[0255] The following describes an authentication method 400 provided in an embodiment of the present application with reference to FIG11 . The method 400 includes:

[0256] Step 401: Configure a second mapping relationship for the drone.

[0257] The second mapping relationship may include a correspondence between the identifiers of multiple USSs and multiple CAA-Level UAV IDs. The multiple USSs are used to provide flight services for the drone, and the multiple USSs may be USSs on the flight path of the drone. Each CAA-Level UAV ID in the second mapping relationship may be allocated to the drone by the corresponding USS. Exemplarily, the multiple USSs include USS#1 and USS#2. In the second mapping relationship, the identifier of the drone corresponding to USS#1 is the first identifier, and the identifier of the drone corresponding to USS#2 is the second identifier.

[0258] Optionally, in some cases, the CAA-Level UAV ID may include the identification information of its corresponding USS, that is, the CAA-Level UAV ID may include or indicate the correspondence between the UAV ID and the USS identification, or in other words, the USS corresponding to the UAV ID can be determined based on the CAA-Level UAV ID (that is, the corresponding USS identification is determined). Therefore, the second mapping relationship in the embodiment of the present application may, for example, include multiple CAA-Level UAV IDs, and configuring the second mapping relationship may be configuring multiple CAA-Level UAV IDs of the drone (that is, there is no need to additionally configure the corresponding multiple USSs).

[0259] Optionally, the second mapping relationship may be pre-configured by the manufacturer before the drone leaves the factory; or the second mapping relationship may be configured through the application layer (application software).

[0260] Step 402: The UAV sends a registration request message to the AMF, where the message carries the second identifier.

[0261] Among them, the drone can determine that it is currently in the service area of ​​USS#2 based on its own location information, and the second identifier is the CAA-Level UAV ID corresponding to USS#2.

[0262] Optionally, the registration request message may also include identification information of USS#2 (e.g., the address of USS#2), which is used to help the AMF quickly find the corresponding USS (i.e., USS#2). Exemplarily, the address of USS#2 here may be the IP address of USS#2.

[0263] In some cases, the registration request message may not include the identification information of the USS. In this case, the AMF can find the corresponding USS (i.e., USS#2) based on the USS identification information carried in the CAA-Level UAV ID.

[0264] Step 403: The AMF determines to execute or trigger the UUAA-MM process of the UAV.

[0265] For example, the AMF may determine or judge whether to execute the UUAA procedure for the UAV based on factors such as whether the UAV has aviation contract information. In this embodiment, the AMF determines to execute the UUAA-MM procedure for the UAV. The UUAA-MM procedure includes subsequent steps 404 to 408.

[0266] In step 404, the AMF sends an authentication authorization request message to the corresponding UAS NF / NEF, which carries the second identifier and the GPSI of the UAV.

[0267] Optionally, the message may also carry the address of USS#2.

[0268] In step 405, the UAS NF / NEF sends an authentication authorization request message to USS#2, where the message carries the second identifier and the GPSI of the UAV.

[0269] Step 406: USS#2 sends an authentication authorization response message to the UAS NF / NEF. The message carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (eg, success).

[0270] In step 407, the UAS NF / NEF sends an authentication authorization response message to the AMF, which carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (e.g., success).

[0271] Optionally, step 406 and step 407 can be completed by the same step or the same action, and the UAS NF / NEF can transparently forward the authentication authorization response message, that is, the UAS NF / NEF sends the authentication authorization response message from USS#2 to the AMF in a transparent manner (the UAS NF / NEF does not perceive the authentication authorization response message).

[0272] In step 408, the AMF sends a NAS_MM transmission message to the UAV, which carries the authentication result (e.g., authentication success).

[0273] Step 409: The USS providing services to the UAV is switched.

[0274] Step 409 can be understood as the USS switching process, where the UAV switches from USS#2 to USS#1. Therefore, USS#2 can also be expressed as an S-USS, and USS#1 can be expressed as a T-USS. That is, USS#2 here corresponds to the aforementioned source server or S-USS, and USS#1 here corresponds to the aforementioned target server or T-USS.

[0275] In one possible approach, USS#2 can subscribe to the UAV's location information. When USS#2 determines, based on the location information, that the UAV has moved from the service area corresponding to USS#2 to the service area corresponding to USS#1, USS#2 queries the IP address of USS#1 and performs UAV data migration, i.e., sends the UAV's context content to USS#1, which may include the UAV's GPSI and a second identifier (optional).

[0276] In step 410, USS#1 (ie, T-USS) sends an authentication notification message to the UAS NF / NEF.

[0277] The message carries the first instruction information and the GPSI of the UAV, wherein the first instruction information is used to instruct the UAV to switch from USS#2 to USS#1. The first instruction information can be referred to the relevant description above and will not be repeated here.

[0278] In step 411, the UAS NF / NEF sends an authentication notification message to the AMF, which carries the first indication information and the GPSI of the UAV.

[0279] Step 412: After the AMF receives the first indication information, it determines, based on the first indication information, that the server providing services for the UAV has been switched.

[0280] Furthermore, the AMF sends a first message to the UAV requesting a first identifier, which is the CAA-Level UAV ID corresponding to USS#1. The first information can be referred to the relevant description above and will not be repeated here.

[0281] Step 413: In response to the first information, the UAV determines a first identifier.

[0282] In one possible way, the UAV can first determine the current service area based on the current location information. The USS corresponding to the service area is USS#1 (T-USS), and then the identifier of USS#1 can be determined. Afterwards, the UAV can determine the CAA-Level UAV ID corresponding to the identifier of USS#1 based on the first mapping relationship in the second mapping relationship (for example, a mapping relationship table), and the determined CAA-Level UAV ID is the first identifier. Among them, the first mapping relationship includes the correspondence between USS#1 and the first identifier. The first mapping relationship can refer to the relevant statements in the aforementioned method 300. Here, the first mapping relationship is included in the second mapping relationship, and the first identifier corresponding to USS#1 can be determined based on the second mapping relationship.

[0283] Step 414: The UAV sends the first identifier to the AMF.

[0284] Step 415: The AMF initiates an authentication or re-authentication request based on the first identifier.

[0285] That is, an authentication authorization request message is sent to the UAS NF / NEF, which carries the first identifier, the GPSI of the UAV, etc. Optionally, it may also carry the address of USS#1.

[0286] Optionally, before step 415, the AMF further determines whether to initiate the UUAA-MM procedure for the UAV again based on factors such as whether the UAV has aviation contract information. That is, the actions of step 403 are repeated, and step 415 is performed only after it is determined that the UUAA-MM procedure can be initiated.

[0287] In step 416, the UAS NF / NEF sends an authentication authorization request message to the T-USS. The message carries the first identifier, the GPSI of the UAV, and other contents.

[0288] Optionally, step 415 and step 416 can be completed by the same step or the same action, and the UAS NF / NEF can transparently forward the authentication authorization request message, that is, the UAS NF / NEF sends the authentication authorization request message from the AMF to the T-USS by transparent transmission (the UAS NF / NEF does not perceive the authentication authorization request message).

[0289] As a variation of method 400, the UAV can determine, based on its own location information, that the USS providing the service is switched from USS#2 to USS#1 (i.e., from S-USS to T-USS), and actively initiate an authentication or re-authentication request. Specifically, the UAV can determine, based on its own location information, that it is switching from USS#1 to USS#2, and obtain the first identifier corresponding to USS#1 based on the location information and the first mapping relationship, and then send the first identifier to USS#1, i.e., initiate the UUAA-MM process again (re-execute step 402 and subsequent steps). In this case, steps 410-412 can be omitted.

[0290] Figure 12 is a schematic flow chart of an authentication method 500 provided in an embodiment of the present application. Method 500 can be viewed as a more specific and lower-level implementation of the aforementioned methods 100-300. In method 500, the UAS NF / NEF corresponds to the first device in the aforementioned methods 100-300, the UAV or AMF corresponds to the second device in the aforementioned methods 100-300, and the T-USS corresponds to the third device in the aforementioned methods 100-300.

[0291] The following describes an authentication method 500 provided in an embodiment of the present application with reference to FIG12 . The method 500 includes:

[0292] Steps 501 to 509 are the same as steps 401 to 406 in the aforementioned method 400 . Please refer to the relevant descriptions above and will not be repeated here.

[0293] In step 510, USS#1 sends an authentication notification message to the UAS NF / NEF, which carries first indication information and the GPSI of the UAV. The first indication information is used to instruct the UAV to switch from USS#2 to USS#1, and the first indication information includes the identifier of USS#1.

[0294] In step 511, the UAS NF / NEF determines the server currently providing services to the UAV according to the first indication information, or determines that the server currently providing services to the UAV is switched.

[0295] The server switching in step 511 can be understood as the UAV switching from USS#2 to USS#1.

[0296] The UAS NF / NEF may determine that the UAV has switched from USS#2 to USS#1 based on the identifier of USS#1 in the first indication information (e.g., the IP address of USS#1). For example, the UAS NF / NEF compares the identifier of USS#1 with the currently stored identifier of USS#2. Due to inconsistency in the comparison results, it can be determined that the IP address of the USS has changed, that is, it can be determined that the UAV has switched from USS#2 to USS#1.

[0297] In step 512, the UAS NF / NEF sends a first message to the AMF requesting a first identifier, which is the CAA-Level UAV ID corresponding to USS#1.

[0298] Step 513: The AMF sends the first information to the UAV.

[0299] Optionally, step 512 and step 513 can be completed by the same step or the same action, and the AMF can transparently forward the first information, that is, the AMF sends the first information from the UAS NF / NEF to the UAV by transparent transmission (the AMF does not perceive the first information).

[0300] Optionally, if the AMF itself can obtain or has the first identifier, it can directly send the first identifier to the UAS NF / NEF without performing step 513. In one possible implementation, the specific acquisition method can be found in the description of steps 603 and 613 in method 600 below.

[0301] Step 514: In response to the first information, the UAV determines a first identifier.

[0302] The specific implementation process can be found in the above description of step 413, which will not be repeated here.

[0303] Step 515: The UAV sends a first identifier to the AMF.

[0304] Step 516: The AMF sends the first identifier to the UAS NF / NEF.

[0305] Similarly, step 515 and step 516 can be completed by the same step or the same action, and the AMF can transparently forward the first identifier, that is, the AMF sends the first identifier from the UAV to the UAS NF / NEF by transparent transmission (the AMF does not perceive the first identifier).

[0306] In step 517, the UAS NF / NEF initiates an authentication or re-authentication request based on the first identifier, that is, sends an authentication authorization request message to the T-USS, which carries the first identifier, the GPSI of the UAV, and other content.

[0307] As a variation of method 500, the UAS NF / NEF can determine, based on the UAV's location information, that the UAV is switching from USS#2 to USS#1, and proactively initiate an authentication or re-authentication request. Specifically, the UAS NF / NEF can determine, based on the UAV's location information, that the UAV is switching from USS#2 to USS#1 (i.e., switching from an S-USS to a T-USS), and request a first identifier from the UAV, then send the first identifier to USS#1, thereby re-initiating the UUAA-MM process (re-executing step 505 and subsequent steps). In this case, step 510 can be omitted.

[0308] In one possible implementation, the location information of the drone can be subscribed to the AMF. The UAS NF / NEF uses the location information of different servers as different areas of interest (AoI), and subscribes to the AMF to know whether the drone is in the area of ​​interest, that is, subscribes to the AMF for UE presence in AoI. When the UAV moves out of / into the corresponding area of ​​interest, the AMF initiates a notification to the UAS NF / NEF, instructing the UAV to move out (out) / into (in) the corresponding area of ​​interest. Thus, the UAS NF / NEF can determine that the drone has moved out of the service area corresponding to the source server and entered the service area corresponding to the target server based on the location information of the drone. For example, the UAS NF / NEF can determine that the drone has switched from the source server to the target server.

[0309] Figure 13 is a schematic flow chart of an authentication method 600 provided in an embodiment of the present application. Method 600 can be viewed as a more specific and lower-level implementation of methods 100 through 300 described above. In method 600, the AMF corresponds to the first device in methods 100 through 300, and the T-USS or UAS NF / NEF corresponds to the third device in methods 100 through 300.

[0310] The following describes an authentication method 600 provided in an embodiment of the present application with reference to FIG13 . The method 600 includes:

[0311] Step 601: configure the aforementioned second mapping relationship for the drone. For details, please refer to the relevant description in the aforementioned method 400.

[0312] Step 602: The UAV sends a registration request message to the AMF, where the message carries the second identifier and indication information of the second mapping relationship.

[0313] Among them, the drone can determine that it is currently in the service area of ​​USS#2 based on its own location information, and the second identifier is the CAA-Level UAV ID corresponding to USS#2.

[0314] Step 603: AMF saves the second mapping relationship, for example, saves the second mapping relationship in the context content of the UAV.

[0315] In step 604, the AMF determines to execute the UUAA-MM process of the UAV.

[0316] In step 605, the AMF sends an authentication authorization request message to the corresponding UAS NF / NEF. The message carries the second identifier, the GPSI of the UAV, and optionally the address of USS#2.

[0317] In step 606, the UAS NF / NEF sends an authentication authorization request message to USS#2, where the message carries the second identifier and the GPSI of the UAV.

[0318] Step 607: USS#2 sends an authentication authorization response message to the UAS NF / NEF. The message carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (eg, success).

[0319] In step 608, the UAS NF / NEF sends an authentication authorization response message to the AMF, which carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (e.g., success).

[0320] In step 609, the AMF sends a NAS_MM transmission message to the UAV, which carries the authentication result (e.g., authentication success).

[0321] In step 610, the USS providing service for the UAV is switched, that is, the USS switching process is performed, and the UAV is switched from USS#2 (S-USS) to USS#1 (T-USS).

[0322] In step 611, USS#1 sends an authentication notification message to the UAS NF / NEF. The message carries first indication information and the GPSI of the UAV. The first indication information is used to instruct the UAV to switch from USS#2 to USS#1, or to indicate that the UAV has moved out of the service area of ​​USS#2 and / or has moved into the service area of ​​USS#1. Alternatively, the first indication information is used to indicate that the current server of the UAV is USS#1.

[0323] In step 612, the UAS NF / NEF forwards the authentication notification message to the AMF, which carries the first indication information and the GPSI of the UAV.

[0324] In step 613, after receiving the first indication information, the AMF determines that the server providing services for the UAV has switched based on the first indication information. Then, the AMF determines the first identifier, which is the CAA-Level UAV ID corresponding to USS#1.

[0325] In one possible way, the AMF first determines the current service area based on the current location information of the drone. The USS corresponding to the service area is USS#1, and then the identifier of USS#1 can be determined. After that, the AMF determines the CAA-Level UAV ID corresponding to USS#1 based on the first mapping relationship in the second mapping relationship (for example, a mapping relationship table), and the found CAA-Level UAV ID is the first identifier. In other words, the first mapping relationship is included in the second mapping relationship, and the first identifier corresponding to USS#1 can be determined based on the second mapping relationship.

[0326] In step 614, the AMF initiates an authentication or re-authentication request based on the first identifier. Specifically, it sends an Authentication Authorization Request message to the UAS NF / NEF. The message carries the first identifier, the UAV's GPSI, and other information. Optionally, it also carries the address of USS#1.

[0327] In step 615, the UAS NF / NEF forwards the authentication authorization request message to the T-USS. The message carries the first identifier, the GPSI of the UAV, and other contents.

[0328] As a variation of method 600, the AMF can determine that UAV USS#2 switches to USS#1 based on the UAV's location information, and actively initiate an authentication or re-authentication request. Specifically, the AMF can determine that USS#2 switches to USS#1 (i.e., switches from S-USS to T-USS) based on the UAV's location information, and obtain the first identifier corresponding to USS#1 based on the location information, and then send the first identifier to USS#1, that is, initiate the UUAA-MM process again (re-execute step 605 and subsequent steps). At this time, steps 611-612 can be omitted.

[0329] Figure 14 is a schematic flow chart of an authentication method 700 provided in an embodiment of the present application. Method 700 can be viewed as a more specific and lower-level implementation of the aforementioned methods 100-300. In method 700, the UAS NF / NEF corresponds to the first device in the aforementioned methods 100-300, the AMF corresponds to the second device in the aforementioned methods 100-300, and the T-USS corresponds to the third device in the aforementioned methods 100-300.

[0330] The following describes an authentication method 700 provided in an embodiment of the present application with reference to FIG14 . The method 700 includes:

[0331] Steps 701 to 710 are the same as steps 601 to 610 in the aforementioned method 600. Please refer to the relevant descriptions in the previous text and will not be repeated here.

[0332] In step 711, USS#1 sends an authentication notification message to the UAS NF / NEF, which carries the first indication information and the GPSI of the UAV. The first indication information is used to instruct the UAV to switch from USS#2 to USS#1 (i.e., from S-USS to T-USS), and the first indication information includes the identifier of USS#1.

[0333] Step 712: The UAS NF / NEF determines, based on the first indication information, that the server providing service to the UAV is switched, that is, determines that the UAV is switched from USS#2 to USS#1.

[0334] The UAS NF / NEF may determine that the UAV has switched from USS#2 to USS#1 based on the identifier of USS#1 in the first indication information (e.g., the IP address of USS#1). For example, the UAS NF / NEF compares the identifier of USS#1 with the identifier of the currently stored USS#2. Due to inconsistency in the comparison results, it can be determined that the IP address of the USS has changed, that is, it can be determined that the UAV has switched from USS#2 to USS#1.

[0335] In step 713, the UAS NF / NEF sends a first message requesting a first identifier to the AMF. The first identifier is the CAA-Level UAV ID corresponding to USS#1. The first message also includes the identifier of USS#1.

[0336] Step 714: In response to the first information, the AMF determines the first identifier based on the identifier of USS#1 and the first mapping relationship in the second mapping relationship.

[0337] Step 715: The AMF sends the first identifier to the UAS NF / NEF.

[0338] In step 716, the UAS NF / NEF initiates an authentication or re-authentication request based on the first identifier, i.e., sends an authentication authorization request message to USS#1, which carries the first identifier, the GPSI of the UAV, and other information.

[0339] As a variation of method 700, the UAS NF / NEF can determine that the UAV is switching from USS#2 to USS#1 based on the UAV's location information, and actively initiate an authentication or re-authentication request. Specifically, the UAS NF / NEF can determine that the UAV is switching from USS#2 to USS#1 (i.e., switching from S-USS to T-USS) based on the UAV's location information, and obtain the first identifier corresponding to USS#1 based on the location information, and then send the first identifier to USS#1, i.e., initiate the UUAA-MM process again (re-execute step 706 and subsequent steps). In this case, step 711 can be omitted.

[0340] Figure 15 is a schematic flow chart of an authentication method 800 provided in an embodiment of the present application. Method 800 can be viewed as a more specific and lower-level implementation of methods 100 through 300 described above. In method 800, the UAS NF / NEF corresponds to the first device in methods 100 through 300, and the T-USS corresponds to the third device in methods 100 through 300.

[0341] The following describes an authentication method 800 provided in an embodiment of the present application with reference to FIG15 . The method 800 includes:

[0342] Step 801: Configure the aforementioned second mapping relationship for the drone.

[0343] In step 802, the UAV sends a registration request message to the AMF, which carries the second identifier and information indicating the second mapping relationship. The UAV can determine that it is currently in the service area of ​​USS#2 based on its own location information. The second identifier is the CAA-Level UAV ID corresponding to USS#2 in the second mapping relationship.

[0344] Step 803: AMF saves the second mapping relationship, for example, saves the second mapping relationship in the context content of the UAV.

[0345] In step 804, the AMF determines whether the UUAA-MM process of the UAV can be executed.

[0346] In step 805, the AMF sends an authentication authorization request message to the corresponding UAS NF / NEF. The message carries the second identifier, the GPSI of the UAV, and an indication of the second mapping relationship. Optionally, it may also carry the address of USS#2.

[0347] In step 806, the UAS NF / NEF sends an authentication authorization request message to USS#2, where the message carries the second identifier and the GPSI of the UAV.

[0348] Step 807: USS#2 sends an authentication authorization response message to the UAS NF / NEF. The message carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (eg, success).

[0349] In step 808, the UAS NF / NEF sends an authentication authorization response message to the AMF, which carries or includes the second identifier, the GPSI of the UAV, and the result of the UUAA-MM (e.g., success).

[0350] In step 809, the AMF sends a NAS_MM transmission message to the UAV, which carries the authentication result (e.g., authentication success).

[0351] In step 810, the UAS NF / NEF saves the second mapping relationship, for example, saves the second mapping relationship in the context of the UAV.

[0352] In step 811, the USS providing services for the UAV is switched, that is, the USS switching process is performed, and the UAV is switched from USS#2 to USS#1 (that is, from S-USS to T-USS).

[0353] In step 812, USS#1 sends an authentication notification message to the UAS NF / NEF, which carries the first indication information and the GPSI of the UAV. The first indication information is used to instruct the UAV to switch from USS#2 to USS#1, and the first indication information includes the identifier of USS#1.

[0354] In step 813, the UAS NF / NEF determines, based on the first indication information, that the server providing services to the UAV is switched, that is, determines that the UAV is switched from USS#2 to USS#1.

[0355] Step 814: The UAS NF / NEF determines a first identifier according to the identifier of USS#1 and the first mapping relationship in the second mapping relationship.

[0356] In step 815, the UAS NF / NEF initiates an authentication or re-authentication request based on the first identifier, i.e., sends an authentication authorization request message to USS#1, which carries the first identifier, the GPSI of the UAV, and other information.

[0357] The authentication method according to an embodiment of the present application is described in detail above with reference to Figures 1 to 15 . The following describes the apparatus according to an embodiment of the present application in detail with reference to Figures 16 to 19 . It should be understood that the apparatus shown in Figures 16 to 19 can implement one or more steps of the method flow shown in Figures 8 to 15 . To avoid repetition, detailed description is omitted here.

[0358] Figure 16 is a schematic diagram of the structure of a communication device 900 provided in an embodiment of the present application. The communication device 900 is used in a scenario where a drone switches from a source server to a target server. The communication device 900 can be the first device in the aforementioned embodiment. As shown in Figure 16, the communication device 900 includes: a processing unit 910 and a sending unit 920.

[0359] The processing unit 910 is configured to obtain a first identifier corresponding to the target server, where the first identifier is used to identify the drone.

[0360] The sending unit 920 is used to send the first identifier to the target server, where the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0361] Optionally, the communication device 900 further includes: a receiving unit 930, configured to receive first indication information, where the first indication information is used to instruct the drone to switch from the source server to the target server, or to instruct the drone to move out of the service area of ​​the source server and / or move into the service area of ​​the target server, or the first indication information is used to indicate the current target server of the drone;

[0362] The processing unit 910 is specifically configured to obtain a first identifier corresponding to the target server according to the first indication information.

[0363] Optionally, the processing unit 910 is further configured to: determine whether the drone is switched from the source server to the target server.

[0364] Optionally, the processing unit 910 is specifically configured to: obtain location information of the drone;

[0365] According to the location information and the service area corresponding to the target server, it is determined that the drone is switched from the source server to the target server.

[0366] Optionally, the first indication information includes an identifier of the target server.

[0367] Optionally, the sending unit 920 is further configured to send first information to the second device, where the first information is used to request the first identifier; and the communication apparatus 900 further comprises a receiving unit 930 configured to receive the first identifier from the second device.

[0368] Optionally, the first information includes the identifier of the target server and / or second indication information, the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0369] Optionally, the processing unit 910 is specifically configured to determine the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0370] Optionally, the communication device 900 is the drone, the access and mobility management function AMF network element, the session management function SMF network element, the drone aviation system network function UAS NF network element or the network open function NEF network element.

[0371] FIG17 is a schematic diagram of the structure of a communication device 1000 provided in an embodiment of the present application. The communication device 1000 is used in a scenario where a drone switches from a source server to a target server. The communication device 1000 may be the first device in the aforementioned embodiment. As shown in FIG17 , the communication device 1000 includes: a processor 1010, a memory 1020, and a communication interface 1030. Instructions are stored in the memory 1020, and the processor 1010 is used to execute the instructions in the memory 1020. When the instructions are executed, the processor 1010 is used to execute the method provided in any of the above method embodiments. The processor 1010 is also used to control the communication interface 1030 to communicate with the outside world.

[0372] Furthermore, the processor 1010 , the memory 1020 , and the communication interface 1030 may communicate with each other through internal connection paths to transfer control and / or data signals.

[0373] Furthermore, the memory 1020 may be integrated into the processor 1010 or may be provided separately from the processor 1010 .

[0374] In one possible approach, the communication device 1000 can be used to execute the various steps performed by the first device in the authentication method shown in Figures 8-15. The communication device 1000 may include the various units shown in Figure 16 for executing the aforementioned authentication method. Furthermore, the various modules in the communication device 1000 and the aforementioned other operations and / or functions are respectively configured to implement the corresponding processes of the authentication method shown in Figures 8-15. The specific process of each module executing the aforementioned corresponding steps has been described in detail in the method and, for the sake of brevity, will not be repeated here.

[0375] FIG18 is a schematic diagram of the structure of a communication device 1100 provided in an embodiment of the present application. The communication device 1100 is applied in a scenario where a drone switches from a source server to a target server. The communication device 1100 may be the second device in the aforementioned embodiment. As shown in FIG18 , the communication device 1100 includes: a receiving unit 1110 and a sending unit 1120.

[0376] The receiving unit 1110 is configured to receive first information from a first device, where the first information is used to request a first identifier corresponding to the target server, where the first identifier is used to identify the drone;

[0377] The sending unit 1120 is configured to send the first identifier to the first device according to the first information, wherein the first identifier is used by the target server to authenticate or re-authenticate the drone.

[0378] Optionally, the communication device 1100 further includes:

[0379] The processing unit 1130 is configured to determine the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

[0380] Optionally, the first information includes the identifier of the target server and / or second indication information, the second indication information is used to instruct the second device to send / report the first identifier corresponding to the target server, or the second indication information is used to instruct the second device to send / report the identifier of the drone corresponding to the server currently providing the service, or the second indication information is used to instruct the second device to send / report the current identification information of the drone.

[0381] Optionally, the communication device 1100 is an access and mobility management function AMF network element or a session management function SMF network element, and the first device is an unmanned aerial vehicle system network function UAS NF network element or a network open function NEF network element or a UAS service provider USS or a UAS traffic management UTM; or, the communication device 1100 is the unmanned aerial vehicle, and the first device is the AMF network element, the SMF network element, the UAS NF network element or the NEF network element.

[0382] FIG19 is a schematic diagram of the structure of a communication device 1200 provided in an embodiment of the present application. The communication device 1200 is used in a scenario where a drone switches from a source server to a target server. The communication device 1200 may be the second device in the aforementioned embodiment. As shown in FIG19 , the communication device 1200 includes: a processor 1210, a memory 1220, and a communication interface 1230. Instructions are stored in the memory 1220, and the processor 1210 is used to execute the instructions in the memory 1220. When the instructions are executed, the processor 1210 is used to execute the method provided in any of the above method embodiments. The processor 1210 is also used to control the communication interface 1230 to communicate with the outside world.

[0383] Furthermore, the processor 1210 , the memory 1220 , and the communication interface 1230 may communicate with each other through internal connection paths to transmit control and / or data signals.

[0384] Furthermore, the memory 1220 may be integrated into the processor 1210 or may be provided separately from the processor 1210 .

[0385] In one possible approach, communication device 1200 can be used to execute the various steps performed by the second device in the authentication method shown in Figures 8-15. This communication device 1200 may include the various units shown in Figure 18 for executing the aforementioned authentication method. Furthermore, the various modules in communication device 1200 and the aforementioned other operations and / or functions are respectively intended to implement the corresponding processes of the authentication method shown in Figures 8-15. The specific process by which each module executes the aforementioned corresponding steps is described in detail in the method and, for the sake of brevity, will not be repeated here.

[0386] It should be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0387] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0388] According to the method provided in the embodiments of the present application, the present application also provides a computer program product, which includes: computer program code, which, when running on a computer, enables the computer to execute the method of any one of the embodiments shown in Figures 8 to 15.

[0389] According to the method provided in the embodiments of the present application, the present application also provides a computer-readable medium, which stores program code. When the program code runs on a computer, the computer executes the method of any one of the embodiments shown in Figures 8 to 15.

[0390] According to the method provided in the embodiments of the present application, the present application also provides a chip system, including a processor, for calling and running a computer program from a memory, so that a communication device equipped with the chip system executes a method for causing a computer to execute any one of the embodiments shown in Figures 8 to 15.

[0391] According to the method provided in the embodiments of the present application, the present application also provides a system, which includes the aforementioned first device and / or second device.

[0392] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0393] For ease of understanding, the terms involved in the process of introducing the solution of this application are explained below.

[0394] In the embodiment of the present application, "indication" may include direct indication and indirect indication, and may also include explicit indication and implicit indication. The information indicated by a certain information (such as the "indication information" in the foregoing text) is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein the other information has an association relationship with the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can also be achieved by means of the arrangement order of each information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent.

[0395] In the embodiments of the present application, “first”, “second” and various numbers are only used for the convenience of description and are not intended to limit the scope of the embodiments of the present application. For example, different indication information is used to distinguish different indication information.

[0396] The “communication protocol” involved in the embodiments of the present application may refer to a standard protocol in the communication field, for example, it may include an LTE protocol, a NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0397] The term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0398] In this application, "at least one" means one or more, and "plurality" means two or more. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.

[0399] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0400] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0401] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0402] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0403] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0404] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0405] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0406] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. An authentication method, characterized in that: Application scenarios where drones switch from a source server to a target server include: The first device obtains a first identifier corresponding to the target server, where the first identifier is used to identify the drone; The first device sends the first identifier to the target server, where the first identifier is used by the target server to authenticate or re-authenticate the drone.

2. The authentication method according to claim 1, wherein: The authentication method further comprises: The first device receives first indication information, where the first indication information is used to instruct the drone to switch from the source server to the target server; The first device obtaining a first identifier corresponding to the target server includes: The first device obtains a first identifier corresponding to the target server according to the first indication information.

3. The authentication method according to claim 1, wherein: Before the first device obtains the first identifier corresponding to the target server, the method further includes: The first device determines that the drone is switched from the source server to the target server.

4. The authentication method according to claim 3, wherein: The first device determines that the drone is switched from the source server to the target server, including: The first device obtains the location information of the drone; The first device determines, based on the location information and a service area corresponding to the target server, that the drone is switched from the source server to the target server.

5. The authentication method according to claim 2, wherein: The first indication information includes an identifier of the target server.

6. The authentication method according to any one of claims 1 to 5, characterized in that: The first device obtaining a first identifier corresponding to the target server includes: The first device sends first information to the second device, where the first information is used to request the first identifier; The first device receives the first identifier from the second device.

7. The authentication method according to claim 6, wherein: The first information includes an identifier of the target server.

8. The authentication method according to any one of claims 1 to 5, characterized in that: The first device obtaining a first identifier corresponding to the target server includes: The first device determines the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

9. The authentication method according to any one of claims 1 to 8, characterized in that: The first device is the drone, the access and mobility management function AMF network element, the session management function SMF network element, the drone aviation system network function UAS NF network element, and the network open function NEF network element.

10. An authentication method, characterized in that: Application scenarios where drones switch from a source server to a target server include: The second device receives first information from the first device, where the first information is used to request a first identifier corresponding to the target server, and the first identifier is used to identify the drone; In response to the first information, the second device sends the first identifier to the first device, wherein the first identifier is used by the target server to authenticate or re-authenticate the drone.

11. The authentication method according to claim 10, wherein: Before the second device sends the first identifier to the first device, the authentication method further includes: The second device determines the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

12. The authentication method according to claim 10 or 11, characterized in that: The first information includes an identifier of the target server.

13. The authentication method according to any one of claims 10 to 12, characterized in that: The second device is an access and mobility management function AMF network element or a session management function SMF network element, and the first device is an unmanned aerial system network function UAS NF network element or a network open function NEF network element or a UAS service provider USS or a UAS traffic manager UTM; or The second device is the drone, and the first device is the AMF network element, the SMF network element, the UAS NF network element or the NEF network element.

14. A communication device, characterized in that: Application scenarios where drones switch from a source server to a target server include: A processing unit, configured to obtain a first identifier corresponding to the target server, where the first identifier is used to identify the drone; A sending unit is used to send the first identifier to the target server, where the first identifier is used by the target server to authenticate or re-authenticate the drone.

15. The communication device according to claim 14, wherein: The communication device further includes: A receiving unit, configured to receive first instruction information, where the first instruction information is used to instruct the drone to switch from the source server to the target server; The processing unit is specifically configured to obtain a first identifier corresponding to the target server according to the first indication information. The communication device according to claim 14 , wherein: The processing unit is further configured to determine that the drone is switched from the source server to the target server.

17. The communication device according to claim 16, wherein: The processing unit is specifically configured to: Obtaining the location information of the drone; According to the location information and the service area corresponding to the target server, it is determined that the drone is switched from the source server to the target server.

18. The communication device according to claim 15, wherein: The first indication information includes an identifier of the target server.

19. The communication device according to any one of claims 14 to 18, characterized in that: The sending unit is further configured to send first information to the second device, where the first information is used to request the first identifier. The communication apparatus further comprises a receiving unit configured to receive the first identifier from the second device.

20. The communication device according to claim 19, wherein The first information includes an identifier of the target server.

21. The communication device according to any one of claims 14 to 18, characterized in that: The processing unit is specifically configured to: The first identifier is determined according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a corresponding relationship between the identifier of the target server and the first identifier.

22. The communication device according to any one of claims 14 to 21, characterized in that: The communication device is the drone, the access and mobility management function AMF network element, the session management function SMF network element, the drone aviation system network function UAS NF network element or the network open function NEF network element.

23. A communication device, characterized in that: Application scenarios where drones switch from a source server to a target server include: a receiving unit, configured to receive first information from a first device, wherein the first information is used to request a first identifier corresponding to the target server, and the first identifier is used to identify the drone; A sending unit is configured to send the first identifier to the first device according to the first information, wherein the first identifier is used by the target server to authenticate or re-authenticate the drone.

24. The communication device according to claim 23, wherein: The communication device further includes: A processing unit is configured to determine the first identifier according to the identifier of the target server and a first mapping relationship, wherein the first mapping relationship includes a correspondence between the identifier of the target server and the first identifier.

25. The communication device according to claim 23 or 24, characterized in that The first information includes an identifier of the target server.

26. The communication device according to any one of claims 23 to 25, characterized in that: The communication device is an access and mobility management function AMF network element or a session management function SMF network element, and the first device is an unmanned aerial system network function UAS NF network element or a network exposure function NEF network element or a UAS service provider USS or a UAS traffic manager UTM; or, The communication device is the drone, and the first device is the AMF network element, the SMF network element, the UAS NF network element or the NEF network element.

27. A communication device, characterized in that: The system comprises at least one processor, wherein the at least one processor is configured to be coupled with a memory, read and execute instructions in the memory, so as to implement the method according to any one of claims 1 to 9.

28. A communication device, characterized in that: The system comprises at least one processor, wherein the at least one processor is configured to be coupled with a memory, read and execute instructions in the memory, so as to implement the method according to any one of claims 10 to 13.

29. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is run on a computer, the computer is caused to perform the method according to any one of claims 1 to 13.

30. A computer program product, characterized in that include: Computer program code, when the computer program code is run on a computer, causes the computer to perform the method according to any one of claims 1 to 13.

Images