Patent Description:
Federal aviation administration (FAA) and national aeronautics and space administration (NASA) are defining an unmanned aerial vehicle (UAV) traffic management (UTM) system. The UTM system seeks to present an effective management structure for UAV traffic. In this vein, the UTM is sought to act as an enabler to promote widespread use of UAVs in both commercial and recreational settings while at the same time minimizing the perils to manned air traffic and surrounding pieces of infrastructure. The UTM system is designed to work autonomously, with no active human air traffic controller constantly supervising and monitoring the airspace. Wide-area connectivity enhances the safety and control of UAV navigation, which is critically important for UAV use cases to gain wide acceptance by consumers, regulators, and various industry sectors who have interests in using UAVs for different purposes.

UAV connectivity serves two major purposes. The first major purpose is for command and control of the UAV. In most use cases, a UAV can fly autonomously, from a starting point to a destination. However, providing remote control can significantly enhance the safety and control of a UAV. For example, if there is a change of the flight path of the UAV due to traffic management, it is essential that such information is communicated to the UAV. Accordingly, command and control functionality are essential for supporting UAV traffic management. The second major purpose is for providing data communications with/for the UAV. For example, use cases like flying cameras and remote surveillance require a UAV to send back real-time/live telemetry data, pictures, and/or videos.

Well established, ubiquitous cellular networks can best provide wide-area connectivity for supporting UAV missions. This wide-area connectivity is made possible through seamless handovers between cells in the cellular network. These seamless handovers ensure that during the duration of a UAV mission, a UAV can be served by a cell with the required reliability and quality of service (QoS). For example, a UAV initially served by cell A may after a certain point be handed over to cell B. In this example, cell A is referred to as the source cell and cell B is referred to as the target cell. Handover in a 3rd Generation Partnership Project (3GPP) network is enabled through user equipment (UE) measurements (i.e., UAV measurements). For example, a UE/UAV is given a neighbor cell list and the UE/UAV performs reference signal received power (RSRP) or reference signal received quality (RSRQ) measurements for each cell in the neighbor cell list. The measurements are based on known reference signals transmitted by these cells and detected by the UE/UAV. In the meantime, the quality of service of the source/serving cell is measured. A handover process is triggered when the QoS on the source/serving cell to the UE/UAV, as indicated by the UE/UAV measurements, drops below a certain threshold and/or when the UE/UAV measurements for a neighbor cell in the neighbor cell list (e.g., the target cell) exceeds a certain threshold.

If UAV's authentication, authorization, and/or registration by and/or to UAS service supplier (USS)IUTM fails, how a 3GPP system does with a UAV's 3GPP registration or with the UAV itself may be a challenging issue. Thus, improvements in the field are desired. Therefore, there is a need for an apparatus and a method of communication Patent publication No. <CIT> provides an unmanned aerial vehicle access method and device, the method being used for an MME. Said method comprises: when an access request message sent by an unmanned aerial vehicle is received, acquiring an international mobile equipment identity (IMEI) of the unmanned aerial vehicle; performing identity authentication on the unmanned aerial vehicle according to the IMEI of the unmanned aerial vehicle so as to obtain an identity authentication result; if the identity authentication result is authentication success, determining to accept the access of the unmanned aerial vehicle; and sending, to the unmanned aerial vehicle, a first access response message for indicating that the access is accepted. Patent publication No. <CIT>, <CIT> and <CIT> disclose the following technical solution: a device receives a request for a flight path for a UAV to travel from a first location to a second location, and determines capability information for the UAV based on component information of the UAV. The device calculates the flight path based on the capability information, identifies multiple recharging stations located on or near the flight path, and selects a recharging station from the multiple recharging stations based on one or more factors. The device generates flight path instructions, for the flight path, that instruct the UAV to stop and recharge at the recharging station. The device provides the flight path instructions to the UAV to permit the UAV to travel from the first location to a location of the recharging station, stop and recharge at the recharging station, and travel from the location of the recharging station to the second location via the flight path. 3GPPdraft S2-<NUM> proposes to add a solution to support authentication and authorization for UAV and UAV Controller. 3GPPdraft S2-<NUM> introduces a solution to KI #<NUM>.

