Methods and systems for 5gs and eps interworking for uav communication

Abstract

A method performed by a network node for storing a context for at least one unmanned aircraft system includes receiving a notification including an identifier indicative of an unmanned aircraft system and information that a serving anchor node for the unmanned aircraft system corresponding to the identifier has changed from a first anchor node to a second anchor node. The stored context for the unmanned aircraft system is updated, wherein the stored context includes the serving anchor node for the unmanned aircraft system to indicate the second anchor node as the serving anchor node.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 150120, filed February 17, 2021; U.S. Provisional Patent Application No. 63 / 183822, filed May 4, 2021; and U.S. Provisional Patent Application No. 63 / 253218, filed October 7, 2021, each of which is incorporated herein by reference. Background Technology

[0003] This disclosure relates in general to the fields of communications, software, and coding, including, for example, methods, architectures, apparatus, and systems for processing unmanned aerial systems (UAS). Attached Figure Description

[0004] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the drawings (figures) and specific embodiments should not be considered limiting, and other equally valid examples are possible and contemplated. Additionally, similar reference numerals (“ref.”) in the figures indicate similar elements, and wherein:

[0005] Figure 1A This is a system diagram illustrating an exemplary communication system;

[0006] Figure 1B It shows that it can be used Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0007] Figure 1C It shows that it can be used Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0008] Figure 1D It shows that it can be used Figure 1A System diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0009] Figure 2 The advanced UUAA process during 5GS registration is shown;

[0010] Figure 3 The advanced UUAA process during PDU session establishment is shown;

[0011] Figure 4 The system architecture for 5GS and EPS interoperability is shown;

[0012] Figure 5A and Figure 5B The UUAA context alignment in the case of the UE moving from EPS to 5GS is illustrated according to an embodiment based on the principles of the present invention;

[0013] Figure 6A and Figure 6B Another embodiment of the invention, based on the principles of the present invention, illustrates UUAA context alignment in the case of a UE moving from EPS to 5GS;

[0014] Figure 7 A method for establishing UAS-NF of UAV context during UUAA is shown according to an embodiment of the principles of the present invention;

[0015] Figure 8 A method for updating the UAS-NF of the UAV context during re-authentication / authorization is illustrated according to an embodiment of the principles of the present invention;

[0016] Figure 9 A method for UAS-NF query during interoperability is shown according to an embodiment of the principles of the present invention; and

[0017] Figure 10 A method for network-triggered UAV re-authentication during interoperability is illustrated according to an embodiment of the principles of the present invention;

[0018] Figure 11 An AMF modification processing method according to an embodiment of the principles of the present invention is shown; and

[0019] Figure 12A and Figure 12B A method for UUAA context alignment is shown when the UE moves from 5GS to EPS. Detailed Implementation

[0020] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should 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, processes, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively, the “Provided”) herein. Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims presupposes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0021] Exemplary communication system

[0022] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. (Compared to...) Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted to and / or configured with respect to the methods, apparatuses and systems provided herein.

[0023] Figure 1A This is a system diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 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) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-sOFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0024] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include (or be) user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0025] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to, for example, facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or Network 112). As an example, base stations 114a and 114b may be any of a base transceiver station (BTS), a node B (NB), an evolved node B (eNB), a home node B (HNB), a home evolved node B (HeNB), a g node B (gNB), an NR node B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0026] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, 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, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0027] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0028] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0029] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0030] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can enable radio technology such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0031] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0032] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0033] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In implementations, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In implementations, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In implementations, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: microcell, picocell, or femtocell. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN106 / 115.

[0034] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses any of the following radio technologies: GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi.

[0035] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 114 or a different RAT.

[0036] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114b that can employ IEEE 802 radio technology.

[0037] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing components.

[0038] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together, for example, in an electronic package or chip.

[0039] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In embodiments, transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0040] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may employ MIMO technology. Therefore, in an embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0041] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0042] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0043] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0044] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0045] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software modules / units and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (e.g., for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Components / peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0046] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0047] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0048] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0049] Each of the evolved Nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0050] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0051] The MME 162 can connect to each of the evolved nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0052] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0053] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0054] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0055] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0056] In a representative implementation, the other network 112 may be a WLAN.

[0057] A WLAN in Basic Services 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 access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0058] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, such as in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0059] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0060] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0061] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0062] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

[0063] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0064] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to the implementation scheme. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0065] RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation. Each gNB 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an implementation, gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0066] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0067] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0068] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0069] Figure 1DThe CN 115 shown 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. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any one of these elements may be owned and / or operated by an entity other than a CN operator.

[0070] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c, for example, based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. AMF 162 can provide control plane functions for handover between RAN 113 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.

[0071] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0072] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110), for example, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0073] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 115 may provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0074] Given Figures 1A to 1D as well as Figures 1A to 1D The functions described herein, including one or more of the functions described with reference to any of the following, may be performed by one or more emulation components / devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other components / devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0075] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0076] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0077] introduction

[0078] The number of unmanned aerial vehicles (UAVs) (commonly referred to as drones) has grown rapidly in recent years, and applications enabled by UAVs are expanding into a variety of industries. However, conventional unmanned aerial systems (UAS) (i.e., UAVs and controllers) primarily rely on direct point-to-point communication via the unlicensed Industrial, Scientific, and Medical (ISM) bands, which limits the scope of operations, and communication is typically unreliable, insecure, and has low data rates. To further unlock the potential of UAV applications, advanced cellular technologies such as Long Term Evolution (LTE) and 5G can be used to enable beyond-visual-range (BVLOS) operations and higher-performance, more reliable communication for UAVs.

