Patent Description:
A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures (FIGs. ) and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref") in the FIGs. indicate like elements, and wherein:.

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and/or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and/or inherently (collectively "provided") herein. Although various embodiments are described and/or claimed herein in which an apparatus, system, device, etc. and/or any element thereof carries out an operation, process, algorithm, function, etc. and/or any portion thereof, it is to be understood that any embodiments described and/or claimed herein assume that any apparatus, system, device, etc. and/or any element thereof is configured to carry out any operation, process, algorithm, function, etc. and/or any portion thereof.

The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to <FIG>, where various elements of the network may utilize, perform, be arranged in accordance with and/or be adapted and/or configured for the methods, apparatuses and systems provided herein.

<FIG> is a system diagram illustrating an example communications system <NUM> in which one or more disclosed embodiments may be implemented. For example, the communications systems <NUM> may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discreet Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) <NUM>/<NUM>, a core network (CN) <NUM>/<NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and/or a "STA", may be configured to transmit and/or receive wireless signals and may include (or be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.

Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, e.g., to facilitate access to one or more communication networks, such as the CN <NUM>/<NUM>, the Internet <NUM>, and/or the networks <NUM>. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNode-B (eNB), a Home Node-B (HNB), a Home eNode-B (HeNB), a gNode-B (gNB), a NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, and the like.

Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell.

For example, the base station 114a in the RAN <NUM>/<NUM> and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface <NUM> using wideband CDMA (WCDMA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE <NUM> (i.e., Wireless Fidelity (Wi-Fi), IEEE <NUM> (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard <NUM> (IS-<NUM>), Interim Standard <NUM> (IS-<NUM>), Interim Standard <NUM> (IS-<NUM>), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114b in <FIG> may be a wireless router, Home Node-B, Home eNode-B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE <NUM> to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, picocell or femtocell.

For example, in addition to being connected to the RAN <NUM>/<NUM>, which may be utilizing an NR radio technology, the CN <NUM>/<NUM> may also be in communication with another RAN (not shown) employing any of a GSM, UMTS, CDMA <NUM>, WiMAX, E-UTRA, or Wi-Fi radio technology.

The CN <NUM>/<NUM> may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN <NUM>, the Internet <NUM>, and/or other networks <NUM>.

As shown in <FIG>, the WTRU <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and/or other elements/peripherals <NUM>, among others.

While <FIG> depicts the processor <NUM> and the transceiver <NUM> as separate components, it will be appreciated that the processor <NUM> and the transceiver <NUM> may be integrated together, e.g., in an electronic package or chip.

For example, in an embodiment, the transmit/receive element <NUM> may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element <NUM> may be configured to transmit and/or receive both RF and light signals.

For example, the WTRU <NUM> may employ MIMO technology. Thus, in an embodiment, the WTRU <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface <NUM>.

The processor <NUM> may further be coupled to other elements/peripherals <NUM>, which may include one or more software and/or hardware modules/units that provide additional features, functionality and/or wired or wireless connectivity. For example, the elements/peripherals <NUM> may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, and the like. The elements/peripherals <NUM> may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

The WTRU <NUM> may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the uplink (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. In an embodiment, the WTRU <NUM> may include ahalf-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).

As noted above, the RAN <NUM> may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface <NUM>.

In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and/or downlink (DL), and the like.

While each of the foregoing elements are depicted as part of the CN <NUM>, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the CN operator.

The MME <NUM> may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN <NUM> via an S1 interface and may serve as a control node.

The SGW <NUM> may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN <NUM> via the S1 interface. The SGW <NUM> may perform other functions, such as anchoring user planes during inter-eNode-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a distribution system (DS) or another type of wired/wireless network that carries traffic into and/or out of the BSS. 11e DLS or an <NUM>.

In certain representative embodiments, Carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, for example in in <NUM> systems.

High throughput (HT) STAs may use a <NUM> wide channel for communication, for example, via a combination of the primary <NUM> channel with an adjacent or nonadjacent <NUM> channel to form a <NUM> wide channel.

Very high throughput (VHT) STAs may support <NUM>, <NUM>, <NUM>, and/or <NUM> wide channels. Inverse fast fourier transform (IFFT) processing, and time domain processing, may be done on each stream separately. At the receiver of the receiving STA, the above-described operation for the <NUM>+<NUM> configuration may be reversed, and the combined data may be sent to a medium access control (MAC) layer, entity, etc..

11af and <NUM> ah. 11af and <NUM>. 11n, and <NUM>. 11af supports <NUM>, <NUM> and <NUM> bandwidths in the TV white space (TVWS) spectrum, and <NUM>. 11ah may support meter type control/machine-type communications (MTC), such as MTC devices in a macro coverage area.

11n, <NUM>. 11ac, <NUM>. 11af, and <NUM>. Carrier sensing and/or network allocation vector (NAV) settings may depend on the status of the primary channel.

In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from the WTRUs 102a, 102b, 102c.

For example, OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like.

The CN <NUM> shown in <FIG> may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b.

For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b, e.g., to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and/or the like. The AMF <NUM> may provide a control plane function for switching between the RAN <NUM> and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as Wi-Fi.

The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN <NUM> via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet <NUM>, e.g., to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

In an embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

In view of <FIG>, and the corresponding description of <FIG>, one or more, or all, of the functions described herein with regard to any of: WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME <NUM>, SGW <NUM>, PGW <NUM>, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and/or any other element(s)/device(s) described herein, may be performed by one or more emulation elements/devices (not shown).

The number of Unmanned Aerial Vehicles (UAV), often called drones, has been rapidly growing in recent years and the applications enabled by UAV are expanding into a wide variety of industries. However, conventional Unmanned Aerial Systems (UASs), i.e. UAV and controller, mostly rely on direct point-to-point communication via the unlicensed Industrial, Scientific and Medical (ISM) radio bands, which limits the range of operation, and the communication is typically unreliable, insecure and with low data rates. To further unleash the potential of UAV applications, advanced cellular technologies such as Long-Term Evolution (LTE) and <NUM> may be utilized to enable Beyond Visual Line of Sight (BVLOS) operation and higher performance and more reliable communication for UAS.

Ubiquitous mobile network coverage can provide an operation range that is far beyond that limited by the point-to-point communication using ISM frequencies. Advanced communication capabilities, such as high bandwidth, low latency, guaranteed QoS, etc., of modern cellular networks (especially <NUM> network) can help improve the performance of UAV applications. Advanced security mechanisms of modem cellular networks can address security concerns involved in managing UAV applications.

In addition to primary authentication and authorization by the 3GPP system, Unmanned Aerial Vehicle (UAV) and Unmanned Aerial Vehicle Controller (UAV-C) devices are required to be authenticated and authorized by the UAS Service Supplier/UAS Traffic Management (USS/UTM) with the support of the 3GPP system. This extra authentication and authorization procedure is referred to as USS UAV Authentication & Authorization (UUAA).

In a <NUM> System (5GS), UUAA may be performed either during 5GS Registration procedure or during PDU Session establishment procedure.

<FIG> illustrates a high-level UUAA procedure during 5GS Registration. If a UE <NUM>, (i.e. UAV) intends to use UAV related services, it may send, in step S202 a Registration request to the AMF <NUM> to indicate its support for UAV services and include its Civil Aviation Administration (CAA) level UAV Identifier. Upon successful primary 3GPP Authentication and Authorization (A&A), in step S204, the AMF <NUM> may, in step S206, send a registration accept message to the UE <NUM>, indicating that UUAA is pending. The AMF <NUM> may then trigger the UUAA procedure based on the information received in the Registration request and other information such as UE subscription information and local policies. The AMF <NUM> may request the UUAA service of the USS/UTM <NUM> by sending, in step S208, the request to a UAS Network Function <NUM> (UAS-NF). The UAS-NF <NUM> is a 3GPP network function that interfaces with the USS/UTM <NUM> for UAV related procedures such as UUAA and UAV tracking; it can for example be co-located with a Network Exposure Function (NEF) or a Service Capability Exposure Function (SCEF). The UAS-NF <NUM> discovers the USS/UTM <NUM> address based on pre-configured address information or the CAA-level UAV ID sent by the UE <NUM>. The USS/UTM <NUM> address may alternatively be provided by the UE <NUM>. In step S210, the UAS-NF <NUM> invokes the API provided by the USS/UTM <NUM> and provides necessary information, such as CAA-level UAV ID, 3GPP UAV ID (e.g., Generic Public Subscription Identifier, GPSI), to request the UUAA service, "A&A request". In step S212, the USS/UTM <NUM> may further exchange information with the UAV or UAV-C through the UAS-NF <NUM> and 3GPP network to complete UUAA, "A&A message roundtrips". In step S214, the USS/UTM <NUM> informs the UAS-NF <NUM> about the UUAA results, "A&A response", and in turn, in step S216, the UAS-NF <NUM> informs the AMF <NUM>, "UUAA response". A new CAA-level UAV ID may be allocated by the USS/UTM <NUM> as a result of successful UUAA, stored in the UAS-NF <NUM> and the AMF <NUM>, and provided, "UE Configuration Update (UUAA result)", to the UE <NUM> in step S218. The USS/UTM <NUM> may provide the UAV <NUM> with security information that the UAV <NUM> may use to establish secure communication with the USS/UTM <NUM>.

If the UUAA is not performed during the 5GS Registration, the UUAA procedure may alternatively be triggered during the establishment of the PDU Session related to UAV operations, as illustrated in <FIG>. In this case, in step S302, the UE <NUM> (i.e. UAV or UAV-C) includes its CAA-level UAV ID in the PDU Session establishment request that is sent to the SMF <NUM>. Based on the received information, such as the CAA-level UAV ID, the DNN/NSSAI that corresponds to UAV related service, and other information (e.g., subscription information), the SMF initiates, in step S304, the UUAA request with the UAS-NF <NUM> that, in step S306, forwards the A&A request to the USS/UTM <NUM>. The rest of the procedure is similar to the UUAA during Registration: the A&A message roundtrips in step <NUM>, the A&A response in step S310, the UUAA response in step S312 can be the same as described with reference to <FIG> and in step S314, the UUAA result is sent by the SMF to the UAV in a PDU session establishment accept message.

In an Evolved Packet System (EPS), the UUAA procedure is performed during the Attach/PDN Connectivity establishment procedure. UAV related information may be included in the Protocol Configuration Option (PCO) of the EPS Session Management (ESM) Container in the Attach Request. The MME may select the Access Point Name (APN) and the Packet Data Network Gateway (PGW) (or PGW-C+SMF) corresponding to the UAV service based on UE subscription information (such as "Aerial UE Information"). The PGW determines that the secondary A&A by USS/UTM is required and initiates the UUAA request via the UAS-NF. The UUAA result is informed to the UAS-NF and PGW (or PGW-C+SMF).

UAV related connection (PDU Session or PDN Connection) can only be established after the UAV or UAV-C has successfully completed UUAA. An UAV or UAV-C may establish a single common connection for both general communication with USS/UTM (e.g., sending UAV tracking data, such as network Remote ID, or receiving USS/UTM configuration information) and C2 communication with the UAV-C; or it may use a dedicated connection for general communication with the USS/UTM and another separate connection for C2 communication with the UAV-C.

To enable C2 communication with the UAV-C, the UAV needs to be authorized by the USS/UTM for the pairing with the UAV-C. In a single-connection case, the pairing authorization may be performed together with the UUAA procedure during the connection establishment procedure or may be initiated later using a connection modification procedure. In a separate-connection case, the pairing authorization may be performed during the connection establishment dedicated to UAV - UAV-C C2 communication. The pairing information (e.g., the peer CAA-level UAV identifier) may be provided by the UAV or pre-configured in the USS/UTM. If the pairing authorization is successful, the USS/UTM may provide traffic routing policies or filters for the C2 communication to the 3GPP system so the 3GPP system can enforce these policies/filters to ensure that the connection only allows the C2 communication between the UAV and the UAV-C. Similarly, to UUAA, the USS/UTM may provide the UAV via the network with a new CAA-level UAV ID and security information that the UAV may use to establish secure communication with the UAV-C.

<FIG> illustrates a system architecture for interworking between 5GS and EPS, including Home Subscriber Server (HSS)+ Unified Data Management (UDM), Policy Control Function (PCF), SMF+PGW-C, UPF+PGW-U, SGW, MME, E-UTRAN, AMF, NG-RAN and UEs on both sides. In addition, interfaces between different parts are indicated.

Combined entities, such as SMF+PGW-C, UPF+PGW-U, etc., support similar functionalities in 5GS and EPS respectively and enable the interworking between them. The N26 interface between AMF and MME is an optional interface that enables the AMF and MME to exchange information such as UE context.

A UE can operate in Single Registration (SR) mode or Dual Registration (DR) mode between 5GS and EPS. In SR mode, the UE maintains a single coordinated registration for 5GS and EPS, while in DR mode the UE handles independent registration for 5GS and EPS.

Now, when a UAV or UAV-C which has been authenticated and authorized by USS/UTM in 5GS, moves from the 5GS to the EPS (without N26 interface), either in IDLE mode or Connected mode, it may get re-authenticated by the USS/UTM in the EPS. When the UAV or UAV-C returns from the EPS to the 5GS, the 5GS may still maintain the old UUAA context (e.g., in the AMF). For example, if a UAV failed UUAA (e.g., after re-authentication) in the EPS and returns to the 5GS, the 5GS may still consider it properly authenticated by the USS/UTM according to the now obsolete UUAA context and allow the UAV to establish connections for UAV communication, which in this case should not be allowed. As another example, the UAV may be allocated a new CAA-level UAV ID (e.g., when it was re-authenticated by the USS/UTM or at any time in the EPS), but after it returns to the 5GS, the 5GS system may still use the obsolete CAA-level UAV ID (e.g., stored from previous UUAA) which can cause problems in UAV-related procedures that use the CAA-level UAV ID such as pairing authorization and/or request for UAS connectivity (e.g., with USS/UTM and/or UAV-C), tracking, etc. In the case of UAV tracking, when reporting the location of a UAV to a USS/UTM (e.g., from a set of UAVs in a given location area), the 3GPP system may provide an inconsistent (e.g., different) CAA-level UAV ID depending on whether the UAV is connected via EPS or 5GS. When requesting UAS services from 5GS (e.g., during pairing authorization), the UAV may provide the network with its current CAA-level UAV ID (e.g., newly assigned by USS/UTM while it was in EPS) which may be rejected by the 5GS in case of a mismatch with the value in the 5GS UUAA context. The similar issue may also occur in the reverse scenario, when a UAV is re-authenticated or assigned a new CAA by the USS/UTM in the 5GS while the EPS maintains the obsolete UUAA context.

Additionally, if a UAV was authenticated and authorized by the USS/UTM in 5GS via the UUAA-MM procedure (i.e. a UUAA procedure optionally performed during 5GS registration) and then moves to an EPS system, the EPS system does not have any UUAA context for the UAV and does not know which PDU Sessions are associated with the UAS service.

It can thus be desired to address these potential UUAA context consistency issues and provide methods to allow the 5GS to sync up with the UUAA context with the EPS.

Further, if a UAV or UAV-C has established PDU Sessions for UAV communication in the 5GS, these PDU Sessions will be transferred to the EPS as the PDN Connections/EPS bearers when it moves from the 5GS to the EPS (with N26 interface). However, the MME is not aware that the transferred PDN Connections/EPS bearers are related to UAV service. This will allow the UAV or the UAV-C to continue the UAV communication without allowing the USS/UTM to re-authenticate or revoke pairing/C2 communication authorization of UAV in in the EPS. In some cases, USS/UTM re-authentication/re-authorization may be necessary or even mandatory per regulatory requirements, especially when the UE is in IDLE mode and the service continuity is not a concern. Normally, the UUAA procedure in EPS is triggered during the PDN Connection establishment. But in this case, the UAV PDN Connection is already transferred from the 5GS PDU Sessions and there is no need for the UAV to initiate the PDN Connection establishment.

It can thus be desired to enable re-authentication/re-authorization or revocation of pairing/C2 communication by USS/UTM in this scenario (i.e. transfer of PDU Session used for UAS service transferred for 5GS to EPS as PDN Connections/EPS bearers).

In addition, the AMF serving the UAV may change (e.g. during a mobility registration). In this case, the UAS-NF needs to locate the correct AMF for procedures initiated by the USS/UTM (e.g., UAV location tracking and authorization revocation).

It can thus be desired to inform the UAS-NF about a new AMF serving the UAV.

In an embodiment, the UE indicates its most recent UUAA status when moving to a different system (e.g. 5GS or EPS), as will be described.

When a UE (e.g. UAV or UAV-C) completes USS/UTM authentication and authorization or re-authentication and re-authorization in 5GS or EPS, besides the normal UUAA context information such as UUAA status (successfully authenticated/authorized or not) and CAA-level UAV ID, the UE may also store the type of system (e.g. EPS or 5GS) in which it was most recently authenticated and authorized by the USS/UTM and a timestamp indicating when the most recent UUAA was completed. When the UE moves from one system to another system due to mobility, it may indicate this information (e.g. the type of system and timestamp of its recent UUAA) to the new system so that the new system can use this information to determine whether to initiate USS/UTM re-authentication & re-authorization or to retrieve the UUAA context from the previous system and to continue to use the UUAA context in the new system. This information may also help the new system to discard and avoid using any obsolete UUAA context that it may maintain. In the case of UAV re-authentication by USS/UTM, the current system (e.g., 5GS) may detect that the UAV has already been authenticated by USS/UTM on the previous system based on the UE provided system type (e.g., EPS) and may decide to trigger a fast re-authentication procedure of the UAV by the USS/UTM, whereby the UAV may use its most recent CAA level UAV ID (e.g., as re-authentication identity) and the security information (e.g., includes a re-authentication key) provided by the USS/UTM from the previous UUAA procedure (as previously described) instead of performing a full authentication procedure (e.g., using a certificate associated with a long term UAV Identifier).

Example <NUM>: a UAV is authenticated and authorized by USS/UTM in the EPS and has established PDN Connections for UAV communication in EPS, it moves from the EPS to the 5GS in IDLE mode and there is N26 interface between the EPS MME and the 5GS AMF. The UAV follows the procedure specified in Clause <NUM>. <NUM> of TS <NUM> to register in the 5GS and transfer the PDN connections for UAV communication to the PDU Sessions in the 5GS. However, the AMF may not have any UUAA context at all or it may have an obsolete UUAA context from a previous UUAA procedure in the 5GS. The AMF may not be aware that the PDU Sessions transferred from the EPS PDN Connections are for UAV communication. In this case, the UAV may indicate in the 5GS Registration request message that it was most recently authenticated and authorized by USS/UTM in the EPS, the timestamp the UUAA was completed, the CAA-level ID that may result from the previous UUAA procedure in the EPS, etc. Upon this information, the AMF may:.

In case the AMF determines to trigger a new UUAA procedure in the 5GS, a possibility is not to transfer the PDN Connections for UAV communication to the 5GS; another possibility is to transfer the PDN Connections for UAV communication to the 5GS PDU Sessions, but instruct the SMF/UPF to suspend these PDU Sessions until the USS/UTM re-authentication/re-authorization is successful. The AMF can also discard the UUAA context info received from the UE or from the PGW-C+SMF.

In case the AMF determines not to trigger a new UUAA procedure in the 5GS, it may store the UUAA context info received from the UE and from the PGW-C+SMF, and may use this UUAA context info for future UAV related procedures.

<FIG> and <FIG> illustrate UUAA context alignment in case of UE mobility from EPS to 5GS according to an embodiment of the present principles in which there is a N26 interface between the EPS and 5GS.

In step S502, the UE (e.g. UAV or UAV-C) <NUM> registers in EPS and is USS/UTM authenticated and authorized. The UE <NUM> stores the UUAA context (UUAA status, CAA-level UAV ID, timestamp of the recent UUAA completion, etc.) resulting from the UUAA in EPS. The UE <NUM> may also establish PDN Connections/EPS bearers in the EPS for UAV communication.

In step S504, upon moving to the 5GS in IDLE mode the UE initiates the Registration procedure with the AMF <NUM> in 5GS by sending a Registration request. The Registration request may include a EPS UUAA indication indicating that the UE has been recently authenticated/authorized by the USS/UTM <NUM> via EPS, the CAA-level UAV ID obtained from the USS/UTM <NUM> while it was in EPS, and the timestamp of the previous, recent UUAA completion.

In step S506, the AMF <NUM> that receives the 5GS Registration request may have previously served the UE <NUM> and may maintain the UE context including the UUAA context. The AMF <NUM> may be able to retrieve the UE context from some other AMF (not shown in the figure). If the UE indicates in the Registration request that it has been USS/UTM authenticated/authorized in EPS, the AMF <NUM> discards the old UUAA context that it may have for the UE.

In step S508, the AMF <NUM> retrieves the UE's EPS Mobility Management (MM) context from the MME <NUM> in the EPS. The received EPS MM context may include the bearer context of the PDN connections/EPS bearers that were used for UAV communications, and the bearer context may include an indication that the PDN connections/EPS bearer is for UAV communication.

In step S510, 3GPP primary authentication is performed by the UE <NUM>, the AMF <NUM> and the HSS + UDM <NUM>. The following steps in <FIG> and <FIG> assume successful UE authentication and authorization in 5GS.

In case the received bearer context in step S508 indicates that the PDN connection/EPS bearer is for UAV communication, in step S512, the AMF <NUM> may locate the PGW-C+SMF <NUM> and retrieve the Session Management (SM) context of the PDN connection/EPS bearers (Nsmf_PDUSession_ContextRequest). The SM context may contain the UAV related context information including the UUAA context.

In step S514, the AMF <NUM> determines whether to initiate re-authentication/re-authorization by USS/UTM in 5GS considering at least one of a number of factors:.

In case the AMF <NUM> determines to initiate new UUAA in the 5GS, it may have two options in handling UAV-related PDN connections if any exist:.

In case option <NUM> is used, the AMF <NUM> indicates, in step S516, to the SMF <NUM> that the PDU Session is suspended (Nsmf_PDUSession_CreateSMContext), i.e. the data transmission is not allowed over these PDU Sessions. In step S518, the SMF <NUM> establishes a N4 session with the UPF <NUM> for the PDU Session and instructs it to suspend data transmission. In step S520, the SMF <NUM> returns a context response (Nsmf_PDUSession_ContextResponse) to the AMF <NUM>.

In step S522, the AMF <NUM> returns the Registration Accept to the UE <NUM>.

In step S524, the AMF <NUM> initiates the new UUAA procedure with the USS/UTM <NUM> via the UAS-NF <NUM>. The CAA-level UAV ID and other security info resulted from previous EPS UUAA procedure may be used to enable a fast re-authentication/re-authorization by the USS/UTM.

In case the re-authentication/re-authorization by the USS/UTM <NUM> is successful and there are suspended UAV-related PDU Sessions (transferred from EPS PDN connections), in step S526, the AMF <NUM> informs the SMF <NUM> to resume the PDU Sessions (i.e. allow the data transmission over those PDU Sessions) and, in step S528, the SMF <NUM> forwards this information to the UPF <NUM>, "N4 session modification". If the re-authentication and re-authorization by the USS/UTM <NUM> fails, the AMF <NUM> should initiate release of those PDU Sessions. The AMF <NUM> may also send the new UUAA context information to the SMF <NUM> that stores the new UUAA context or replace the old UUAA context with the new one received from the AMF <NUM>.

Example <NUM>: an UE is authenticated and authorized by USS/UTM in the EPS, has established PDN Connections for UAV communication in EPS, and moves from the EPS to the 5GS in IDLE mode. There is no N26 interface between the EPS MME and the 5GS AMF. Similar to example <NUM>, based on indication received from the UAV, the AMF may trigger USS/UTM re-authentication/re-authorization during the Registration procedure. Additionally, the AMF may determine not to trigger USS/UTM re-authentication/re-authorization but may inform the SMF that the UAV is subject to the re-authentication/re-authorization by the USS/UTM. And the SMF may trigger the UUAA procedure when the UAV requests to establish the PDU Sessions for UAV communication.

<FIG> and <FIG> illustrate UUAA context alignment in case of UE mobility from EPS to 5GS according to an embodiment of the present principles in which there is no N26 interface between the EPS and 5GS.

In step S602, the UE <NUM> (UAV or UAV-C) is registered in EPS and authenticated and authorized by the USS/UTM <NUM>. The UE <NUM> stores the UUAA context (UUAA status, CAA-level UAV ID, timestamp of the recent UUAA completion, etc.) resulting from the UUAA in EPS. The UE <NUM> may also have established PDN Connections/EPS bearers in the EPS for UAV communication.

Upon UE movement to the 5GS in IDLE mode, in step S604, the UE <NUM> initiates the Registration procedure with the AMF <NUM> in 5GS by sending a Registration request that can include an EPS UUAA indication indicating that the UE, e.g. recently, has been authenticated/authorized by the USS/UTM (<NUM> in <FIG>) via EPS, the CAA-level UAV ID obtained from the USS/UTM <NUM> while it was in EPS, and the timestamp of the recent UUAA completion. If the UE <NUM> is working in Dual-Registration mode, it may maintain a separate context (including the UUAA context resulting from previous UUAA in 5GS) for 5GS and the UE <NUM> should use the EPS UUAA context instead of the old 5GS UUAA context that is obsolete since it is not the most recent UUAA context.

In case the UE <NUM> is working in Dual-Registration mode, it may maintain a separate context (including the UUAA context resulted from the previous UUAA in 5GS) for 5GS and the UE should use the EPS UUAA context instead of the old 5GS UUAA context. UEs operating in Dual registration mode may perform 5GS registration before moving from EPS to 5GS. If the UE has performed UUAA procedure in the EPS, the UE may include "EPS UUAA indication" in the Registration Request to 5GS. If the UE has not registered with 5GS before moving to 5GS, it may perform a registration request with 'handover' indication at the time of moving to 5GS. The UE may also include the "EPS UUAA indication" as described.

The AMF <NUM> that receives the 5GS Registration request may have previously served the UE and may maintains the UE context including the UUAA context, or the AMF <NUM> may be able to retrieve the UE context from some other AMF (not shown in the figure). If the UE <NUM> indicates in the Registration request that it has been USS/UTM authenticated/authorized in EPS, in step S606, the AMF <NUM> should discard the old UUAA context that it may have.

In step S608, the UE <NUM> is authenticated and authorized in <NUM> Core (5GC), e.g. using 3GPP primary authentication. In the rest of <FIG> and <FIG>, it is assumed that the authentication and authorization are successful.

In step S610, the AMF <NUM> returns the Registration Accept to the UE <NUM>.

In step S612, the AMF <NUM> determines whether to initiate re-authentication/re-authorization by the USS/UTM <NUM> in 5GS considering for example at least one factor described with reference to Example <NUM>.

In case the AMF <NUM> determines that the UE <NUM> should be re-authenticated by the USS/UTM <NUM>, the AFM <NUM> may, in step S614, inform the PGW-C+SMF <NUM> that the UE <NUM> is subjected to re-authentication/re-authorization by the USS/UTM <NUM>. The AMF <NUM> may also forward the new CAA-level UAV ID received from the UE <NUM> to the SMF <NUM>. Alternatively, the AMF <NUM> may send this indication, i.e. that the UE is subject to re-authentication, together with the Nsmf_PDUSession_CreateSMContext request (see step S620) during the PDU Session establishment.

In case the PGW-C+SMF <NUM> received the indication from the AMF <NUM> as described in Step S614, the PGW-C+SMF <NUM> should, in step S616, discard the old UUAA context information that it may have.

In step S618, the UE <NUM> sends a PDU Session Establishment request to the AMF <NUM> to initiate the PDU Session Establishment procedure in order to transfer the PDN Connections established in EPS for UAV communication. In the dual registration mode, the UE may perform PDN connection transfer from EPC to 5Gs with 'handover' indication. While transferring the PDN connection to the PDU session, the UE may include an indication "EPS UUAA SM indication" in the PDU session request message.

In step S620, the AMF <NUM> indicates that USS/UTM re-authentication is required by sending a Nsmf_PDUSession_CreateSMContext request to the PGW-C+SMF <NUM>. As mentioned, the AMF <NUM> may include the indication that the re-authentication/re-authorization by USS/UTM <NUM> is required and the CAA-level UAV ID received from the UE.

Based on this indication, the PGW-C+SMF <NUM> may, in step S622, reinitiate the UUAA procedure. The PGW-C+SMF <NUM> receives the UUAA result and other UUAA context (e.g. new CAA-level UAV ID) from the USS/UTM <NUM>.

In step S624, the PGW-C+SMF <NUM> forwards the new UUAA context to the AMF <NUM> in a Nsmf_PDUSession_CreateSMContext response.

In step S626, the AMF <NUM> forwards the PDU Session Establishment Accept message and the new UUAA context to the UE <NUM>.

Example <NUM>: a method of UUAA context alignment in case of UE mobility from 5GS to EPS is illustrated in <FIG> and <FIG>. A UE (UAV or UAV-C) <NUM> has registered and been authenticated and authorized by USS/UTM <NUM> in the 5GS via a UUAA-MM procedure (i.e. during 5GS registration) in step S1202. In step S1204, the UE moves from the 5GS to the EPS in IDLE mode and performs a TAU or Attach procedure.

If the UE has not established the PDU Sessions related to UAS service in the 5GS, or the 5GS has determined not to transfer the PDU Sessions related to UAS service to EPS, when the UAS service is triggered, in step S1206, the UE needs to establish PDN connections for UAS service. In step S1208, the UE sends a PDN Connection establishment request for UAS service to the SMF+PGW-C <NUM>, in which the UE may indicate that it has already been authenticated and authorized by the USS/UTM in the 5GS and also provide other UAV context information such as UAV identifiers (e.g. CAA-Level UAV ID, the timestamp of the previous UUAA success).

Upon receiving the PDN connection request and the aforementioned indication, the SMF+PGW-C function may, in step S1210, based on network policy or other condition(s) (e.g. whether the time elapsed from the previous UUAA is longer than a threshold), determine whether or not a UUAA procedure is required (i.e. to skip or initiate the UUAA procedure) regardless of the fact that the UAV has already been authenticated and authorized.

In case the SMF+PGW-C <NUM> determines to skip the UUAA procedure (i.e. no UUAA required in step S1210), the SMF+PGW-C may, in step S1212a, retrieve the UUAA context information from the UAS-NF <NUM>. The SMF+PGW-C may compare the context information retrieved from the UAS-NF with the context information provided by the UAV. In case of a match, the SMF+PGW-C completes the PDN Connection establishment procedure, in step S1214a.

However, in case of a mismatch, the SMF+PGW-C may discard the context information and initiate, in step S1212b, a new UUAA procedure, "UUAA-SM procedure" after which it, in step S1214b, completes the PDN Connection establishment procedure.

In case the SMF+PGW-C determines not to skip the UUAA procedure (i.e. UUAA required in step S1210), i.e. that a UUAA procedure is required, it may, in step S1212b, initiate a new UUAA procedure, "UUAA-SM procedure" after which it, in step S1214b, completes the PDN Connection establishment procedure.

In any case, the SMF+PGW-C may, in step S1216, update the UAS-NF that it is now the serving function for the UAV and that future requests from the USS/UTM <NUM>, such as UUAA re-authentication and revocation, should be directed towards the SMF+PGW-C.

Another solution is to use the UAS-NF as a common function for the architecture for interworking between 5GS and EPC/E-UTRAN. The UAS-NF can maintain a UAV context (e.g., includes a UUAA context) on behalf of the 5GC and EPC. The UAV context includes the most up-to-date CAA-level UAV ID, 3GPP UAV ID, information about the anchor network functions (e.g., AMF, SMF or MME, PGW) serving the UE, information about the USS/UTM serving the UAV (e.g., FQDN), C2 and pairing authorization information (e.g., whether authorized for pairing/C2 communication, peer UAV-C information). Various methods will now be described.

When the UE performs UUAA, UAS-NF associates the UE's serving anchor function, including system type (AMF, SMF or MME, PGW) with the UAV context. When UUAA completes successfully, the UAS-NF receives from the USS/UTM the UUAA result including the new CAA level UAV ID which the UAS-NF stores into the UAV context, along with USS/UTM address. The UAS-NF may resolve the address of USS/UTM based on CAA-level UAV ID during UUAA and store the USS/UTM address in the UAV context.

<FIG> illustrates a method of UAS-NF establishment of UAV context during UUAA according to an embodiment of the present principles.

In step S702, the UAS-NF receives an authentication/authorization request message from a network anchor function (e.g. AMF or SMF/PGW-C). The request message can include a CAA-level UAV ID, 3GPP UAV ID, and information about the USS/UTM serving the UE.

In step S704, the UAS-NF stores information received in the request message and information about the network anchor function (e.g. including system type: EPS or 5GS) in a UAV context.

In step S706, the UAS-NF sends an authentication/authorization request message to the USS/UTM. The request message can include the CAA-level UAV ID and the 3GPP UAV ID.

In step S708, the UAS-NF receives an authentication/authorization response message from the USS/UTM. The message can include the 3GPP UAV ID and authorization results including a new CAA-level UAV ID, authorization information for UAS communications (e.g. peer UAV-C MAC/IP address, C2 QoS parameters).

In step S710, the UAS-NF stores the authorization information received from the USS/UTM in the UAV context.

In step S712, the UAS-NF sends the authorization results to the network anchor function.

During UAV re-authentication by USS/UTM or if a new CAA level UAV ID is assigned by USS/UTM, the UAS-NF updates the UAV context accordingly (e.g., store new CAA level UAV ID). During a UAV-C replacement by USS/UTM the UAS-NF informs the appropriate anchor function (e.g., SMF/PCF) and updates the peer UAV-C information in the UAV context.

<FIG> illustrates a method of UAS-NF update of UAV context during re-authentication/ authorization according to an embodiment of the present principles.

In step S802, the UAS-NF receives a request message from a USS/UTM. The request message can include a 3GPP UAV ID and any of a new CAA-level UAV ID and new authorization information for UAS communications (e.g. new peer UAV-C MAC/IP address).

In step S804, the UAS-NF stores the authorization information received from the USS/UTM in the UAV context including replacing the current CAA-level UAV ID, and current authorization information for UAS communications with the new authorization information for UAS communications.

In step S806, the UAS-NF retrieves, from the UAV context identified by the 3GPP UAV ID, the information about the network anchor function serving the UE.

In step S808, the UAS-NF sends the new authorization information (e.g. new CAA-level UAV ID, new peer UAV-C address) to the network anchor function.

When a UAV moves between 5GS and EPS, the anchor function can retrieve from the UAS-NF the most recent UAV information (e.g., UAV and/or C2 communication authorization status, CAA level UAV ID) based on the UAV context. The anchor function may determine to send the request to UAS-NF for UAV information based on the system type provided by the UAV as described and to update UAS-NF with information about the UAV serving network anchor function. If UAV authorization has been revoked or if no authorization information is available for the UAV in the UAS-NF, the UAS-NF indicates that the UAV is not authorized to the network function (which may lead to a re-authentication as will be described).

<FIG> illustrates a method of UAS-NF querying during interworking according to an embodiment of the present principles.

In step S902, the UAS-NF receives an information/registration request message including a 3GPP UAV ID from a network anchor function (e.g. AMF or SMF/PGW-C).

In step S904, the UAS-NF retrieves, from the UAV context corresponding to the 3GPP UAV ID, the authorization information about the UAV and stores the information about the network anchor function (e.g. including system type: EPS or 5GS) in the UAV context.

In step S906, the UAS-NF sends an information response message to the network anchor function. The response message can include the 3GPP UAV ID, the authorized CAA-level UAV ID, authorization status for C2 communication (e.g. including peer UAV-C IP address).

In case the network anchor function determines to initiate UAV re-authentication by USS/UTM when the UE moves from one system to another, the UAS-NF forwards the authentication request to the USS/UTM using the address as stored during UUAA.

<FIG> illustrates a method of network-triggered UAV re-authentication during interworking according to an embodiment of the present principles.

In step S1002, the UAS-NF receives a re-authentication/authorization request message including a 3GPP UAV ID from a network anchor function (AMF or SMF/PGW-C).

In step S1004, the UAS-NF retrieves, from the UAV context identified by the 3GPP UAV ID, the CAA-level UAV ID and information about the USS/UTM serving the UE and stores the information about the network anchor function (e.g., including system Type: EPS or 5GS) in the UAV context.

In step S1006, the UAS-NF sends an authentication/authorization request message to the USS/UTM, the message including the CAA-level UAV ID and 3GPP UAV ID.

In step S1008, the UAS-NF receives an authentication/authorization response message from the USS/UTM, the message including the 3GPP UAV ID and authorization results including: a new CAA-level-UAV ID, authorization information for UAS communications (e.g., peer UAV-C MAC/IP address, C2 QoS parameters).

In step S1010, the UAS-NF stores the authorization information received from the USS/UTM in the UAV context.

In step S1012, the UAS-NF sends the authorization result to the network anchor function.

When the USS/UTM revokes the authorization for UAV or pairing/C2 communication, the UAS-NF informs the registered anchor functions in 5GS and/or EPS (e.g., based on information stored in the UAV context) so that the UAV information (e.g., in the UE context information in the network anchor function) and associated resources allocated (PDU Sessions/PDN connection) for the UE gets released.

During location tracking by USS/UTM, the UAS-NF contacts the active serving function (e.g., AMF) and when applicable provides the USS/UTM with the location information along with the latest CAA-level UAV ID as stored in the UAV context.

<FIG> illustrates a method of AMF change handling according to an embodiment of the present principles. When a change of AMF occurs in 5GS (e.g., during mobility registration) for a UAV that has performed UUAA during registration procedure, the new AMF obtains information about the UAS-NF (e.g., UAS-NF ID) when the UAV/UE context is transferred from the old AMF to the new AMF.

In step S1 <NUM>, the corresponding UAS-NF is notified by the new AMF about the change of AMF, but the UAS-NF can also, or instead, be notified by the old AMF. The UAS-NF can thus receive a message (e.g. a registration/subscription request) from the new AMF (and/or the old AMF), the message including UAV identification (e.g., 3GPP UAV ID, CAA level UAV ID) and AMF change information (e.g., new AMF ID, new notification callback).

In step S <NUM>, the UAS-NF updates the information about the newly registered AMF as the anchor network function in the UAV/UUAA context stored in the UAS-NF (during UUAA as described above), thus replacing information about the old AMF. The UAS-NF can use the newly registered AMF information for example to notify the new AMF of authorization revocation by USS/UTM or when requesting location information on behalf of USS/UTM as already described.

In step S <NUM>, the UAS-NF may notify the old AMF about the completion of the transfer of control of UAV context to new AMF, e.g., by sending a de-registration request that can include CAA-level UAV ID, and 3GPP UAV ID confirming transfer of UAV context control to the new AMF.

The foregoing embodiments are discussed, for simplicity, with regard to the terminology and structure of infrared capable devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, single image and/or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE", the term "remote" and/or the terms "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and/or receive unit (WTRU); (ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to <FIG>. As another example, various disclosed embodiments herein supra and infra are described as utilizing a head mounted display. Those skilled in the art will recognize that a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other device may include a drone or other device configured to stream information for providing the adapted reality experience.

In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed.

One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

Insofar as such block diagrams, flowcharts, and/or examples include one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

Those skilled in the art will recognize that it is common within the art to describe devices and/or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity, control motors for moving and/or adjusting components and/or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

The herein described subject matter sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may include usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim including such introduced claim recitation to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. " Further, the terms "any of" followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of" the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And the term "multiple", as used herein, is intended to be synonymous with "a plurality".

Claim 1:
A method, performed by a network node storing a context for at least one unmanned aerial system, the method comprising:
receiving a notification including information indicative of an identifier of an unmanned aerial system and of a change of serving anchor node, in a wireless communication system of which the network node and the at least one unmanned aerial system are part, for the unmanned aerial system corresponding to the identifier to a second anchor node in the wireless communication system, wherein an anchor node is one of an access and mobility management function node or a session management function node; and
updating a stored context for the unmanned aerial system, the stored context including a first anchor node as a serving anchor node for the unmanned aerial system, to indicate the second anchor node as the serving anchor node.