An object of the present disclosure is to propose an apparatus and a method of communication, which can provide a failure indication from a system when an authentication, an authorization, and/or a registration from a mobile device to the system fails. The present application is defined in the independent claims.

In a first aspect of the present disclosure, a method of communication of a network comprises receiving a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration.

In a second aspect of the present disclosure, a network of communication includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The transceiver is configured to receive a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration.

In a third aspect of the present disclosure, a method of communication of a mobile device comprises receiving a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration.

In a fourth aspect of the present disclosure, a mobile device of communication includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The transceiver is configured to receive a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration.

In a fifth aspect of the present disclosure, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above methods.

In a sixth aspect of the present disclosure, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above methods.

In a seventh aspect of the present disclosure, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above methods.

In an eighth aspect of the present disclosure, a computer program product includes a computer program, and the computer program causes a computer to execute the above methods.

In a ninth aspect of the present disclosure, a computer program causes a computer to execute the above methods.

In order to more clearly illustrate the embodiments of the present disclosure or related art, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment and does not limit the disclosure.

In some embodiments, where and when in the present disclosure, the mention of "3GPP system" or "3GPP network" is made, what is inferred is system architecture evolution (SAE)/evolved packet system (EPS) and/or a 5GS (<NUM> system) as defined in TS <NUM> and TS <NUM> respectively. When methods, solutions, and embodiments in the present disclosure describes, proposes, and/or introduces actions or decisions by or in the 3GPP system, such descriptions, proposals, and/or introductions can apply without mention to one or more or a combination of entities within the 3GPP system or 3GPP network as it is presently indicated or aligned in the course of 3GPP SA2's work on Release <NUM> work items.

<FIG> illustrates a 3GPP system and network entities within the 3GPP system. The 3GPP system may be defined in TS <NUM>. <FIG> illustrates that a component/entity makeup of a 3GPP 5GS system, new or renamed entities or entities with new or changed or expanded functionalities might be introduced or changed. Thus, the latest dated versions of TS <NUM> and TS <NUM> should be referred to for fuller details.

<FIG> illustrates a registration to 3GPP system and a registration to USS/UTM. <FIG> describes methods where a UAV in accessing and registering to a 3GPP system leads the 3GPP system as a consequence of that registration to 3GPP and/or a follow up of the registration to 3GPP, contact the USS/UTM, so that the UAV then registers to the USS/UTM for UAS reasons/purposes. One such UAS purpose could be the USS/UTM allocating to the UAV an assigned ID which is used for remote identification and tracking (otherwise commonly known as remote ID, or RID).

Within 3GPP SA2 community and out of SA2#139E (1st June to 12th June <NUM>), the term CAA_Level UAV ID has been adopted as a name of the assigned ID. This aspect can be summarized by <FIG>, (taken from S2-<NUM> with added illustration) between registering to 3GPP system and registering to USS/UTM. In SA2#139E, in the discussions prior to approval of S2-<NUM>, questions were raised on what should or could happen if the 3GPP registration is successful but the USS/UTM registration fail for whatever reasons. Would the failure to successfully complete the USS/UTM registration aspects lead to also failure of the 3GPP registration. Thus, so far, exception cases, error cases, and abnormal cases are left open. Such open and unanswered questions remain for other solutions approved at SA2#139E for the UAS work item. For instance, in S2-<NUM>, the proposal there is the registration to 3GPP system is done and completed first and then subsequently, the UAV can use secondary authentication methods and through establishing user plane to USS/UTM, perform and application to application registration (in S2-<NUM>, the terminology is authorization/authentication while in <FIG> and here in some embodiments of the present disclosure use the term USS/UTM registration - or registration to USS/UTM). Therefore, it is an open issue if the 3GPP registration is completed successfully while the secondary authentication (for USS/UTM) fails. To that end the following editor's note is placed into S2-<NUM>. Editor's note: It is FFS whether the UAV can remain registered in 3GPP system if the UUAA fails. Thus, it is unspecified, unknown, what the 3GPP system should do with the UAV's 3GPP registration or with the UAV itself, if the UAV's authentication/authorization/registration by/to the USS/UTM fails (for whatever reason).