[0079] Ubiquitous mobile network coverage provides operational range far exceeding the limitations of point-to-point communication using ISM frequencies. The advanced communication capabilities of modern cellular networks (especially 5G networks), such as high bandwidth, low latency, and guaranteed QoS, contribute to improved performance in UAV applications. The advanced security mechanisms of modern cellular networks address security concerns related to managing UAV applications.

[0080] Overview

[0081] In addition to the primary certification and authorization processes within the 3GPP system, unmanned aerial vehicles (UAVs) and their controllers (UAV-C) require certification and authorization by the UAS service provider / UAS traffic management (USS / UTM) with the support of the 3GPP system. This additional certification and authorization process is known as USS UAV Certification and Authorization (UUAA).

[0082] In a 5G system (5GS), UUAA can be executed during the 5GS registration process or during the PDU session establishment process.

[0083] Figure 2The advanced UUAA process during 5GS registration is illustrated. If UE 22 (i.e., UAV) intends to use UAV-related services, it may send a registration request to AMF 24 in step S202 to indicate its support for UAV services and include its Civil Aviation Administration (CAA) level UAV identifier. Following successful primary 3GPP Authentication and Authorization (A&A), AMF 24 may send a registration acceptance message to UE 22 in step S206, indicating that UUAA is pending. AMF 24 may then trigger the UUAA process based on the information received in the registration request, as well as other information such as UE subscription information and local policies. AMF 24 may request UUAA services from USS / UTM 28 by sending a request to UAS Network Function 26 (UAS-NF) in step S208. UAS-NF 26 is a 3GPP network function that interfacing with USS / UTM 28 for UAV-related procedures such as UUAA and UAV tracking; for example, it can be co-located with Network Exposure Function (NEF) or Service Capability Exposure Function (SCEF). UAS-NF 26 discovers the USS / UTM 28 address based on pre-configured address information or CAA-level UAV ID sent by UE 22. The USS / UTM 28 address may also be provided by UE 22. In step S210, UAS-NF 26 invokes the API provided by USS / UTM 28 and provides the necessary information (such as CAA-level UAV ID, 3GPP UAV ID (e.g., General Public Subscription Identifier GPSI)) to request UUAA service, i.e., an "A&A request". In step S212, the USS / UTM 28 can also exchange information with the UAV or UAV-C via the UAS-NF 26 and the 3GPP network to complete the UUAA, i.e., "A&A message round trip". In step S214, the USS / UTM 28 notifies the UAS-NF 26 of the UUAA result, i.e., "A&A response", and then in step S216, the UAS-NF 26 notifies the AMF 24, i.e., "UUAA response". As a result of a successful UUAA, the USS / UTM 28 can assign a new CAA-level UAV ID, which is stored in the UAS-NF 26 and AMF 24, and provided to the UE 22 in step S218, i.e., "UE configuration update (UUAA result)". The USS / UTM 28 can provide security information to the UAV 22, which the UAV 22 can use to establish secure communication with the USS / UTM 28.

[0084] If UUAA is not executed during 5GS registration, the UUAA process can optionally be triggered during the establishment of the PDU session related to UAV operation, such as... Figure 3As shown. In this case, in step S302, UE 32 (i.e., UAV or UAV-C) includes its CAA-level UAV ID in the PDU session establishment request sent to SMF 34. Based on the received information, such as the CAA-level UAV ID, the DNN / NSSAI corresponding to the UAV-related service, and other information (e.g., subscription information), SMF initiates a UUAA request to UAS-NF 36 in step S304, which forwards the A&A request to USS / UTM 38 in step S306. The remainder of the process is similar to the UUAA during registration: the A&A message round trip in step 308, the A&A response in step S310, and the UUAA response in step S312 can be referenced. Figure 2 The same applies, and in step S314, the UUAA result is sent by the SMF to the UAV in the PDU session establishment accept message.

[0085] In Evolved Packet Systems (EPS), the UUAA (Unassisted Access and Assist) procedure is performed during the attach / PDN connection establishment process. UAV-related information can be included in the Protocol Configuration Options (PCO) of the EPS Session Management (ESM) container within the attach request. The MME can select the Access Point Name (APN) and Packet Data Network Gateway (PGW) (or PGW-C+SMF) corresponding to the UAV service based on UE subscription information (such as "over-the-air UE information"). The PGW determines that assisted A&A is required by the USS / UTM and initiates a UUAA request via the UAS-NF. The UUAA result is communicated to both the UAS-NF and the PGW (or PGW-C+SMF).