<FIG> illustrates that, in some embodiments, a mobile device <NUM> and a network <NUM> of communication in a communication network system <NUM> according to an embodiment of the present disclosure are provided. The communication network system <NUM> includes the mobile device <NUM> and the network <NUM>. The mobile device <NUM> may include a memory <NUM>, a transceiver <NUM>, and a processor <NUM> coupled to the memory <NUM>, the transceiver <NUM>. The network <NUM> may include a memory <NUM>, a transceiver <NUM>, and a processor <NUM> coupled to the memory <NUM>, the transceiver <NUM>. The processor <NUM> or <NUM> may be configured to implement proposed functions, procedures and/or methods described in this description. Layers of radio interface protocol may be implemented in the processor <NUM> or <NUM>. The memory <NUM> or <NUM> is operatively coupled with the processor <NUM> or <NUM> and stores a variety of information to operate the processor <NUM> or <NUM>. The transceiver <NUM> or <NUM> is operatively coupled with the processor <NUM> or <NUM>, and the transceiver <NUM> or <NUM> transmits and/or receives a radio signal.

In some embodiments, the transceiver <NUM> is configured to receive a failure indication from a system if the system determines that a request of the mobile device <NUM> to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration. This can provide a failure indication from a system when an authentication, an authorization, and/or a registration from a mobile device to the system fails.

<FIG> illustrates a method <NUM> of communication of a network according to an embodiment of the present disclosure. In some embodiments, the method <NUM> includes: a block <NUM>, a network receiving a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration. This can provide a failure indication from a system when an authentication, an authorization, and/or a registration from a mobile device to the system fails.

<FIG> illustrates a method <NUM> of communication of a mobile device according to an embodiment of the present disclosure. In some embodiments, the method <NUM> includes: a block <NUM>, a mobile device receiving a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication, an authorization, and/or a registration. This can provide a failure indication from a system when an authentication, an authorization, and/or a registration from a mobile device to the system fails.

In some embodiments, the mobile device <NUM> receives the failure indication from the network <NUM> if the authentication, the authorization, and/or the registration is a follow on or a concatenation of a 3rd generation partnership project (3GPP) registration. In some embodiments, when the 3GPP registration completes successfully but the authentication, the authorization, and/or the registration to the system fails, the network <NUM> decides whether to allow or not allow the mobile device <NUM> to continue to access the network <NUM>. In some embodiments, the network <NUM> decides whether to allow or not allow the mobile device <NUM> to continue to access the network based on at least one or a combination of the followings: an operator policy, service level agreements, policy rules for the mobile device provided by the system, a 3GPP subscription of the mobile device for 3GPP services, or implementation options in the network. In some embodiments, when the 3GPP registration completes successfully but the authentication, the authorization, and/or the registration to the system fails, if the authentication, the authorization, and/or the registration to the system is done as a part of the 3GPP registration, the network <NUM> rejects the 3GPP registration of the mobile device <NUM>. In some embodiments, the network <NUM> rejects the 3GPP registration of the mobile device <NUM> with a new reject cause or an existing reject cause.

In some embodiments, when the 3GPP registration completes successfully but the authentication, the authorization, and/or the registration to the system fails, if the authentication, the authorization, and/or the registration to the system is done separate or as standalone from the 3GPP registration, the network <NUM> rejects the 3GPP registration of the mobile device <NUM> by commanding the mobile device <NUM> with a de-registration request, or the network commands the mobile device <NUM> to detach by sending a detach request, or the network <NUM> commands the mobile device <NUM> that the 3GPP registration has been terminated by transmitting an existing non-access stratum (NAS) message, a new NAS message, or a session management message.