[0086] UAV-related connections (PDU sessions or PDN connections) can only be established after the UAV or UAV-C has successfully completed UUAA. The UAV or UAV-C may establish a single public connection for both general communication with the USS / UTM (e.g., sending UAV tracking data, such as the 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.

[0087] To enable C2 communication with UAV-C, the UAV needs to be authorized by the USS / UTM to pair with the UAV-C. In a single-connection scenario, pairing authorization can be performed during the connection establishment process along with the UUAA procedure, or it can be initiated later using the connection modification procedure. In a standalone connection scenario, pairing authorization can be performed during connection establishment dedicated to UAV-UAV-C C2 communication. Pairing information (e.g., peer CAA-level UAV identifier) ​​can be provided by the UAV or pre-configured in the USS / UTM. If pairing authorization is successful, the USS / UTM can provide the 3GPP system with traffic routing policies or filters for C2 communication, which the 3GPP system can then enforce to ensure that the connection only allows C2 communication between the UAV and UAV-C. Similarly, for the UUAA, the USS / UTM can provide it via the network with a new CAA-level UAV ID and security information that the UAV can use to establish secure communication with the UAV-C.

[0088] Figure 4 The system architecture for interoperability between 5GS and EPS is shown, 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. Additionally, the interfaces between the different components are shown.

[0089] Combined entities such as SMF+PGW-C and UPF+PGW-U support similar functions in 5GS and EPS, respectively, and enable interoperability between them. The N26 interface between AMF and MME is an optional interface that allows AMF and MME to exchange information such as UE context.

[0090] The UE can operate between 5GS and EPS in either single registration (SR) mode or dual registration (DR) mode. In SR mode, the UE maintains a single coordinated registration for both 5GS and EPS, while in DR mode, the UE handles independent registrations for both 5GS and EPS.

[0091] Now, when a UAV or UAV-C that has been certified and authorized by USS / UTM in 5GS is moved from 5GS to EPS (without utilizing the N26 interface) in idle or connected mode, it can be recertified by USS / UTM in EPS. When a UAV or UAV-C returns to 5GS from EPS, 5GS can still retain the old UUAA context (e.g., in AMF). For example, if a UAV failed to pass UUAA in EPS (e.g., after recertification) and returns to 5GS, 5GS can still consider the UAV to have been correctly certified by USS / UTM based on the now outdated UUAA context and allow the UAV to establish a connection for UAV communication, which should not be allowed in this case. For example, a UAV may be assigned a new CAA-level UAV ID (e.g., when it is recertified by the USS / UTM or at any time in EPS), but after it returns to 5GS, the 5GS system may still use an outdated CAA-level UAV ID (e.g., from previous UUAA storage). This can cause problems in UAV-related processes using CAA-level UAV IDs, such as pairing authorization and / or requesting UAS connections (e.g., with the USS / UTM and / or UAV-C), tracking, etc. In the case of UAV tracking, when reporting the location of a UAV to the USS / UTM (e.g., from a group of UAVs in a given location area), the 3GPP system may provide inconsistent (e.g., different) CAA-level UAV IDs depending on whether the UAV is connected via EPS or via 5GS. When requesting UAS services from 5GS (e.g., during pairing authorization), a UAV may provide the network with its current CAA-level UAV ID (e.g., newly assigned by USS / UTM when it is in EPS). If this UAV ID does not match the value in the 5GS UUAA context, it may be rejected by 5GS. A similar issue may occur in the opposite scenario when a UAV is re-authenticated by USS / UTM in 5GS or assigned a new CAA while EPS retains an outdated UUAA context.

[0092] Additionally, if a UAV is authenticated and authorized by the USS / UTM in 5GS via the UUAA-MM process (i.e., the UUAA process that is optionally performed during 5GS registration) and then moved to the EPS system, the EPS system does not have any UUAA context for the UAV and is unaware of which PDU sessions are associated with UAS services.

[0093] Therefore, it is expected that these potential UUAA context consistency issues can be resolved and a method can be provided to allow 5GS to synchronize UUAA context with EPS.

[0094] Furthermore, if the UAV or UAV-C has already established a PDU session for UAV communication in the 5GS, these PDU sessions will be transferred to the EPS as PDN connection / EPS bearers when it moves from the 5GS to the EPS (using the N26 interface). However, the MME is unaware that the transferred PDN connection / EPS bearers are associated with the UAV service. This allows the UAV or UAV-C to continue UAV communication without allowing the USS / UTM to re-authenticate or revoke the UAV's pairing / C2 communication authorization in the EPS. In some cases, USS / UTM re-authentication / re-authorization may be necessary or even mandatory under regulatory requirements, especially when the UE is in idle mode and service continuity is not an issue. Typically, the UUAA procedure in the EPS is triggered during PDN connection establishment. However, in this case, the UAV PDN connection has already been transferred from the 5GS PDU session, and the UAV does not need to initiate PDN connection establishment.

[0095] Therefore, in this scenario, it is desirable to enable the USS / UTM to perform re-authentication / re-authorization or revocation of pairing / C2 communication (i.e., to transfer the PDU session used for UAS services for 5GS transfer as a PDN connection / EPS bearer to EPS).

[0096] Furthermore, the AMF serving the UAV can change (e.g., during mobile registration). In this case, the UAS-NF needs to locate the correct AMF for processes initiated by the USS / UTM (e.g., UAV location tracking and authorization revocation).

[0097] Therefore, it is expected that the UAS-NF will be notified about the new AMF serving the UAV.

[0098] UUAA context alignment between 5GS and EPS

[0099] In one implementation, when moving to a different system (e.g., 5GS or EPS), the UE indicates its most recent UUAA state, as will be described.

[0100] 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, in addition to regular UUAA context information such as UUAA status (successful authentication / authorization) and CAA-level UAV ID, the UE can also store the system type (e.g., EPS or 5GS) of the most recent USS / UTM authentication and authorization, as well as a timestamp indicating when the most recent UUAA was completed. When the UE moves from one system to another due to mobility, it can indicate this information (e.g., the system type and the timestamp of the UE's most recent UUAA) to the new system, allowing the new system to use this information to determine whether to initiate USS / UTM re-authentication and re-authorization, or to retrieve the UUAA context from the previous system and continue using the UUAA context in the new system. This information also helps the new system discard and avoid using any outdated UUAA context that it can retain. In the case of UAV re-authentication by USS / UTM, the current system (e.g., 5GS) can detect that the UAV has been previously authenticated by USS / UTM based on the system type (e.g., EPS) provided by the UE, and can decide to trigger a fast re-authentication process for the UAV by USS / UTM. In this case, the UAV can use its most recent CAA-level UAV ID (e.g., as the re-authentication identity) and security information provided by USS / UTM from the previous UUAA process (as previously described) (e.g., including the re-authentication key) instead of performing a full authentication process (e.g., using a certificate associated with a long-term UAV identifier).

[0101] Example 1: A UAV is authenticated and authorized by the USS / UTM in EPS, and a PDN connection has been established for UAV communication in EPS. The UAV moves from EPS to 5GS in idle mode, and there is an N26 interface between the EPS MME and the 5GS AMF. The UAV follows the procedure specified in Clause 4.11.1.3.3 of TS23.502 to register in 5GS and transfer the PDN connection used for UAV communication to a PDU session in 5GS. However, the AMF may not have any UUAA context at all, or it may have an outdated UUAA context from a previous UUAA procedure in 5GS. The AMF may not know that the PDU session transferred from the EPS PDN connection is for UAV communication. In this case, the UAV can indicate in the 5GS registration request message that it was recently authenticated and authorized by the USS / UTM in EPS, the timestamp of UUAA completion, the CAA-level ID that can be generated from a previous UUAA procedure in EPS, etc. Based on this information, the AMF can:

[0102] - Discard any outdated UUAA contexts it owns or retrieves from the old AMF.

[0103] - Determine which PDN connections / EPS bearers are related to UAV communication and the associated service PGW-C+SMF addresses based on the EPS UE context received from the MME.

[0104] - Retrieve EPS UUAA context from PGW-C+SMF.

[0105] - Determine whether to trigger a new UUAA process in 5GS based on network policies and regulatory requirements.

[0106] If the AMF determines that a new UUAA procedure is triggered in 5GS, one possibility is not to transfer the PDN connection used for UAV communication to 5GS; another possibility is to transfer the PDN connection used for UAV communication to the 5GS PDU session, but instruct the SMF / UPF to suspend these PDU sessions until the USS / UTM re-authentication / re-authorization is successful. The AMF may also discard UUAA context information received from the UE or from the PGW-C+SMF.

[0107] If the AMF determines that a new UUAA procedure will not be triggered in 5GS, it can store the UUAA context information received from the UE and from the PGW-C+SMF, and can use the UUAA context information for future UAV-related procedures.

[0108] Figure 5A and Figure 5B The UUAA context alignment in the case of the UE moving from EPS to 5GS is illustrated according to an embodiment of the principles of the present invention, wherein an N26 interface exists between EPS and 5GS.

[0109] In step S502, the UE (e.g., UAV or UAV-C) 52 registers in the EPS and is authenticated and authorized by the USS / UTM. The UE 51 stores the UUAA context (UUAA status, CAA-level UAV ID, timestamp of the most recent UUAA completion, etc.) generated by the UUAA in the EPS. The UE 51 can also establish a PDN connection / EPS bearer for UAV communication in the EPS.

[0110] In step S504, when moving to 5GS in idle mode, the UE initiates a registration process with AMF 53 in 5GS by sending a registration request. This registration request may include an EPS UUAA indication that the UE has recently been authenticated / authorized by USS / UTM 58 via EPS, a CAA-level UAV ID obtained from USS / UTM 58 when the UE was in EPS, and timestamps of the previous and most recent UUAA completions.

[0111] In step S506, the AMF 53 receiving the 5GS registration request may have previously served UE 51 and may retain the UE context, including the UUAA context. The AMF 53 may be able to retrieve the UE context from another AMF (not shown in the figure). If the UE indicates in the registration request that it has already been authenticated / authorized by the USS / UTM in the EPS, the AMF 53 discards any old UUAA context it may have for that UE.

[0112] In step S508, AMF 53 retrieves the UE's EPS Mobility Management (MM) context from MME 52 in the EPS. The received EPS MM context may include the bearer context of the PDN connection / EPS bearer already used for UAV communication, and the bearer context may include an indication that the PDN connection / EPS bearer is used for UAV communication.

[0113] In step S510, the 3GPP primary authentication is performed by UE 51, AMF 53 and HSS+UDM 57. Figure 5A and Figure 5B The following steps assume that UE authentication and authorization have been successfully performed in 5GS.

[0114] If the bearer context received in step S508 indicates that the PDN connection / EPS bearer is used for UAV communication, in step S512, AMF 53 can locate PGW-C+SMF 54 and retrieve the session management (SM) context (Nsmf_PDUSession_ContextRequest) of the PDN connection / EPS bearer. The SM context may contain UAV-related context information, including the UUAA context.

[0115] In step S514, AMF 53 considers at least one of the following factors to determine whether recertification / reauthorization should be initiated by USS / UTM in 5GS:

[0116] a: Operator policies or local regulations may require UAV or UAV-C to be recertified and reauthorized when the service network / system changes.

[0117] b: If the timestamp of the most recent (e.g., previous) UUAA indicates that the time period since the last UUAA exceeds a certain threshold, AMF 53 may decide to initiate a new UUAA.

[0118] c: If the UUAA context received from PGW-C+SMF in step S512 is inconsistent with the context received from UE 51 in step S504, AMF 53 may decide to initiate a new UUAA.

[0119] d: If there is no UAV-related PDN connection to be transferred to 5GS (i.e., the bearer context received in step S508 indicates that there is no UAV-related PDN connection), AMF 53 may decide to initiate a new UUAA.

[0120] If AMF 53 determines that a new UUAA is initiated in 5GS, it has two options when handling these connections if any UAV-related PDN connections exist:

[0121] Option 1: AMF 53 can determine not to transfer the PDN connection to 5GS. In this case, steps S516-S520, S526, and S528 can be skipped.

[0122] Option 2: AMF 53 can transfer PDN connections to 5GS PDU sessions, but can instruct SMF 54 / UPF 55 to suspend data transfer on these PDU sessions until the new UUAA is successfully completed.

[0123] When using option 2, in step S516, AMF 53 instructs SMF 54 to pause the PDU session (Nsmf_PDUSession_CreateSMContext), meaning data transmission is not allowed through these PDU sessions. In step S518, SMF 54 establishes an N4 session with UPF 55 for the PDU session and instructs it to pause data transmission. In step S520, SMF 54 returns a context response (Nsmf_PDUSession_ContextResponse) to AMF 53.

[0124] In step S522, AMF 53 returns registration acceptance to UE 51.

[0125] In step S524, AMF 53 initiates a new UUAA procedure with USS / UTM 58 via UAS-NF 56. The CAA-level UAV ID and other security information generated by the previous EPSUUAA procedure can be used to enable rapid re-authentication / re-authorization by USS / UTM.

[0126] If reauthentication / reauthorization by USS / UTM 58 is successful and there are suspended UAV-related PDU sessions (transferred from EPS PDN connection), in step S526, AMF 53 notifies SMF 54 to resume the PDU sessions (i.e., allow data transmission on these PDU sessions), and in step S528, SMF 54 forwards this information to UPF 55, i.e., "N4 Session Modification". If reauthentication and reauthorization by USS / UTM 58 fails, AMF 53 should initiate the release of these PDU sessions. AMF 53 may also send new UUAA context information to SMF 54, which stores the new UUAA context or replaces the old UUAA context with the new UUAA context received from AMF 53.

[0127] Example 2: The UE is authenticated and authorized by the USS / UTM in the EPS, has established a PDN connection for UAV communication in the 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 1, based on the indication received from the UAV, the AMF can trigger USS / UTM re-authentication / re-authorization during the registration process. Alternatively, the AMF can determine not to trigger USS / UTM re-authentication / re-authorization, but can notify the SMF that the UAV undergoes USS / UTM re-authentication / re-authorization. And when the UAV requests to establish a PDU session for UAV communication, the SMF can trigger the UUAA procedure.

[0128] Figure 6A and Figure 6B The UUAA context alignment is illustrated in the case of the UE moving from EPS to 5GS according to an embodiment of the principles of the present invention, wherein there is no N26 interface between EPS and 5GS.

[0129] In step S602, UE 61 (UAV or UAV-C) registers in EPS and is authenticated and authorized by USS / UTM 68. UE 61 stores the UUAA context (UUAA status, CAA-level UAV ID, timestamp of the most recent UUAA completion, etc.) generated by the UUAA in EPS. UE 61 can also establish a PDN connection / EPS bearer for UAV communication already established in EPS.

[0130] When the UE moves to the 5GS in idle mode, in step S604, the UE 61 initiates a registration process with the AMF 63 in the 5GS by sending a registration request. This registration request may include an EPS UUAA indication indicating that the UE has (e.g., recently) been certified / authorized by the EPS by the USS / UTM. Figure 6BThe context includes the UUAA context (68 in the context), the CAA-level UAVID obtained from USS / UTM 68 when it is in EPS, and the timestamp of the most recent UUAA completion. If UE 61 is operating in dual-registration mode, it can maintain a separate context for 5GS (including the UUAA context generated from the previous UUAA in 5GS), and UE 61 should use the EPS UUAA context instead of the outdated old 5GS UUAA context, as it is not the most recent UUAA context.

[0131] When UE 61 is operating in dual-registration mode, it can maintain a separate context for 5GS (including the UUAA context obtained from the previous UUAA in 5GS), and the UE should use the EPS UUAA context instead of the old 5GS UUAA context. A UE operating in dual-registration mode can perform 5GS registration before moving from EPS to 5GS. If the UE has already performed the UUAA procedure in EPS, the UE can include an "EPS UUAA indication" in the registration request to 5GS. If the UE has not yet registered with 5GS before moving to 5GS, it can perform a registration request with a "handover" indication when moving to 5GS. As described, the UE can also include an "EPS UUAA indication".

[0132] The AMF 63 receiving the 5GS registration request may have previously served the UE and may retain the UE context including the UUAA context, or the AMF 63 may be able to retrieve the UE context from another AMF (not shown in the figure). If the UE 61 indicates in the registration request that it has already been authenticated / authorized by the USS / UTM in the EPS, then in step S606, the AMF 63 should discard any old UUAA context it may have.

[0133] In step S608, UE 61 is authenticated and authorized in the 5G core (5GC), for example, using 3GPP primary authentication. Figure 6A and Figure 6B In the remainder, it is assumed that the authentication and authorization are successful.

[0134] In step S610, AMF 63 returns registration acceptance to UE 61.

[0135] In step S612, AMF 63 considers at least one factor, such as those described with reference to Example 1, to determine whether re-authentication / re-authorization should be initiated by USS / UTM 68 in 5GS.

[0136] If AMF 63 determines that UE 61 should be re-authenticated by USS / UTM 68, AMF 63 may notify PGW-C+SMF 64 in step S614 that UE 61 has undergone re-authentication / re-authorization by USS / UTM 68. AMF 63 may also forward the new CAA-level UAV ID received from UE 61 to SMF 64. Alternatively, AMF 63 may send this indication, i.e., UE re-authentication, during PDU session establishment along with an Nsmf_PDUSession_CreateSMContext request (see step S620).

[0137] If PGW-C+SMF 64 receives an instruction from AMF 63 as described in step S614, PGW-C+SMF 64 should discard any old UUAA context information it may have in step S616.

[0138] In step S618, UE 61 sends a PDU session establishment request to AMF 63 to initiate the PDU session establishment process, in order to transfer the PDN connection established in EPS for UAV communication. In dual-registration mode, the UE can use a "handover" indication to perform a PDN connection transfer from EPC to 5GS. When transferring the PDN connection to a PDU session, the UE can include the indication "EPS UUAA SM indication" in the PDU session request message.

[0139] In step S620, AMF 63 indicates the need for USS / UTM re-authentication by sending an Nsmf_PDUSession_CreateSMContext request to PGW-C+SMF 64. As described above, AMF 63 may include an indication requesting re-authentication / re-authorization by USS / UTM 68 and the CAA-level UAV ID received from the UE.

[0140] Based on this instruction, PGW-C+SMF 64 can re-initiate the UUAA procedure in step S622. PGW-C+SMF 64 receives the UUAA result and other UUAA context (e.g., the new CAA-level UAV ID) from USS / UTM 68.

[0141] In step S624, PGW-C+SMF 64 forwards the new UUAA context to AMF 63 in the Nsmf_PDUSession_CreateSMContext response.

[0142] In step S626, AMF 63 forwards the PDU session establishment accept message and the new UUAA context to UE 61.

[0143] Example 3: Figure 12A and Figure 12B The diagram illustrates a method for UUAA context alignment when a UE moves from 5GS to EPS. In step S1202, the UE (UAV or UAV-C) 1201 has been registered and authenticated and authorized by USS / UTM 1205 in 5GS via the UUAA-MM procedure (i.e., during 5GS registration). In step S1204, the UE moves from 5GS to EPS in idle mode and performs a TAU or attach procedure.

[0144] If the UE has not yet established a PDU session related to the UAS service in the 5GS, or the 5GS has determined not to transfer the PDU session related to the UAS service to the EPS, then when the UAS service is triggered, the UE needs to establish a PDN connection for the UAS service in step S1206. In step S1208, the UE sends a PDN connection establishment request for the UAS service to the SMF+PGW-C 1203, where the UE can indicate that it has been authenticated and authorized by the USS / UTM in the 5GS, and also provide other UAV context information, such as the UAV identifier (e.g., CAA-level UAVID, timestamp of previous successful UUAA).

[0145] When a PDN connection request and the aforementioned indication are received, in step S1210, SMF+PGW-C may determine whether a UUAA process is required (i.e., skip or initiate a UUAA process) based on network policies or other conditions (e.g., whether the time elapsed since the previous UUAA is longer than a threshold), regardless of the fact that the UAV has been authenticated and authorized.

[0146] If SMF+PGW-C 1203 determines that the UUAA process should be skipped (i.e., UUAA is not needed in step S1210), SMF+PGW-C may retrieve UUAA context information from UAS-NF 1204 in step S1212a. SMF+PGW-C can compare the context information retrieved from UAS-NF with the context information provided by UAV. If a match is found, SMF+PGW-C completes the PDN connection establishment process in step S1214a.

[0147] However, in the case of mismatch, SMF+PGW-C can discard the context information and initiate a new UUAA procedure, namely "UUAA-SM procedure", in step S1212b, and then complete the PDN connection establishment process in step S1214b.

[0148] If SMF+PGW-C determines that the UUAA process should not be skipped (i.e., UUAA is required in step S1210), it can initiate a new UUAA process, namely the "UUAA-SM process", in step S1212b. After that, it completes the PDN connection establishment process in step S1214b.

[0149] In any case, in step S1216, SMF+PGW-C may update UAS-NF, which is now a service function for UAV, and future requests from USS / UTM 1205 (such as UUAA recertification and revocation) should be directed to SMF+PGW-C.

[0150] UAS-NF serves as a common interoperability function for sharing UE context management.

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

[0152] When a UE performs a UUAA, the UAS-NF associates the UE's service anchor function (including system type (AMF, SMF, MME, PGW)) with the UAV context. Upon successful completion of the UUAA, the UAS-NF receives the UUAA result from the USS / UTM, including a new CAA-level UAV ID and the USS / UTM address. This new CAA-level UAV ID is stored in the UAV context by the UAS-NF. The UAS-NF can then resolve the USS / UTM address based on the CAA-level UAV ID during the UUAA and store the USS / UTM address in the UAV context.

[0153] Figure 7 A method for establishing UAS-NF of UAV context during UUAA is shown according to an embodiment of the principles of the present invention.

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

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

[0156] In step S706, the UAS-NF sends an authentication / authorization request message to the USS / UTM. This request message may include the CAA-level UAV ID and the 3GPP UAV ID.

[0157] In step S708, the UAS-NF receives an authentication / authorization response message from the USS / UTM. This message may include a 3GPPUAV ID and an authorization result, including a new CAA-level UAV ID and authorization information for UAS communication (e.g., peer UAV-CMAC / IP address, C2 QoS parameters).

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

[0159] In step S712, UAS-NF sends the authorization result to the network anchor function.

[0160] During UAV recertification by the USS / UTM, or if the USS / UTM assigns a new CAA-level UAV ID, the UAS-NF updates the UAV context accordingly (e.g., stores the new CAA-level UAV ID). During UAV-C replacement by the USS / UTM, the UAS-NF notifies the appropriate anchor function (e.g., SMF / PCF) and updates the peer UAV-C information in the UAV context.

[0161] Figure 8 A method for updating the UAS-NF of the UAV context during re-authentication / authorization is shown according to an embodiment of the principles of the present invention.

[0162] In step S802, the UAS-NF receives a request message from the USS / UTM. This request message may include any of the following: a 3GPP UAV ID, a new CAA-level UAV ID, and new authorization information for UAS communication (e.g., a new peer UAV-C MAC / IP address).

[0163] 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 the current authorization information for UAS communication with the new authorization information for UAS communication.

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

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

[0166] When a UAV moves between 5GS and EPS, the anchor function can retrieve the most recent UAV information from the UAS-NF based on the UAV context (e.g., UAV and / or C2 communication authorization status, CAA-level UAV ID). The anchor function can determine to send a request for UAV information to the UAS-NF based on the system type provided by the UAV, and update the UAS-NF using information about the UAV serving network anchor function. If the 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 has not been authorized to the network function (this may result in re-authentication, as described below).

[0167] Figure 9 A method for UAS-NF query during interoperability is shown according to an embodiment of the principles of the present invention.

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

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

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

[0171] When a UE moves from one system to another, if the network anchor function determines that a UAV re-authentication by the USS / UTM should be initiated, the UAS-NF will forward the authentication request to the USS / UTM using the address stored during the UUAA.

[0172] Figure 10 A method for network-triggered UAV re-authentication during interoperability is shown according to an embodiment of the principles of the present invention.

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

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

[0175] In step S1006, the UAS-NF sends an authentication / authorization request message to the USS / UTM, which includes the CAA-level UAVID and the 3GPP UAV ID.

[0176] In step S1008, the UAS-NF receives an authentication / authorization response message from the USS / UTM. This message includes a 3GPP UAVID and an authorization result, which includes: a new CAA-level UAVID and authorization information for UAS communication (e.g., peer UAV-C MAC / IP address, C2QoS parameters).

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

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

[0179] When the USS / UTM revokes authorization for UAV or pairing / C2 communication, the UAS-NF notifies the registered anchor function in 5GS and / or EPS (e.g., based on information stored in the UAV context) that the UAV information (e.g., in the UE context information in the network anchor function) and the associated resources (PDU session / PDN connection) allocated to the UE are released.

[0180] During location tracking by the USS / UTM, the UAS-NF contacts the Activity Service Function (e.g., AMF) and, where applicable, provides the USS / UTM with location information along with the latest CAA-level UAV ID, such as that stored in the UAV context.

[0181] Changes to AMF in 5GS

[0182] Figure 11An AMF change processing method according to an embodiment of the principles of the present invention is illustrated. When an AMF change occurs in 5GS for a UAV that has already performed UUAA during the registration process (e.g., during mobility registration), 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.

[0183] In step S1102, the new AMF notifies the corresponding UAS-NF of the AMF change, but the UAS-NF may or may alternatively be notified by the old AMF. Therefore, the UAS-NF may receive messages (e.g., registration / subscription requests) from the new AMF (and / or the old AMF), which include UAV identifiers (e.g., 3GPP UAV ID, CAA-level UAV ID) and AMF change information (e.g., new AMFID, new notification callback).

[0184] In step S1104, the UAS-NF updates information about newly registered AMFs (Affiliated Network Functions) in the UAV / UUAA context stored in the UAS-NF (during the UUAA as described above), thereby replacing the information about the old AMFs. The UAS-NF can use the newly registered AMF information to, for example, notify the new AMF of the USS / UTM's authorization revocation, or when to request location information on behalf of the USS / UTM, as already described.

[0185] In step S1106, the UAS-NF may, for example, notify the old AMF that the transfer of UAV context control to the new AMF is complete by sending a deregistration request that may include the CAA-level UAV ID and the 3GPP UAV ID, confirming the transfer of UAV context control to the new AMF.

[0186] in conclusion

[0187] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0188] For simplicity, the aforementioned embodiments have been discussed regarding the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0189] It should also 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 “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. Similarly, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU; (iii) a device configured with fewer than all the structure and functions of a WTRU; or (iv) etc. This document is in relation to... Figures 1A to 1D Details of exemplary WTRUs that may represent any WTRU described herein are provided. For instance, the various disclosed embodiments herein are described above and below as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays may be utilized, and some or all of this disclosure and the various disclosed embodiments may be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted, realistic experience.