In some embodiments, when the 3GPP registration completes successfully but the authentication, the authorization, and/or the registration to the system fails, the network <NUM> keeps the mobile device <NUM> registered to the network <NUM> for 3GPP services that the mobile device <NUM> is entitled to as a part of the 3GPP registration. In some embodiments, when the 3GPP registration completes successfully but the authentication, the authorization, and/or the registration to the system fails, a failure of the authentication, the authorization, and/or the registration to the system is indicated back to the mobile device <NUM> along with a cause value indicating the failure of the authentication, the authorization, and/or the registration to the system. In some embodiments, the failure of the authentication, the authorization, and/or the registration to the system is indicated back to the mobile device <NUM> in an existing NAS message, a new NAS message, or a session management message.

In some embodiments, the existing NAS message indicating the failure of the authentication, the authorization, and/or the registration to the system comprises a registration accept, a registration reject, a service reject, or a message over a control plane meant for an application of the mobile device <NUM>. In some embodiments, the application of the mobile device <NUM> comprises a configuration update of the mobile device <NUM>. In details, the configuration update of the mobile device <NUM> may be a UE configuration update. The configuration update of the mobile device <NUM> can refer to a possible NAS message. That message can be a method to carry the indication of failure. In some embodiments, the session management message indicating the failure of the authentication, the authorization, and/or the registration to the system comprises a protocol data unit (PDU) session release command to release a PDU session associated or corresponding to the system. In some embodiments, the PDU session release command is associated to a slice or a network slice selection assistance information (NSSAI) that serves the system or serves the UAS service. In some embodiments, a cause for a release of resources of the PDU session release command is associated or corresponding to a reject cause of the 3GPP registration. In some embodiments, the reject cause of the 3GPP registration indicated back to the mobile device <NUM> comprises a newly introduced cause value indicating a reason that the mobile device <NUM> is rejected by the system for a requested service related to the UAS service.

In some embodiments, the reject cause of the 3GPP registration indicated back to the mobile device <NUM> comprises an existing cause value expanded to cover the failure of the authentication, the authorization, and/or the registration to the system. In some embodiments, the authentication, the authorization, and/or the registration is through a user plane established through the network. In some embodiments, the system comprises a UAS service supplier (USS) and/or a UAS traffic management. In some embodiments, the mobile device <NUM> comprises a user equipment and/or an unmanned aerial vehicle (UAV). In some embodiments, the network <NUM> comprises a 3GPP network.

In some embodiments, if the mobile device <NUM> receives a registration reject with a new reject cause or an existing reject cause, the new reject cause or the existing reject cause is indicated to an application layer that is an application client of the mobile device <NUM>. In some embodiments, if the mobile device <NUM> receives a registration reject with a new reject cause or an existing reject cause, the mobile device <NUM> enters a deregistered state and awaits user and/or application level instructions or intervention. In some embodiments, if the mobile device <NUM> receives a registration reject with a new reject cause or an existing reject cause, the mobile device <NUM> registers to a 3GPP system as a 3GPP mobile device with a 3GPP subscription and credentials.

In some embodiments, if the mobile device <NUM> receives a registration accept but with a new reject cause or an existing reject cause, the new reject cause or the existing reject cause is indicated to an application layer that is an application client of the mobile device <NUM>. In some embodiments, if the mobile device receives a registration accept but with a new reject cause or an existing reject cause, when the 3GPP registration has been accepted, the mobile device <NUM> behaves as a 3GPP mobile device conforming to a 3GPP specification excluding using UAS related features, signaling, procedures, and/or services. In some embodiments, if the mobile device <NUM> receives a registration accept but with a new reject cause or an existing reject cause, when the 3GPP registration has been accepted, the mobile device <NUM> stays in a registered state and performs NAS and radio resource control (RRC) procedures in the 3GPP specification. In some embodiments, if the mobile device is triggered by an application layer, the mobile device <NUM> initiates PDU sessions related to UAS features, signaling, procedures, and/or services.

In some embodiments, if the mobile device <NUM> is told to de-register or told to detach itself, a client application of the mobile device <NUM> and/or a user is informed after the mobile device <NUM> goes into de-register or detach itself, releasing resources that the mobile device <NUM> has been assigned or allocated and stays de-registered waiting for upper layers or user intervention. In some embodiments, upon de-registration or detach, the mobile device <NUM> while waiting for an upper layer or user intervention to decide on next steps, the mobile device <NUM> executes camping and selection procedures required of a 3GPP mobile device according to 3GPP specifications. In some embodiments, if the mobile device is told to de-register or told to detach itself, the mobile device <NUM> registers to a 3GPP system as a 3GPP mobile device with a 3GPP subscription and credentials.

In some embodiments, if the mobile device <NUM> receives a PDU session release command for an application level attempt at an application of the mobile device <NUM> to the authentication, the authorization, and/or the registration of an application of the system, the mobile device <NUM> releases resources for a PDU session that the network <NUM> has commanded to be released and awaits action and/or reaction by and/or from upper layers. In some embodiments, if a reason for the release is given to the mobile device <NUM> by the network <NUM> for the release of the PDU session, which can be considered as a reject cause, and the reject cause is given to upper layers and/or be displayed to a user by a man-machine interface (MMI). This display by the MMI to the user may be in the received form from the system or translated and elaborated to human readable and comprehensible form.

Some embodiments of the present disclosure propose methods for a network side and a mobile device/UE/UAV side to resolve or at least mitigate the issues indicated in previous section. For the USS/UTM, if the USS/UTM decides that UAV request to obtain UAS service has failed at authentication/authorization/registration, the USS/UTM will provide an indication of failure to the UAV and/or to the 3GPP network. In some embodiments, if the USS/UTM's authentication/authorization/registration of the UAV is a follow on (or concatenation of) the 3GPP registration, the USS/UTM can indicate such failure to the 3GPP network from where the 3GPP network will convey the USS/UTM authentication/authorization/registration failure to the UAV.

In some embodiments, if the authentication/authorization/registration of the UAV by/to the USS/UTM is through a user plane established through the 3GPP system, i.e. UAV's client application to USS/UTM's server application level communication exchanges, that indication of failure can be provided directly to the UAV. A failure in such a scenario (where UAV to/from USS/UTM is at application level) regardless, will be indicated by USS/UTM to the 3GPP network. In either of above cases, that failure indication communicated to the 3GPP network by the USS/UTM can be the hereafter referred to reject cause used by the 3GPP system towards the UAV or that indication can be mapped or translated to the hereafter mentioned reject cause or reason of failure.

In some embodiments, on a 3GPP network side, when the UAV's 3GPP registration completes successfully but the registration/authorization/authentication to the USS/UTM fails for whatever reason, the 3GPP network/system decides to allow or not allow the UE continued access to the 3GPP system as a UE successfully registered to 3GPP based on operator policy, service level agreements, policy rules for that UE provided by the USS/UTM, UE's 3GPP subscription for 3GPP services, for example, according to such subscription profile the entitled services might be nothing more than just not able to access UAS services or slices related to UAS, implementation options in the network side, or a combination of the above.

In some embodiments, when the UAV's 3GPP registration completes successfully but the registration/authorization/authentication to the USS/UTM fails for whatever reason: If the authentication/authorization/registration to USS/UTM is done as part of the 3GPP registration procedure, the 3GPP network will reject the UAV's 3GPP registration. The rejection by the 3GPP system can be by sending REGISTRATION REJECT with a new or existing reject cause. If the authentication/authorization/registration to USS/UTM is done separate (or as standalone) from the 3GPP registration procedure, the 3GPP network will reject the UAV's 3GPP registration by commanding the UAV with a DE-REGISTRATION REQUEST by a network (NW) or can command the UAV to detach by sending a DETACH REQUEST (new to 5GS). Other existing or new NAS messages to convey and/or command the UAV that its 3GPP registration has been terminated are not excluded. Even Session Management messages can be considered, for example, PDU SESSION RELEASE COMMAND.