[0190] Furthermore, the methods described herein can be implemented in computer programs, 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 via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, 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 optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0191] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0192] Furthermore, the embodiments provided above specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0193] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the implementation is not limited to the platform or CPU described above, and other platforms and CPUs may also support the provided methods.

[0194] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the implementation is not limited to the aforementioned memory, and other platforms and memories may also support the provided methods.

[0195] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0196] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software can become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of deployment. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0197] The above detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, certain portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, either wholly or partially, as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuits and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0198] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to use engineering practice 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 can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following: a system unit enclosure; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computing entities, such as an operating system, drivers, a graphical user interface, and applications; one or more interactive devices, such as a touchpad or screen; and / or a control system, including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0199] The topics described herein sometimes illustrate different components included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0200] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0201] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim objects. However, the use of such phrases should not be construed as implying that any particular claim including such introduced claim objects is limited to an embodiment including only one such claim object by using the indefinite articles “a” or “an.” This is true even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters). Additionally, in instances where conventions such as "at least one of A, B, and C" are used, generally speaking, such constructions mean that those skilled in the art will understand that convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where conventions such as "at least one of A, B, or C" are used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). A person skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items and / or item categories “any one of…”, “any combination of,” “any multiple of,” and / or “any combination of multiples of”, whether alone or in combination with other items and / or other item categories. Furthermore, as used herein, the term “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero. And, as used herein, the term “many” is intended to be synonymous with “multiple.”