In some embodiments, when the UAV's 3GPP registration completes successfully but the registration/authorization/authentication to the USS/UTM fails for whatever reason: The 3GPP system keeps the UAV registered to the 3GPP system for 3GPP services the UAV is entitled to as part of that 3GPP registration. The USS/UTM registration/authorization/authentication/access failure is indicated back to the UAV along with a cause value indicating this failure. This indication is provided back to the UAV in any of the present NAS reject messages, an example of which is REGISTRATION ACCEPT, REGISTRATION REJECT, SERVICE REJECT and might even be in NAS messages over the control plane meant for the UAV application such as UE configuration update. In details, the above configuration update of the mobile device <NUM> may be a UE configuration update. The above configuration update of the mobile device <NUM> can refer to a possible NAS message. That message can be a method to carry the indication of failure. Likewise, session management messages can possibly be used if it is wished to have a separation between 3GPP registration procedure and USS/UTM authentication/authorization/registration procedure. PDU SESSION RELEASE COMMAND, release the particular PDU session associated or corresponding to the USS/UTM. This may also be associated to the slice or NSSAI that serves the USS/UTM or serves the UAS feature/service. The cause given for this release of resources will correspond to the reject cause as already, or hereafter, elaborated.

In some embodiments, the reject cause indicated back to the UAV can be a newly introduced cause value indicating the reason the UAV is rejected by USS/UTM for requested service related to UAS feature. An example can be e.g. Cause #<NUM> - requested UAS services not allowed by USS/UTM. Note that the numerical value of "<NUM>" and the text wording of the reject cause are just an example. Any other new numerical value that is not yet in use will suffice. The actual numerical value to use is to be decide by 3GPP CT1 as is also the exact text wording of the reject cause. In some embodiments, the reject cause indicated back to the UAV can be an existing cause value expanded to cover failure of registration/authentication/authorization to/by USS/UTM. An existing reject cause value such as e.g. Cause #<NUM> - requested service option not subscribed.

<FIG> is a schematic diagram illustrating a registration to 3GPP system according to an embodiment of the present disclosure. <FIG> illustrates some examples of the protocol signaling of above methods. Such examples are by no means exhaustive or complete in detail. However, any person skill in the art will be able to derive the necessary details and can deduce other possible signaling. In some embodiments, the method illustrated in <FIG> includes: UAV/UE starts 3GPP registration at 3GPP NW, 3GPP NW interacts with USS/UTM for UAV's authentication/authorization/registration, USS/UTM informs that UAV authentication/authorization/registration fails, to 3GPP NW, and 3GPP NW transmits, to UAV/UE, REGISTRATION_REJECT (reject cause e.g. #<NUM>) or 3GPP NW transmits, to UAV/UE, REGISTRATION_ACCEPT (reject cause e.g. #<NUM>).

<FIG> is a schematic diagram illustrating a registration to 3GPP system according to an embodiment of the present disclosure. <FIG> illustrates some examples of the protocol signaling of above methods. Such examples are by no means exhaustive or complete in detail. However, any person skill in the art will be able to derive the necessary details and can deduce other possible signaling. In some embodiments, the method illustrated in <FIG> includes: UAV/UE is registered to 3GPP system, UAV/UE triggers session management procedures to establish a PDU session and obtain user plane to communication with USS/UTM, UAV requests registration/authentication/authorization for UAS services e.g. Flight authorization, UAV-UAVC pairing registration/authentication/authorization for UAS services fail, USS/UTM transmits an indication of failure to 3GPP NW, and 3GPP NW transmits, to UAV/UE, DE-REGISTRATION_REQUEST (reject cause e.g. #<NUM>) or 3GPP NW transmits, to UAV/UE, DETACH_REQUEST (reject cause e.g. #<NUM>) or 3GPP NW transmits, to UAV/UE, PDU SESSION RELEASE COMMAND (reject cause e.g. #<NUM>).

In some embodiments, on a UE/UAV/mobile device side: the UE/UAV/mobile receives a REGISTRATION_REJECT with a new or existing reject cause. The reject cause will be indicated to the application layer that is the UAS application client of the UAV. This reject cause decodes to human readable text is provided to the MMI for display to the human user. It is not excluded that the numerical value of the reject code is also displayed as that can serve a more precise indication of the failure should the human user contacts a call center for assistance. The mobile device will enter the DEREGISTERED state and will await user and/or application level instructions or intervention. The mobile device meantime will only be able to support emergency services. As an alternative, and/or in addition to the above methods, the UE attempts just to register to the 3GPP system as a 3GPP UE with its 3GPP subscription and credentials.

In some embodiments, the UE/UAV/mobile device receives a REGISTRATION_ACCEPT but with a new or existing reject cause. The reject cause will be indicated to the application layer that is the UAS application client of the UAV. This reject cause decodes to human readable text is provided to the MMI for display to the human user. It is not excluded that the numerical value of the reject code is also displayed as that can serve a more precise indication of the failure should the human user contacts a call center for assistance. As the UE's 3GPP registration has been accepted, the UE will behave as expected of a 3GPP UE conforming to 3GPP specifications like (and not exhaustively to) TS <NUM> (v16. <NUM>), TS <NUM> (v16. <NUM>) excluding using UAS related features, signaling, procedures and services. The UE stays in REGISTERED state and perform the necessary NAS and RRC procedures required of it given in 3GPP specification such as (but not exhaustively) TS <NUM> (v16. <NUM>), TS <NUM> (v16. <NUM>), TS <NUM>, TS <NUM>. The UE is however, if triggered by application layers, initiate PDU sessions related to UAS features, signaling, procedures and services, including knowingly utilizing any of the UAS related slice parameters (such as NSSAIs in its Allowed NSSAI list that are related to UAS feature and/or service).

In some embodiments, if the UE/UAV/mobile is told to de-register or told to detach itself - for instance NW has responded with DE-REGISTRATION REQUEST or DETACH REQUEST or by any other messages denoting to the mobile to de-register or to detach. The UAS (or UAV) client application and/or the user - in any of these cases covers the upper layers as compared to NAS and RRC - is informed after which the mobile shall go into de-register or detach itself, releasing what resources it has been assigned or allocated and stay de-registered waiting for upper layers or user intervention. Upon de-registration or detach, the UE while awaiting for upper layer or user intervention to decide on its next steps, the UE executes the necessary camping and selection procedures required of a 3GPP UE according to 3GPP specifications amongst which are TS <NUM>, TS <NUM>, TS <NUM>, TS <NUM>, TS <NUM>. As an alternative, and/or in addition to the above methods, the UE attempts just to register to the 3GPP system as a 3GPP UE with its 3GPP subscription and credentials.

In some embodiments, if the UE/UAV/mobile device receives a PDU SESSION RELEASE COMMAND for an application level attempt at UAV application (client) to USS/UTM application (server) registration/authentication/authorization, the UE releases the resources for that PDU Session that the network has commanded to be released and await action/reaction by/from upper layers. If a reason for release is given to the UE by the network for the release of the PDU session - which can be considered as a reject cause - that cause is given to upper layers and/or be displayed to user by the MMI.

All the above identified methods can be used as standalone or in conjunction with or even a combination of parts of each. These identified methods are not excluded if the final choice of NAS messages used or reject cause values chosen are different from what has been identified above.

Commercial interests for some embodiments are as follows. Solving issues in the prior art. Providing a failure indication from a system when an authentication, an authorization, and/or a registration from a mobile device to the system fails. Providing a good communication performance. Providing a high reliability. Some embodiments of the present disclosure are used by <NUM>-NR chipset vendors, V2X communication system development vendors, automakers including cars, trains, trucks, buses, bicycles, moto-bikes, helmets, and etc., drones (unmanned aerial vehicles), smartphone makers, communication devices for public safety use, AR/VR device maker for example gaming, conference/seminar, education purposes. Some embodiments of the present disclosure are a combination of "techniques/processes" that can be adopted in 3GPP specification to create an end product. Some embodiments of the present disclosure propose technical mechanisms.

<FIG> is a block diagram of an example system <NUM> for wireless communication according to an embodiment of the present disclosure. Embodiments described herein may be implemented into the system using any suitably configured hardware and/or software. <FIG> illustrates the system <NUM> including a radio frequency (RF) circuitry <NUM>, a baseband circuitry <NUM>, an application circuitry <NUM>, a memory/storage <NUM>, a display <NUM>, a camera <NUM>, a sensor <NUM>, and an input/output (I/O) interface <NUM>, coupled with each other at least as illustrated.

The application circuitry <NUM> may include a circuitry, such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combinations of general-purpose processors and dedicated processors, such as graphics processors and application processors. The processors may be coupled with the memory/storage and configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems running on the system.

The baseband circuitry <NUM> may include a circuitry, such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry.

In various embodiments, the baseband circuitry <NUM> may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. The RF circuitry <NUM> may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.

In various embodiments, the RF circuitry <NUM> may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to the user equipment, eNB, or gNB may be embodied in whole or in part in one or more of the RF circuitry, the baseband circuitry, and/or the application circuitry. As used herein, "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or a memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules.

In some embodiments, some or all of the constituent components of the baseband circuitry, the application circuitry, and/or the memory/storage may be implemented together on a system on a chip (SOC).

The memory/storage <NUM> may be used to load and store data and/or instructions, for example, for system. The memory/storage for one embodiment may include any combination of suitable volatile memory, such as dynamic random access memory (DRAM)), and/or non-volatile memory, such as flash memory.