[0202] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0203] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0204] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.SC §112. 6. The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

Claims

1. A method executed by a network node storing context for at least one unmanned aerial vehicle (UAV) system, the method comprising: A notification is received in a wireless communication system in which the network node and the UAV system are components. The notification includes an identifier of the UAV system and information indicating that the service anchor node of the UAV system corresponding to the identifier has changed from a first anchor node to a second anchor node in the wireless communication system, wherein the anchor node is one of an access and mobility management function node or a session management function node. as well as Update the stored context for the UAV system, the stored context including the service anchor node of the UAV system, to indicate the second anchor node as the service anchor node.

2. The method of claim 1, wherein the notification is received from at least one of the first anchor node and the second anchor node.

3. The method according to claim 1 or 2 further includes notifying the first anchor node of the completion of the transfer of control of the unmanned aerial vehicle system to the second anchor node.

4. The method according to claim 1 or 2, further comprising: Receive a request message from another node, the request message including information indicating the identifier of the unmanned aerial vehicle system and other information; Retrieve the corresponding anchor node from the stored context of the UAV system corresponding to the identifier in the request message; as well as Send at least a portion of the additional information to the corresponding anchor node.

5. The method of claim 4, wherein the additional node is an authorized node, and the additional information includes authorization information.

6. The method of claim 5, wherein the authorization information indicates one of re-authentication and revocation of the unmanned aerial vehicle system corresponding to the identifier in the request message.