In various embodiments, the I/O interface <NUM> may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

In various embodiments, the sensor <NUM> may include one or more sensing devices to determine environmental conditions and/or location information related to the system. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry and/or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

In various embodiments, the display <NUM> may include a display, such as a liquid crystal display and a touch screen display. In various embodiments, the system <NUM> may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, etc. In various embodiments, system may have more or less components, and/or different architectures. Where appropriate, methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

A person having ordinary skill in the art understands that each of the units, algorithm, and steps described and disclosed in the embodiments of the present disclosure are realized using electronic hardware or combinations of software for computers and electronic hardware. Whether the functions run in hardware or software depends on the condition of application and design requirement for a technical plan. A person having ordinary skill in the art can use different ways to realize the function for each specific application while such realizations should not go beyond the scope of the present disclosure. It is understood by a person having ordinary skill in the art that he/she can refer to the working processes of the system, device, and unit in the above-mentioned embodiment since the working processes of the above-mentioned system, device, and unit are basically the same. For easy description and simplicity, these working processes will not be detailed.

While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the scope of protection sought is delimited by the appending claims.

Claim 1:
A method of communication of a network, comprising:
receiving a failure indication from a system if the system determines that a request of a mobile device to obtain an unmanned aerial system (UAS) service has failed at an authentication or an authorization, wherein the system comprises a UAS service supplier (USS) and/or a UAS traffic management system, the USS/UTM decides that the mobile device request to obtain unmanned aerial system (UAS) service has failed at authentication/authorization, and the network comprises a 3rd Generation Partnership Project (3GPP) network;
wherein the method further comprises transmitting the failure indication to the mobile device if the authentication or the authorization is a follow on or a concatenation of a 3GPP registration;
wherein when the 3GPP registration completes successfully but the authentication or the authorization fails, the network decides whether to allow or not allow the mobile device to continue to access the network;
wherein the network decides whether to allow or not allow the mobile device to continue to access the network based on an operator policy.