7. The method of claim 4, wherein the request message is a request for a service.

8. The method of claim 7, wherein the service is location tracking of the unmanned aerial vehicle system corresponding to the identifier in the request message.

9. A wireless transmit / receive unit (WTRU), the WTRU comprising: The memory stores processor-executable program instructions; and At least one processor, the at least one processor being configured to execute the program instructions to: A notification is received in a wireless communication system in which the WTRU and the unmanned aerial vehicle (UAV) system are components. The notification includes an identifier of the UAV system and information indicating that the UAV system's service anchor node, corresponding to the identifier, changes from a first anchor node to a second anchor node in the wireless communication system. The anchor node is one of an access and mobility management function node or a session management function node. as well as Update the stored context for the UAV system, the stored context including the service anchor node of the UAV system, to indicate the second anchor node as the service anchor node.

10. The WTRU of claim 9, wherein the notification is received from at least one of the first anchor node and the second anchor node.

11. The WTRU of claim 9 or 10, wherein the at least one processor is further configured to execute the program instructions to notify the first anchor node of the completion of the transfer of control of the unmanned aerial vehicle system to the second anchor node.

12. The WTRU of claim 9 or 10, wherein the at least one processor is further configured to execute the program instructions to: Receive a request message from another node, the request message including information indicating the identifier of the unmanned aerial vehicle system and other information; Retrieve the corresponding anchor node from the stored context of the UAV system corresponding to the identifier in the request message; and Send at least a portion of the additional information to the corresponding anchor node.

13. The WTRU of claim 12, wherein the additional node is an authorized node, and the additional information includes authorization information.

14. The WTRU of claim 13, wherein the authorization information indicates either re-authentication or revocation of the unmanned aerial vehicle system corresponding to the identifier in the request message.

15. The WTRU of claim 12, wherein the request message is a request for a service.

16. The WTRU of claim 15, wherein the service is location tracking of the unmanned aerial vehicle system corresponding to the identifier in the request message.

Images