Uncrewed aerial vehicle

Abstract

To solve a problem in which standardization of communications between UE operating as UAVs (Uncrewed Aerial Vehicles) using 5G System (5GS) and between UAVs and networks is underway, and however, discussions have recently begun on the No-Transmit Zone (NTZ), an area where the use of certain frequency bands is not permitted, and the behavior of UAVs entering the NTZ, including the sending and receiving of information about the NTZ, and the processing related to communications with the networks or devices to which the UAVs are connected, has not been clarified.SOLUTION: A method is provided for a network and a UAV that support NTZ to appropriately transmit, receive, store, and process information about NTZ support and information about the NTZ, thereby appropriately regulating the initiation of mobility management procedures and session management procedures initiated by UAVs that have entered the NTZ on the basis of information about the NTZ received from the network.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a UAV (Uncrewed Aerial Vehicle). [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project: registered trademark) is studying the system architecture of the 5G System (5GS), a fifth-generation (5G) mobile communication system, and is discussing how to support new procedures and new functions (see Non-Patent Documents 1 to 4). In Release 19 of the 5G standard, new architectures and architecture extensions for communication between UAVs (Uncrewed Aerial Vehicles) or between UAVs and networks or systems, as well as procedures and control information for communication and control, are being studied (see Non-Patent Document 4). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP TS 23.501 V18.4.0 (2023-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18) [Non-patent document 2] 3GPP TS 23.502 V18.4.0 (2023-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18) [Non-patent document 3] 3GPP TS 24.501 V18.5.0 (2023-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18) [Non-patent document 4] 3GPP TR 23.700-59 V0.2.0 (2024-03); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on architecture enhancements of UAS, UAV and UAM; Phase 3 (Release 19) Summary of the Invention [Problem to be solved by the invention]

[0004] In the 5G System (5GS), a new core network, the 5G Core Network (5GCN), is being considered to provide a wide variety of services. Regarding communications between uncrewed aerial vehicles (UAVs) or between UAVs and networks or systems, 5GCN is being considered to expand its functionality to support No-Transmit Zones (NTZs), which are areas where the use of certain frequency bands is not permitted. However, the behavior of the NTZ, including the sending and receiving of information about UAVs within the NTZ and the processing related to communications between UAVs and the networks or devices to which they are connected, remains unclear.

[0005] One aspect of this embodiment has been made in consideration of the above circumstances, and its purpose is to provide a method for networks and UAVs supporting NTZs to appropriately send and receive information about the NTZ, so that a UAV that has entered the NTZ area can appropriately regulate the initiation of mobility management procedures and session management procedures initiated by the UAV that has entered the NTZ based on information about the NTZ received from the network. [Means for solving the problem]

[0006] An uncrewed aerial vehicle (UAV) according to one aspect of the present embodiment is a UAV (uncrewed aerial vehicle) including a transceiver unit and a controller, wherein the transceiver unit transmits capability information indicating support for a no-transmit zone (NTZ) to a network and receives the NTZ information from the network, and the controller does not initiate a mobility registration update procedure when a registration area changes within the NTZ.An uncrewed aerial vehicle (UAV) according to one aspect of the present embodiment is a UAV (uncrewed aerial vehicle) including a transceiver unit and a controller, wherein the transceiver unit transmits capability information indicating support for a no-transmit zone (NTZ) to a network and receives the NTZ information from the network, and the controller does not initiate a registration update procedure when a periodic registration update timer expires within the NTZ. One aspect of the UAV (Uncrewed Aerial Vehicle) of this embodiment is a UAV (Uncrewed Aerial Vehicle) equipped with a transceiver unit and a control unit, wherein the transceiver unit transmits capability information indicating that the UAV supports an NTZ (No-Transmit Zone) to a network and receives NTZ information from the network, and the control unit does not initiate mobility management procedures and session management procedures when the UAV is within the NTZ. [Effects of the Invention]

[0007] According to one aspect of this embodiment, a network that supports an NTZ (No-Transmit Zone) and a UAV (Uncrewed Aerial Vehicle) can appropriately send and receive information about the NTZ, thereby making it possible to appropriately regulate UAV-initiated mobility management procedures and session management procedures within the NTZ based on information about the NTZ received from the network by a UAV that has entered the NTZ area. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an outline of a mobile communication system (EPS / 5GS). [Figure 2] FIG. 1 is a diagram illustrating the detailed configuration of a mobile communication system (EPS / 5GS). [Figure 3] FIG. 1 is a diagram illustrating the device configuration of a UE. [Figure 4] A diagram explaining the configuration of an access network device (gNB) in 5GS. [Figure 5] A diagram explaining the configuration of core network devices (AMF / SMF / UPF) in 5GS. [Figure 6] FIG. 10 is a diagram illustrating a registration procedure. [Figure 7] FIG. 1 is a diagram illustrating a session management procedure. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, a best mode for carrying out one aspect of this embodiment will be described with reference to the drawings. In this embodiment, as an example, an embodiment of a mobile communication system to which one aspect of this embodiment is applied will be described.

[0010] [1. System Overview] First, FIG. 1 is a diagram for explaining an outline of a mobile communication system 1 used in each embodiment, and FIG. 2 is a diagram for explaining a detailed configuration of the mobile communication system 1. As shown in FIG.

[0011] FIG. 1 shows that the mobile communication system 1 is composed of UE_A10, access network _A80, core network _A90, PDN (Packet Data Network) _A5, access network _B120, core network _B190, and DN (Data Network) _A6.

[0012] In the following, these devices and functions may be referred to by abbreviating the symbols, such as UE, access network_A, core network_A, PDN, access network_B, core network_B, DN, etc.

[0013] Figure 2 also shows devices and functions such as UE_A10, E-UTRAN80, MME40, SGW35, PGW-U30, PGW-C32, PCRF60, HSS50, 5G AN120, AMF140, UPF130, SMF132, PCF160, UDM150, and N3IWF170, as well as interfaces that connect these devices and functions to each other.

[0014] In the following, these devices and functions may be referred to by abbreviated symbols such as UE, E-UTRAN, MME, SGW, PGW-U, PGW-C, PCRF, HSS, 5G AN, AMF, UPF, SMF, PCF, UDM, N3IWF, etc.

[0015] The 4G system EPS (Evolved Packet System) includes an access network A and a core network A, but may further include a UE and / or a PDN. The 5G system 5GS (5G System) includes a UE, an access network B, and a core network B, but may further include a DN.

[0016] A UE is a device that can connect to a network service via 3GPP access (also referred to as a 3GPP access network, or 3GPP AN) and / or non-3GPP access (also referred to as a non-3GPP access network, or non-3GPP AN). A UE may be a terminal device capable of wireless communication, such as a mobile phone or a smartphone, and may be a terminal device that can connect to both EPS and 5GS. A UE may include a UICC (Universal Integrated Circuit Card) or an eUICC (Embedded UICC). Note that a UE may be referred to as a user device or a terminal device.

[0017] Furthermore, access network_A corresponds to an E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and / or a wireless LAN access network. One or more eNBs (evolved Node Bs) 45 are deployed in the E-UTRAN. Note that, hereinafter, the eNB 45 may be referred to by abbreviating the symbol eNB. If there are multiple eNBs, the eNBs are connected to each other, for example, via an X2 interface. Furthermore, one or more access points are deployed in the wireless LAN access network.

[0018] Furthermore, access network_B corresponds to a 5G access network (5G AN). The 5G AN is composed of an NG-RAN (NG Radio Access Network) and / or a non-3GPP access network. One or more gNBs (NR Node Bs) 122 are deployed in the NG-RAN. Note that, hereinafter, the symbol for gNB 122 may be abbreviated, such as gNB. The gNB is a node that provides the NR (New Radio) user plane and control plane to UEs and connects to the 5GCN via an NG interface (including an N2 interface or an N3 interface). In other words, the gNB is a base station device newly designed for 5GS, and has different functions from the base station device (eNB) used in the 4G system EPS. Furthermore, when there are multiple gNBs, the gNBs are connected to each other, for example, via an Xn interface.

[0019] Furthermore, the non-3GPP access network may be an untrusted non-3GPP access network or a trusted non-3GPP access network. Here, the untrusted non-3GPP access network may be a non-3GPP access network that does not perform security management within the access network, such as a public wireless LAN. On the other hand, the trusted non-3GPP access network may be an access network specified by 3GPP, and may include a trusted non-3GPP access point (TNAP) and a trusted non-3GPP gateway function (TNGF).

[0020] In the following, E-UTRAN and NG-RAN may be referred to as 3GPP access. Also, wireless LAN access networks and non-3GPP AN may be referred to as non-3GPP access. Also, nodes located in access network_B may be collectively referred to as NG-RAN nodes.

[0021] Furthermore, in the following, access network _A, and / or access network _B, and / or devices included in access network _A, and / or devices included in access network _B may be referred to as access networks or access network devices.

[0022] The core network_A corresponds to an EPC (Evolved Packet Core), which includes, for example, an MME (Mobility Management Entity), an SGW (Serving Gateway), a PGW (Packet Data Network Gateway)-U, a PGW-C, a PCRF (Policy and Charging Rules Function), and an HSS (Home Subscriber Server).

[0023] Furthermore, the core network_B corresponds to a 5G Core Network (5GCN). In the 5GCN, for example, an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), a Policy Control Function (PCF), a Unified Data Management (UDM), etc. are arranged. Here, the 5GCN may be expressed as a 5GC.

[0024] Furthermore, in this specification, core network _A, and / or core network _B, and / or devices included in core network _A, and / or devices included in core network _B may be referred to as core networks, or core network devices, or devices within core networks, or networks, or NWs. In other words, for example, when referring to networks or NWs in this specification, it may mean core network _A or core network _B.

[0025] The core network (core network _A and / or core network _B) may be an IP mobile communication network operated by a mobile network operator (MNO) that connects the access network (access network _A and / or access network _B) to the PDN and / or DN, or it may be a core network for a mobile network operator that operates and manages the mobile communication system 1, or it may be a core network for a virtual mobile communication operator or virtual mobile communication service provider such as an MVNO (Mobile Virtual Network Operator) or MVNE (Mobile Virtual Network Enabler).

[0026] Also, while FIG. 1 illustrates a case where the PDN and the DN are the same, they may be different. The PDN may be a DN (Data Network) that provides communication services to the UE. The DN may be configured as a packet data service network, or may be configured for each service. Furthermore, the PDN may include a connected communication terminal. Therefore, connecting to the PDN may mean connecting to a communication terminal or a server device located in the PDN. Furthermore, transmitting and receiving user data to and from the PDN may mean transmitting and receiving user data to and from a communication terminal or a server device located in the PDN. The PDN may be referred to as the DN, and the DN may be referred to as the PDN.

[0027] In addition, hereinafter, at least a portion of the access network _A, the core network _A, the PDN, the access network _B, the core network _B, and the DN, and / or one or more devices included therein may be referred to as a network or a network device. In other words, when a network and / or a network device sends or receives a message and / or performs a procedure, it means that at least a portion of the access network _A, the core network _A, the PDN, the access network _B, the core network _B, and the DN, and / or one or more devices included therein send or receive a message and / or perform a procedure.

[0028] The UE can also connect to an access network. The UE can also connect to a core network via the access network. The UE can also connect to a PDN or DN via the access network and the core network. That is, the UE can transmit and receive (communicate) user data with the PDN or DN. When transmitting and receiving user data, not only IP (Internet Protocol) communication but also non-IP communication can be used.

[0029] Here, IP communication refers to data communication using IP, and data is transmitted and received using IP packets. An IP packet consists of an IP header and a payload. The payload may include data transmitted and received by devices and functions included in EPS or devices and functions included in 5GS. Non-IP communication refers to data communication that does not use IP, and data is transmitted and received in a format different from the IP packet structure. For example, non-IP communication may be data communication achieved by transmitting and receiving application data without an IP header, or it may be user data transmitted and received by a UE with a different header, such as a MAC header or an Ethernet (registered trademark) frame header, added.

[0030] In addition, access network _A, core network _A, access network _B, core network _B, PDN_A, and DN_A may be configured with devices not shown in Fig. 2. For example, core network _A and / or core network _B may include an AUSF (Authentication Server Function) and an AAA (Authentication, authorization, and accounting) server (AAA-S).

[0031] Here, the AUSF is a core network device having an authentication function for 3GPP access and non-3GPP access, specifically, a network function unit that receives an authentication request for 3GPP access and / or non-3GPP access from a UE and executes the authentication procedure.

[0032] The AAA server is a device that has authentication, authorization, and accounting functions and is connected to the AUSF directly or indirectly via another network device. The AAA server may be a network device within the core network. The AAA server may not be included in the core network _A and / or core network _B, but may be included in the PLMN. In other words, the AAA server may be a core network device or a device outside the core network. For example, the AAA server may be a server device within the PLMN managed by a third party.

[0033] 2, for the sake of simplicity, each device and function is shown one by one, but multiple similar devices and functions may be configured in the mobile communication system 1. Specifically, the mobile communication system 1 may be configured with multiple devices and functions such as UE_A10, E-UTRAN80, MME40, SGW35, PGW-U30, PGW-C32, PCRF60, HSS50, 5G AN120, AMF140, UPF130, SMF132, PCF160, and / or UDM150.

[0034] The UPF_A235 is connected to the DN, the SMF, other UPFs, and the access network. The UPF_A235 may perform functions such as anchoring for intra-RAT or inter-RAT mobility, packet routing and forwarding, an UL CL (Uplink Classifier) ​​function that supports routing of multiple traffic flows for one DN, a branching point function that supports multi-homed PDU sessions, QoS processing for the user plane, verification of uplink traffic, buffering of downlink packets, and a trigger function for downlink data notification. The UPF_A235 may also be a relay device that forwards user data as a gateway between the DN and the core network_B190. The UPF_A235 may also be a gateway for IP communication and / or non-IP communication. The UPF_A235 may also have the function of forwarding IP communication and the function of converting non-IP communication to IP communication. Furthermore, multiple gateways may be gateways that connect the core network _B190 to a single DN. Note that UPF_A235 may have connectivity with other NFs and may be connected to each device via other NFs.

[0035] Between UPF_A235 and the access network, UPF_C239 (also called a branching point or uplink classifier), which is a UPF different from UPF_A235, may exist as a device or NF. When UPF_C239 exists, a PDU session between the UE and the DN will be established via the access network, UPF_C239, and UPF_A235.

[0036] Furthermore, the UPF 130 may be the same device as the UPF_A 235. Note that the UPF 130 and the UPF_A 235 may be written with the symbols omitted, such as UPF.

[0037] [2. Configuration of each device] Next, the configuration of each device (UE, and / or access network device, and / or core network device) used in each embodiment will be described with reference to the drawings. Each device may be configured as physical hardware, as logical (virtual) hardware configured on general-purpose hardware, or as software. Furthermore, at least a part (including all) of the functions of each device may be configured as physical hardware, logical hardware, or software.

[0038] Note that each memory unit (memory unit_A340, memory unit_A440, memory unit_B540, memory unit_A640, memory unit_B740) in each device / function mentioned below is configured with, for example, a semiconductor memory, a solid state drive (SSD), a hard disk drive (HDD), etc. Furthermore, each memory unit can store not only information that was originally set at the time of shipment, but also various information transmitted and received between devices / functions other than the device / function itself (e.g., UE, and / or access network device, and / or core network device, and / or PDN, and / or DN). Furthermore, each memory unit can store identification information, control information, flags, parameters, etc. included in control messages transmitted and received in various communication procedures described below. Furthermore, each memory unit may store this information for each UE. Furthermore, when interworking between 5GS and EPS is performed, each memory unit can store control messages and user data transmitted and received between 5GS and / or devices / functions included in EPS. At this time, not only those transmitted and received via the N26 interface but also those transmitted and received without going through the N26 interface can be stored.

[0039] [2.1. UE Device Configuration] First, an example of the device configuration of UE (User Equipment) will be explained using Figure 3. The UE is composed of a control unit _A300, an antenna 310, a transceiver unit _A320, and a memory unit _A340. The control unit _A300, the transceiver unit _A320, and the memory unit _A340 are connected via a bus. The transceiver unit _A320 is connected to the antenna 310.

[0040] Note that the UE in this specification may be a UAV (Uncrewed Aerial Vehicle) or an Aerial UE.

[0041] The control unit _A300 is a functional unit that controls the operation and functions of the entire UE.The control unit _A300 realizes various processing in the UE by reading and executing various programs stored in the memory unit _A340 as necessary.

[0042] The transceiver unit _A320 is a functional unit for wireless communication with a base station device (eNB or gNB) in the access network via an antenna. That is, the UE can use the transceiver unit _A320 to transmit and receive user data and / or control information between an access network device, and / or a core network device, and / or a PDN, and / or a DN.

[0043] Explaining in detail with reference to Figure 2, the UE can communicate with a base station device (eNB) in the E-UTRAN via the LTE-Uu interface by using the transceiver unit _A320. The UE can also communicate with a base station device (gNB) in the 5G AN by using the transceiver unit _A320. The UE can also transmit and receive AMF and NAS (Non-Access-Stratum) messages via the N1 interface by using the transceiver unit _A320. However, since the N1 interface is logical, in reality, communication between the UE and the AMF is performed via the 5G AN.

[0044] The memory unit _A340 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the UE.

[0045] [2.2. gNB device configuration] Next, an example of the gNB device configuration will be described using Figure 4. The gNB is composed of a control unit _B500, an antenna 510, a network connection unit _B520, a transceiver unit _B530, and a memory unit _B540. The control unit _B500, the network connection unit _B520, the transceiver unit _B530, and the memory unit _B540 are connected via a bus. The transceiver unit _B530 is connected to the antenna 510.

[0046] The control unit _B500 is a functional unit that controls the operation and functions of the entire gNB. The control unit _B500 realizes various processes in the gNB by reading and executing various programs stored in the memory unit _B540 as necessary.

[0047] The network connection unit _B520 is a functional unit for the gNB to communicate with the AMF and / or UPF. That is, the gNB can send and receive user data and / or control information between the AMF and / or UPF using the network connection unit _B520.

[0048] The transceiver unit _B530 is a functional unit for wireless communication with the UE via the antenna 510. That is, the gNB can transmit and receive user data and / or control information to and from the UE using the transceiver unit _B530.

[0049] 2, a gNB in ​​a 5G AN can communicate with an AMF via an N2 interface by using a network connection unit _B 520, and can communicate with a UPF via an N3 interface, and can communicate with a UE by using a transceiver unit _B 530.

[0050] The memory unit _B540 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the gNB.

[0051] [2.3. AMF device configuration] Next, an example of the AMF device configuration will be explained using Figure 5. The AMF is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory unit _B740 are connected via a bus. The AMF may be a node that handles the control plane. The AMF may also be a network device. In other words, for example, in this specification, a network device may mean an AMF.

[0052] The control unit _B700 is a functional unit that controls the operation and functions of the entire AMF.The control unit _B700 realizes various processing in the AMF by reading and executing various programs stored in the memory unit _B740 as necessary.

[0053] The network connection unit _B720 is a functional unit for the AMF to connect to a base station device (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF in a 5G AN. That is, the AMF can use the network connection unit _B720 to transmit and receive user data and / or control information between a base station device (gNB), and / or SMF, and / or PCF, and / or UDM, and / or SCEF in a 5G AN. In other words, for example, the network connection unit may be a transceiver unit.

[0054] Explaining in detail with reference to FIG. 2, the AMF in the 5GCN can communicate with a gNB via the N2 interface by using the network connection unit _A620, can communicate with a UDM via the N8 interface, can communicate with an SMF via the N11 interface, and can communicate with a PCF via the N15 interface. The AMF can also send and receive NAS messages with a UE via the N1 interface by using the network connection unit _A620. However, since the N1 interface is logical, communication between the UE and the AMF is actually performed via a 5G AN. Furthermore, if the AMF supports the N26 interface, it can communicate with an MME via the N26 interface by using the network connection unit _A620.

[0055] The memory unit _B740 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the AMF.

[0056] The AMF has functions such as exchanging control messages with the RAN using the N2 interface, exchanging NAS messages with the UE using the N1 interface, encrypting and protecting the integrity of NAS messages, registration management (RM) functions, connection management (CM) functions, reachability management functions, mobility management functions for UEs, etc., transferring SM (Session Management) messages between the UE and the SMF, access authentication (Access Authorization) functions, security anchor functionality (SEA), security context management (SCM), a function to support the N2 interface for the N3IWF (Non-3GPP Interworking Function), a function to support sending and receiving NAS signals with the UE via the N3IWF, and a function to authenticate UEs connected via the N3IWF.

[0057] In addition, registration management manages the RM state for each UE. The RM state may be synchronized between the UE and the AMF. The RM state includes an unregistered state (RM-DEREGISTERED state) and a registered state (RM-REGISTERED state). In the RM-DEREGISTERED state, the UE is not registered with the network, and therefore the UE context in the AMF does not have valid location information or routing information for the UE, and therefore the AMF cannot reach the UE. In the RM-REGISTERED state, the UE is registered with the network, and therefore the UE can receive services that require registration with the network. Note that the RM state may also be expressed as a 5GMM state. In this case, the RM-DEREGISTERED state may be expressed as a 5GMM-DEREGISTERED state, and the RM-REGISTERED state may be expressed as a 5GMM-REGISTERED state.

[0058] In other words, 5GMM-REGISTERED may be a state in which each device has established a 5GMM context or a PDU session context. When each device is 5GMM-REGISTERED, UE_A10 may start transmitting and receiving user data and control messages, or may respond to paging. Furthermore, when each device is 5GMM-REGISTERED, UE_A10 may perform registration procedures other than the registration procedure for initial registration, and / or service request procedures.

[0059] Furthermore, 5GMM-DEREGISTERED may be a state in which each device has not established a 5GMM context, a state in which UE_A10's location information is not known to the network, or a state in which UE_A10 is unreachable from the network. Note that when each device is 5GMM-DEREGISTERED, UE_A10 may initiate a registration procedure or may establish a 5GMM context by performing the registration procedure.

[0060] In addition, connection management manages the CM state for each UE. The CM state may be synchronized between the UE and the AMF. The CM state includes a non-connected state (CM-IDLE state) and a connected state (CM-CONNECTED state). In the CM-IDLE state, the UE is in the RM-REGISTERED state but does not have a NAS signaling connection established with the AMF via the N1 interface. In the CM-IDLE state, the UE does not have an N2 interface connection or an N3 interface connection. On the other hand, in the CM-CONNECTED state, the UE has a NAS signaling connection established with the AMF via the N1 interface. In the CM-CONNECTED state, the UE may have an N2 interface connection and / or an N3 interface connection.

[0061] Furthermore, in connection management, the CM state in 3GPP access and the CM state in non-3GPP access may be managed separately. In this case, the CM state in 3GPP access may include a non-connected state in 3GPP access (CM-IDLE state over 3GPP access) and a connected state in 3GPP access (CM-CONNECTED state over 3GPP access). Furthermore, the CM state in non-3GPP access may include a non-connected state in non-3GPP access (CM-IDLE state over non-3GPP access) and a connected state in non-3GPP access (CM-CONNECTED state over non-3GPP access). Note that the non-connected state may be expressed as an idle mode, and the connected state mode may be expressed as a connected mode.

[0062] The CM state may be expressed as a 5GMM mode. In this case, the unconnected state may be expressed as a 5GMM-IDLE mode, and the connected state may be expressed as a 5GMM-CONNECTED mode. Furthermore, the unconnected state in 3GPP access may be expressed as a 5GMM-IDLE mode over 3GPP access, and the connected state in 3GPP access may be expressed as a 5GMM-CONNECTED mode over 3GPP access. Furthermore, the unconnected state in non-3GPP access may be expressed as 5GMM unconnected mode in non-3GPP access (5GMM-IDLE mode over non-3GPP access), and the connected state in non-3GPP access may be expressed as 5GMM connected mode in non-3GPP access (5GMM-CONNECTED mode over non-3GPP access). Note that the 5GMM unconnected mode may be expressed as idle mode, and the 5GMM connected mode may be expressed as connected mode.

[0063] In addition, one or more AMFs may be placed in the core network_B. In addition, the AMF may be a Network Function (NF) that manages one or more Network Slice Instances (NSIs). In addition, the AMF may be a Common Control Plane Network Function (CCNF) shared among multiple NSIs.

[0064] In addition, the N3IWF is a device and / or function located between the non-3GPP access and the 5GCN when the UE connects to the 5GS via the non-3GPP access.

[0065] [2.4. SMF device configuration] Next, an example of the SMF device configuration will be explained using Figure 5. The SMF is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory unit _B740 are connected via a bus. The SMF may be a node that handles the control plane.

[0066] The control unit _B700 is a functional unit that controls the operation and functions of the entire SMF.The control unit _B700 realizes various processing in the SMF by reading and executing various programs stored in the memory unit _B740 as necessary.

[0067] The network connection unit _B720 is a functional unit for the SMF to connect with the AMF, and / or UPF, and / or PCF, and / or UDM. In other words, the SMF can send and receive user data and / or control information between the AMF, and / or UPF, and / or PCF, and / or UDM using the network connection unit _B720.

[0068] Explaining in more detail with reference to Figure 2, the SMF in the 5GCN can communicate with the AMF via the N11 interface, with the UPF via the N4 interface, with the PCF via the N7 interface, and with the UDM via the N10 interface by using the network connection unit _A620.

[0069] The memory unit _B740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the SMF.

[0070] The SMF has session management functions such as establishing, modifying, and releasing PDU sessions, IP address allocation for UEs and its management, UPF selection and control, UPF configuration for routing traffic to the appropriate destination, sending and receiving the SM portion of NAS messages, Downlink Data Notification, providing AN-specific (for each AN) SM information to be sent to the AN via the N2 interface via the AMF, determining the SSC mode (Session and Service Continuity mode) for the session, and roaming functions.

[0071] [2.5. UPF device configuration] Next, an example of the device configuration of the UPF will be explained using Figure 5. The UPF is composed of a control unit _B700, a network connection unit _B720, and a memory unit _B740. The control unit _B700, the network connection unit _B720, and the memory unit _B740 are connected via a bus. The UPF may be a node that handles the control plane.

[0072] The control unit _B700 is a functional unit that controls the operation and functions of the entire UPF.The control unit _B700 realizes various processing in the UPF by reading and executing various programs stored in the memory unit _B740 as necessary.

[0073] The network connection unit _B720 is a functional unit for the UPF to connect to a base station device (gNB), and / or SMF, and / or DN within the 5G AN. In other words, the UPF can use the network connection unit _B720 to transmit and receive user data and / or control information between the base station device (gNB), and / or SMF, and / or DN within the 5G AN.

[0074] Explaining in more detail with reference to Figure 2, a UPF in a 5GCN can communicate with a gNB via the N3 interface, with an SMF via the N4 interface, with a DN via the N6 interface, and with other UPFs via the N9 interface by using the network connection unit _A620.

[0075] The memory unit _B740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UPF.

[0076] The UPF has functions such as an anchor point for intra-RAT mobility or inter-RAT mobility, an external PDU session point for interconnecting to DNs (i.e., a gateway between DNs and core network_B that forwards user data), packet routing and forwarding, an UL CL (Uplink Classifier) ​​function that supports routing of multiple traffic flows to one DN, a branching point function that supports multi-homed PDU sessions, a QoS (Quality of Service) processing function for the user plane, an uplink traffic verification function, downlink packet buffering, and a function to trigger downlink data notifications.

[0077] The UPF may also be a gateway for IP communication and / or non-IP communication. The UPF may also have a function for forwarding IP communication and a function for converting non-IP communication and IP communication. Furthermore, multiple gateways may be gateways that connect the core network_B to a single DN. The UPF may also have connectivity with other NFs and may be connected to each device via other NFs.

[0078] The user plane refers to user data transmitted and received between a UE and a network. The user plane may be transmitted and received using a PDN connection or a PDU session. Furthermore, in the case of EPS, the user plane may be transmitted and received using the LTE-Uu interface, and / or the S1-U interface, and / or the S5 interface, and / or the S8 interface, and / or the SGi interface. Furthermore, in the case of 5GS, the user plane may be transmitted and received via the interface between the UE and the NG RAN, and / or the N3 interface, and / or the N9 interface, and / or the N6 interface. Hereinafter, the user plane may be referred to as the U-Plane.

[0079] Furthermore, the control plane refers to control messages transmitted and received to control UE communications, etc. The control plane may be transmitted and received using a Non-Access-Stratum (NAS) signaling connection between the UE and the MME. Furthermore, in the case of EPS, the control plane may be transmitted and received using the LTE-Uu interface and the S1-MME interface. Furthermore, in the case of 5GS, the control plane may be transmitted and received using the interface between the UE and the NG RAN and the N2 interface. Hereinafter, the control plane may be referred to as the control plane or the C-Plane.

[0080] Furthermore, the U-Plane (User Plane; UP) may be a communication path for transmitting and receiving user data and may be composed of multiple bearers. Furthermore, the C-Plane (Control Plane; CP) may be a communication path for transmitting and receiving control messages and may be composed of multiple bearers.

[0081] 2.6. Description of Other Devices and / or Functions Next, other devices and / or functions will be described.

[0082] The terminal device may be a mobile equipment (ME) or a user equipment (UE), and may or may not include a universal integrated circuit card (UICC) and / or a universal subscriber identity module (USIM).

[0083] In addition, the UE described in this specification may be read as a terminal device. Furthermore, the terminal device may be read as a UE or a UAV. Furthermore, in this specification, the UE may be read as a UE or a UAV.

[0084] The PCF has a function to provide policy rules.

[0085] The UDM also has functions such as authentication credential processing, user identification processing, access authentication, registration / mobility management, and subscription management.

[0086] The PCRF is connected to the PGW and / or PDN and has a function of managing QoS for data delivery. For example, it manages the QoS of the communication path between the UE_A10 and the PDN. Furthermore, the PCRF may be a device that creates and / or manages PCC (Policy and Charging Control) rules and / or routing rules used by each device when transmitting and receiving user data.

[0087] The HSS is connected to the MME and / or SCEF and has a function of managing subscriber information. The subscriber information of the HSS is referred to, for example, when controlling access to the MME. Furthermore, the HSS may be connected to a location management device different from the MME.

[0088] [3. Explanation of terms and identification information used in each embodiment] Next, highly specialized terms and identification information used in each embodiment will be explained in advance.

[0089] [3.1. Explanation of terms used in each embodiment] Next, highly specialized terms used in each embodiment will be explained.

[0090] A network refers to at least a portion of an access network _B, a core network _B, and a DN. Furthermore, one or more devices included in at least a portion of an access network _B, a core network _B, and a DN may be referred to as a network or a network device. In other words, when a network transmits, receives, and / or processes messages, it may mean that devices within the network (network devices and / or control devices) transmit, receive, receive, and / or process messages. Conversely, when a device within the network transmits, receives, receives, and / or processes messages, it may mean that the network transmits, receives, receives, and / or processes messages.

[0091] An SM (Session Management) message (also referred to as a NAS (Non-Access-Stratum) SM message) may be a NAS message used in a procedure for SM (SM procedure), or may be a control message transmitted and received between UE_A10 and SMF_A230 via AMF_A240. Furthermore, the SM message may include a PDU session establishment request message, a PDU session establishment accept message, a PDU session establishment reject message, a PDU session modification request message, a PDU session modification command message, a PDU session modification complete message, a PDU session modification command reject message, a PDU session modification reject message, a PDU session release request message, a PDU session release reject message, a PDU session release command message, a PDU session release complete message, etc. Furthermore, the procedure for SM or the SM procedure may include a PDU session establishment procedure, a PDU session modification procedure, and a UE-requested PDU session release procedure.Each procedure may be initiated from the UE or from the NW.

[0092] An MM (Mobility management) message (also referred to as an NAS MM message) may be an NAS message used in procedures for MM, and may be a control message transmitted and received between UE_A10 and AMF_A240. Furthermore, the MM message may include a registration request message, a registration accept message, a registration reject message, a de-registration request message, a de-registration accept message, a configuration update command message, a configuration update complete message, a service request message, a service accept message, a service reject message, a notification message, a notification response message, etc. Furthermore, the procedures for MM or MM procedures may include a registration procedure, a de-registration procedure, a generic UE configuration update procedure (also simply referred to as a UE configuration update procedure), an authentication and / or authorization procedure, a service request procedure, a paging procedure, and a notification procedure.

[0093] The 5GS (5G System) service is a connection service provided using the core network _B190. Furthermore, the 5GS service may be a service different from the EPS service or a service similar to the EPS service.

[0094] Non-5GS services may be services other than 5GS services, and may include EPS services and / or non-EPS services.

[0095] PDN (Packet Data Network) type indicates the type of PDN connection, and can be IPv4, IPv6, IPv4v6, or non-IP. If IPv4 is specified, it indicates that data will be sent and received using IPv4. If IPv6 is specified, it indicates that data will be sent and received using IPv6. If IPv4v6 is specified, it indicates that data will be sent and received using either IPv4 or IPv6. If non-IP is specified, it indicates that communication will not be via IP, but via a communication method other than IP.

[0096] A PDU (Protocol Data Unit / Packet Data Unit) session can be defined as an association between a DN that provides PDU connectivity services and a UE, but it may also be connectivity established between a UE and an external gateway. In 5GS, a UE can transmit and receive user data to and from a DN by establishing a PDU session via an access network _B and a core network _B. Here, this external gateway may be a UPF, SCEF, or the like. The UE can transmit and receive user data to and from a device, such as an application server, located in the DN using the PDU session. Note that each device (UE, and / or access network device, and / or core network device) may manage one or more pieces of identification information associated with a PDU session. Note that this identification information may include one or more of a DNN, a QoS rule, a PDU session type, an application identification information, an NSI identification information, an access network identification information, and an SSC mode, or may further include other information. Furthermore, when multiple PDU sessions are established, the identification information associated with each PDU session may be the same or different.

[0097] The DNN (Data Network Name) may be identification information for identifying a core network and / or an external network such as a DN. Furthermore, the DNN can also be used as information for selecting a gateway such as a PGW / UPF that connects the core network B190. Furthermore, the DNN may be equivalent to an APN (Access Point Name).

[0098] A network slice (NS) is a logical network that provides specific network capabilities and network characteristics. UEs and / or networks can support network slices (NW slices; NS) in 5GS. A network slice may also be simply referred to as a slice.

[0099] A UE and / or a device in the network can be assigned to one or more NSs based on registration information such as an NSSAI, an S-NSSAI, an UE usage type, an NSI ID, or one or more APNs. The UE usage type is a parameter value included in the UE registration information and used to identify the NSI. The UE usage type may be stored in the HSS. The AMF may select an SMF and a UPF based on the UE usage type.

[0100] Furthermore, S-NSSAI (Single Network Slice Selection Assistance Information) is information for identifying an NS. S-NSSAI may consist of only SST (Slice / Service type), or may consist of SST and SD (Slice Differentiator). Here, SST is information indicating the expected behavior of an NS in terms of functions and services. Furthermore, SD may be information that interpolates SST when selecting one NSI from multiple NSIs indicated by SST. S-NSSAI may be information specific to each PLMN or SNPN, or may be standard information common to PLMNs or SNPNs.

[0101] In addition, the S-NSSAI may be transmitted and received between each device using the 5GS S-NSSAI IE, in which case the S-NSSAI may be composed of the S-NSSAI (SST and / or SD) associated with the current PLMN or SNPN, and / or the S-NSSAI (SST and / or SD) of the HPLMN (if any, for example, when the UE is roaming or when the current PLMN or SNPN is a VPLMN or SNPN).

[0102] Furthermore, the S-NSSAI transmitted and received between the UE and the NW may be expressed as an S-NSSAI IE (Information element). Furthermore, the S-NSSAI IE transmitted and received between the UE and the NW may be composed of an S-NSSAI configured with an SST and / or SD of the registered PLMN or SNPN, and / or an SST and / or SD indicating the S-NSSAI of the HPLMN or HSNPN to which the S-NSSAI is mapped. One or more S-NSSAIs stored in the UE and / or NW may be composed of an SST and / or SD, or may be composed of an S-NSSAI configured with an SST and / or SD, and / or an SST and / or SD indicating the S-NSSAI of the HPLMN to which the S-NSSAI is mapped.

[0103] Also, NSSAI (Network Slice Selection Assistance Information) is a collection of S-NSSAIs. Each S-NSSAI included in the NSSAI is information that assists the access network or core network in selecting an NSI. The UE may store an NSSAI allowed by the network for each PLMN or SNPN. The NSSAI may also be information used to select an AMF. The UE may apply each NSSAI (allowed NSSAI, and / or configured NSSAI, and / or rejected NSSAI, and / or pending NSSAI) to a PLMN and an EPLMN, or to an SNPN and an ESNPN.

[0104] Also, a configured NSSAI is an NSSAI that is provisioned and stored in the UE. The UE may store a configured NSSAI for each PLMN or SNPN. The UE may store a configured NSSAI in association with a PLMN or SNPN.

[0105] In this document, a configured NSSAI associated with a PLMN may be expressed as a configured NSSAI for the PLMN, or a configured NSSAI of the PLMN, or a configured NSSAI for the PLMN, or a configured NSSAI associated with the PLMN. Similarly, a configured NSSAI associated with an SNPN may be expressed as a configured NSSAI for the SNPN, or a configured NSSAI of the SNPN, or a configured NSSAI for the SNPN, or a configured NSSAI associated with the SNPN.

[0106] Also, a UE may not be associated with a PLMN and may store a configured NSSAI that is valid for all PLMNs, and may refer to such a configured NSSAI as the "default configured NSSAI." Similarly, a UE may not be associated with an SNPN and may store a configured NSSAI that is valid for all SNPNs, and may refer to such a configured NSSAI as the "default configured NSSAI." A UE may not be associated with a PLMN or SNPN and may store a configured NSSAI that is valid for all PLMNs and SPNNs, and may refer to such a configured NSSAI as the "default configured NSSAI."

[0107] A mapped S-NSSAI is an S-NSSAI of an HPLMN that is mapped to an S-NSSAI of a registered PLMN in a roaming scenario. The UE may store one or more mapped S-NSSAIs that are mapped to S-NSSAIs included in the configured NSSAI and allowed NSSAI for each access type. Furthermore, the UE may store one or more mapped S-NSSAIs for rejected NSSAIs and / or S-NSSAIs included in pending NSSAIs.

[0108] If a roaming scenario of an SNPN is supported, the mapped S-NSSAI may be the S-NSSAI of the HSNPN mapped to the S-NSSAI of the registered SNPN.

[0109] A configured NSSAI may be associated with multiple PLMNs or SNPNs, where the multiple PLMNs may be EPLMNs and the multiple SNPNs may be ESNPNs.

[0110] The configured NSSAI may be information configured by the network (or PLMN or SNPN). The S-NSSAI included in the configured NSSAI may be expressed as the configured S-NSSAI. The configured S-NSSAI may be transmitted or received using the S-NSSAI IE, and in this case, the configured S-NSSAI may be configured to include the S-NSSAI (SST and / or SD) and the mapped S-NSSAI (SST of the mapped HPLMN or SNPN and / or SD of the mapped HPLMN or SNPN) (if any, for example, when the UE is roaming or when the associated PLMN or SNPN is a VPLMN or VSNPN).

[0111] Alternatively, the S-NSSAI (SST and / or SD) of a PLMN or SNPN and the S-NSSAI (SST and / or SD) of a HPLMN or SNPN may be treated independently. Specifically, the configured S-NSSAI of a PLMN or SNPN may be expressed as a "configured S-NSSAI for a PLMN or SNPN" or a "configured S-NSSAI of a PLMN or SNPN" or a "configured S-NSSAI for a PLMN or SNPN."

[0112] Furthermore, one or more S-NSSAIs of an HPLMN or HSNPN to which the configured S-NSSAI is mapped may be expressed as "one or more mapped S-NSSAIs for a configured NSSAI of a PLMN or SNPN" or "one or more mapped S-NSSAIs for a configured NSSAI of a PLMN or SNPN."

[0113] In other words, the UE may store a "configured NSSAI of the current PLMN or SNPN" in which the S-NSSAI of the current PLMN or SNPN is configured, and may also store "one or more mapped S-NSSAIs for the configured NSSAI of the current PLMN or SNPN" when roaming. The one or more mapped S-NSSAIs for the configured NSSAI may be 3GPP mapped S-NSSAI(s) for the configured NSSAI.

[0114] The configured NSSAI may be updated by the NW at any timing, and the updated configured NSSAI may be transmitted from the NW to the UE based on the update.

[0115] The requested NSSAI is an NSSAI provided by the UE to the network during the registration procedure. In the registration procedure, the S-NSSAI included in the requested NSSAI sent by the UE may be the S-NSSAI included in the allowed NSSAI or configured NSSAI stored by the UE.

[0116] The requested NSSAI may be information indicating a network slice requested by the UE. The S-NSSAI included in the requested NSSAI may be expressed as a requested S-NSSAI. For example, the requested NSSAI is transmitted and received by being included in an NAS message, such as a registration request message or a PDU session establishment request message, transmitted from the UE to the network, or an RRC (Radio Resource Control) message including a NAS (Non-Access-Stratum) message. Here, in a roaming case, the requested NSSAI may include the S-NSSAI of the VPLMN and the S-NSSAI of the mapped HPLMN. In other words, the S-NSSAI included in the requested NSSAI (requested S-NSSAI) may be composed of the S-NSSAI and the mapped S-NSSAI.

[0117] The requested NSSAI may be information including one or more S-NSSAIs associated with a network slice requested by the UE. Note that the network slice requested by the UE may be a network slice that the UE wants to use, or a network slice that the UE requests permission to use from the network. The S-NSSAI included in the requested NSSAI may be an S-NSSAI included in a configured NSSAI associated with the current PLMN, or may be an S-NSSAI included in an allowed NSSAI associated with the current PLMN.

[0118] In other words, the requested NSSAI may be an S-NSSAI included in a configured NSSAI associated with one or more current PLMNs, or an S-NSSAI included in an allowed NSSAI associated with one or more current PLMNs, or a combination of the two. More specifically, the allowed NSSAI associated with the current PLMN may be an allowed NSSAI associated with the current PLMN and the current access type. Furthermore, the requested NSSAI may be a 5GS requested NSSAI.

[0119] In addition, the S-NSSAI included in the requested NSSAI may be an S-NSSAI stored by the UE and not included in the rejected NSSAI associated with the current PLMN or SNPN, and / or an S-NSSAI stored by the UE and not included in the pending NSSAI associated with the current PLMN or SNPN.

[0120] Furthermore, the S-NSSAI included in the requested NSSAI may be an S-NSSAI for which the back-off timer associated with that S-NSSAI and / or its mapped S-NSSAI is not running in the UE.

[0121] Also, the allowed NSSAI is information indicating one or more network slices to which the UE is allowed. In other words, the allowed NSSAI is information identifying a network slice to which the network allows the UE to connect. The allowed NSSAI may be an allowed NSSAI stored in the UE and / or the NW, or may be an allowed NSSAI transmitted from the NW to the UE. In this case, the allowed NSSAI may refer to the allowed NSSAI IE of 3GPP.

[0122] The allowed NSSAI IE sent from the NW to the UE may include a list of S-NSSAIs of the current PLMN or SNPN that are valid for the current PLMN or SNPN when not roaming.

[0123] When roaming, the allowed NSSAI IE sent from the NW to the UE may include a list of S-NSSAIs of the current PLMN or SNPN that are valid for the current PLMN or SNPN, and may also include a list of mapped S-NSSAIs, which are the S-NSSAIs of the HPLMN or HSNPN to which the S-NSSAIs of the current PLMN or SNPN are mapped.

[0124] Note that a list of S-NSSAIs of the current PLMN or SNPN that are valid for the current PLMN or SNPN and included in the allowed NSSAI IE may be referred to as the Allowed NSSAI, and a list of mapped S-NSSAIs that are S-NSSAIs of the HPLMN or HSNPN to which the S-NSSAIs of the current PLMN or SNPN are mapped may be referred to as the list of mapped S-NSSAIs of the Allowed NSSAI. Here, the list of mapped S-NSSAIs of the Allowed NSSAI may be 3GPP mapped S-NSSAI(s) for the allowed NSSAI for a PLMN. Similarly, the Allowed NSSAI may mean 3GPP allowed NSSAI for a PLMN or an SNPN.

[0125] The UE and / or NW may store and manage the allowed NSSAI for each access (3GPP access or non-3GPP access) as information of the UE. The UE and / or NW may further manage the allowed NSSAI in association with a registration area.

[0126] Furthermore, the UE and / or NW may store and manage an allowed NSSAI associated with a PLMN or an SNPN as information of the UE. An allowed NSSAI may be associated with multiple PLMNs, where the multiple PLMNs may be EPLMNs, and the multiple SNPNs may be ESNPNs.

[0127] In this document, an allowed NSSAI associated with a PLMN or SNPN and an access type may be expressed as an "allowed NSSAI for a PLMN or SNPN and an access type" or an "allowed NSSAI for an access type of a PLMN or SNPN."

[0128] An S-NSSAI included in an allowed NSSAI may be expressed as an allowed S-NSSAI. The allowed S-NSSAI may be transmitted or received using the S-NSSAI IE, in which case the allowed S-NSSAI (SST and / or SD) may be configured to include the S-NSSAI and the mapped S-NSSAI (SST of the mapped HPLMN or SNPN and / or SD of the mapped HPLMN or SNPN) (if any, for example, when the UE is roaming or when the associated PLMN or SNPN is a VPLMN or VSNPN).

[0129] Alternatively, the S-NSSAI (SST and / or SD) of a PLMN or SNPN and the S-NSSAI (SST of a mapped HPLMN or SNPN and / or SD of a mapped HPLMN or SNPN) of a HPLMN or SNPN may be treated independently. Specifically, the Allowed S-NSSAI of a PLMN or SNPN may be expressed as "allowed S-NSSAI for a PLMN or SNPN" or "allowed S-NSSAI of a PLMN or SNPN" or "allowed S-NSSAI for a PLMN or SNPN."

[0130] Furthermore, one or more S-NSSAIs of an HPLMN or HSNPN to which the allowed S-NSSAI is mapped may be expressed as "one or more mapped S-NSSAIs for an allowed NSSAI of a PLMN or SNPN" or "one or more mapped S-NSSAIs for an allowed NSSAI of a PLMN or SNPN."

[0131] Furthermore, the rejected NSSAI is information indicating one or more network slices that the UE is not permitted to use or request. In other words, the rejected NSSAI is information identifying a network slice to which the network does not permit the UE to connect. The rejected NSSAI transmitted from the NW to the UE may be included in the rejected NSSAI IE or the extended rejected NSSAI IE.

[0132] The rejected NSSAI transmitted and received using the rejected NSSAI IE may be information including one or more combinations of the S-NSSAI (SST and / or SD) and a rejection reason value (rejected S-NSSAI).The rejected NSSAI transmitted and received using the Extended rejected NSSAI IE may be information including one or more combinations of the S-NSSAI (SST and / or SD) and the mapped S-NSSAI (SST of the mapped HPLMN or SNPN and / or SD of the mapped HPLMN or SNPN) (if any, for example, when the UE is roaming or when the associated PLMN or SNPN is a VPLMN or VSNPN) and a rejection reason value (rejected S-NSSAI) in the case of roaming.

[0133] The Extended rejected NSSAI IE may include one or more sets of Rejected S-NSSAs and / or NSSAIs (5GS Partial extended rejected NSSAI list), and the set of Rejected S-NSSAIs may include information indicating the type of this set.

[0134] The information indicating the type of set may be, for example, information indicating that the set includes one or more rejected S-NSSAIs (SST and / or SD) with associated back-off timer values, or information indicating that the set includes one or more rejected S-NSSAIs (SST and / or SD) without associated back-off timer values.

[0135] If the information indicating the type of set is information indicating that this set includes one or more rejected S-NSSAIs with associated back-off timer values, the set of rejected S-NSSAIs may include a back-off timer value.

[0136] Here, the S-NSSAI included in the rejected NSSAI may be associated with a PLMN ID or an SNPN ID. Note that the PLMN or SNPN indicated by the PLMN ID or SNPN ID associated with the S-NSSAI included in the rejected NSSAI may be the current PLMN or the current SNPN. Alternatively, the PLMN ID or SNPN ID associated with the S-NSSAI included in the rejected NSSAI may be information indicating an HPLMN or an HSNPN, regardless of the current PLMN or SNPN.

[0137] Here, the rejection reason value is information indicating the reason why the network rejects the corresponding S-NSSAI or the combination of the corresponding S-NSSAI and the mapped S-NSSAI (if any). The UE and / or the network may store and manage each S-NSSAI and / or the mapped S-NSSAI (if any) as an appropriate rejected NSSAI and / or the mapped S-NSSAI of the rejected NSSAI based on the rejection reason value associated with each S-NSSAI or the combination of the corresponding S-NSSAI and the mapped S-NSSAI.

[0138] Furthermore, the rejected NSSAI may be included in an NAS message transmitted from the network to the UE, such as a registration accept message, a configuration update command, or a registration reject message, or in an RRC message including an NAS message. The S-NSSAI included in the rejected NSSAI may be expressed as the rejected S-NSSAI.

[0139] When the UE is roaming, the rejected NSSAI may be transmitted using the Rejected NSSAI IE or may be transmitted using the Extended rejected NSSAI IE. The Extended rejected NSSAI IE may include one or more rejected S-NSSAI (IEs) consisting of the S-NSSAI (SST and / or SD) of the current PLMN or SNPN, the mapped S-NSSAI (SST of the mapped HPLMN or SNPN and / or SD of the mapped HPLMN or SNPN), and a rejection reason value. The UE may understand that the received S-NSSAI of the current PLMN or SNPN together with the received mapped S-NSSAI has been rejected from the NW. On the other hand, the Rejected NSSAI IE may include a rejected S-NSSAI IE with the S-NSSAI of the current PLMN or SNPN and a rejection reason value, and the UE may understand that the request to the NW for the S-NSSAI associated with the received S-NSSAI of the current PLMN or SNPN, or the S-NSSAI of the HPLMN or HSNPN, has been rejected.

[0140] The rejected NSSAI may be any one of the first to fifth rejected NSSAIs, one or more mapped S-NSSAIs for the first rejected NSSAI, one or more mapped S-NSSAIs for the second rejected NSSAI, one or more mapped S-NSSAIs for the fourth rejected NSSAI, and one or more mapped S-NSSAIs for the fifth rejected NSSAI, or a combination thereof. The S-NSSAI included in the rejected NSSAI may be expressed as the rejected S-NSSAI. The rejected S-NSSAI may be transmitted and received between devices using the S-NSSAI IE, and the S-NSSAI IE indicating the rejected NSSAI may include the S-NSSAI and the mapped S-NSSAI.

[0141] The UE and / or NW may store and manage the rejected NSSAI associated with the PLMN or SNPN as information of the UE. The rejected NSSAI may be further associated with one or more other PLMNs or SNPNs, where the one or more other PLMNs may be EPLMNs and the one or more other SNPNs may be ESNPNs.

[0142] The PDU (Protocol Data Unit / Packet Data Unit) session type indicates the type of PDU session, and can be IPv4, IPv6, Ethernet, or Unstructured. If IPv4 is specified, it indicates that data will be sent and received using IPv4. If IPv6 is specified, it indicates that data will be sent and received using IPv6. If Ethernet is specified, it indicates that Ethernet frames will be sent and received. Ethernet may also indicate that communication using IP is not performed. If Unstructured is specified, it indicates that data will be sent and received to an application server or the like in the DN using Point-to-Point (P2P) tunneling technology. As the P2P tunneling technology, for example, UDP / IP encapsulation technology may be used. In addition to the above, the PDU session type may also include IP. IP can be specified if the UE is capable of using both IPv4 and IPv6.

[0143] A PLMN (Public Land Mobile Network) is a communication network that provides mobile radio communication services. A PLMN is a network managed by an operator, which is a communications carrier, and the operator can be identified by a PLMN ID. A PLMN that matches the MCC (Mobile Country Code) and MNC (Mobile Network Code) of a UE's IMSI (International Mobile Subscriber Identity) may be a Home PLMN (HPLMN). Furthermore, a UE may store an Equivalent HPLMN list (also referred to as equivalent HPLMN) in its USIM to identify one or more Equivalent HPLMNs (EPLMNs). A PLMN that is different from the HPLMN and / or EPLMN may be a Visited PLMN (VPLMN). A PLMN to which a UE has successfully registered may be a Registered PLMN (RPLMN).

[0144] A tracking area is a single or multiple ranges managed by the core network that can be represented by the location information of UE_A10. Note that a tracking area may be composed of multiple cells. Furthermore, a tracking area may be an area in which control messages such as paging are broadcast, or an area in which UE_A10 can move without performing a handover procedure. Furthermore, a tracking area may be a routing area, a location area, or anything similar. Hereinafter, a tracking area may be a TA (Tracking Area). A tracking area may be identified by a TAI (Tracking Area Identity) consisting of a TAC (Tracking area code) and a PLMN.

[0145] A registration area is a collection of one or more TAs assigned to a UE by the AMF. Note that while UE_A10 is moving within one or more TAs included in the registration area, it may be able to move without sending or receiving signals for tracking area update. In other words, a registration area may be a group of information indicating areas in which UE_A10 can move without performing a tracking area update procedure. A registration area may be identified by a TAI list consisting of one or more TAIs.

[0146] The Current TAI is the TAI broadcast by the selected PLMN in the cell where the UE is located or camped, or if the cell is a satellite NG-RAN cell that broadcasts multiple Tracking Area Codes (TACs) in the selected PLMN, the UE NAS layer may select the current TAI from multiple Tracking Area Codes (TACs) in the selected PLMN.

[0147] The Lists of 5GS forbidden tracking areas may be a list of 5GS forbidden tracking areas for roaming and / or a list of 5GS forbidden tracking areas for regional provision of service stored by a UE not operating in an SNPN access operation mode. In other words, a UE not operating in an SNPN access operation mode must store a list of 5GS forbidden tracking areas for roaming and / or a list of 5GS forbidden tracking areas for regional service provision. Furthermore, the UE must search for a suitable cell within the same PLMN that belongs to a TA that is not included in the list of 5GS forbidden tracking areas.

[0148] Furthermore, a UE is not permitted to request 5GS services other than emergency services if it is located in a cell of a TA that belongs to the list of 5GS forbidden tracking areas for regional provision of service.

[0149] The UE may also store the forbidden tracking area ID (TAI) in a list of 5GS forbidden tracking areas for regional service provision to prevent repeated attempts to access cells in the forbidden tracking area. Furthermore, the list of 5GS forbidden tracking areas for regional service provision may be deleted when the UE is powered off, when the SIM is removed, or periodically (for a period ranging from 12 to 24 hours).

[0150] In addition, the information indicating the 5GS forbidden tracking areas for roaming may be included in an information element (IE) containing one or more forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" included in a message sent by the network, and transmitted to the UE.

[0151] In addition, the 5GS forbidden tracking areas for regional provision of service may be included in an information element (IE) containing one or more forbidden TAIs for the list of "5GS forbidden tracking areas for regional provision of service" (5GS forbidden tracking areas for roaming) included in a message sent by the network and transmitted to the UE.

[0152] The UE ID is information for identifying a UE. For example, the UE ID may be a SUCI (Subscription Concealed Identifier), a SUPI (Subscription Permanent Identifier), a GUTI (Globally Unique Temporary Identifier), an IMEI (International Mobile Subscriber Identity), an IMEISV (IMEI Software Version), or a TMSI (Temporary Mobile Subscriber Identity). Alternatively, the UE ID may be other information set in an application or a network. Furthermore, the UE ID may be information for identifying a user.

[0153] Next, a UAV (Uncrewed Aerial Vehicle) may be a flying drone. The UAV may be associated with a UAV controller. Furthermore, the UAV may be associated with the UAV controller and managed by a core network device and / or UTM (UAS Traffic Management). Furthermore, when the UAV is associated with a UAV controller (described later) and managed, it may be managed as a UAS by the core network device and / or UTM. The UAV's own information (identification information, IP address, location information, etc.) may be managed by the core network device and / or UTM. Furthermore, the UAV may be a UE. Note that the UAV may also be referred to as an aerial UE, etc.

[0154] Next, a UAV controller (UAV-C) is a controller for operating a UAV. The UAV controller may be associated with the UAV. Furthermore, the UAV controller may be associated with the UAV and managed by a core network device and / or a UTM. Furthermore, when the UAV controller is associated with the UAV and managed, it may be managed as a UAS by the core network device and / or a UTM. The UAV controller's own information (identification information, IP address, location information, etc.) may be managed by the core network device and / or a UTM. Furthermore, the UAV controller may be a UE. Note that the UAV controller may be expressed as a UAC or a UAV-C. Furthermore, the UAV-C may be a UE.

[0155] Next, a UAS (Uncrewed Aerial System) may be composed of a UAV and a UAV controller. The UAS may be managed by a core network device and / or a UTM. The UAS may be composed of one UAV and one UAV controller.

[0156] Furthermore, a UAS (Uncrewed Aerial System) may be composed of a UAV and related functions. Here, the related functions may include a C2 (command and control) link. Furthermore, the C2 link may be a link between the UAV and a control device, or a link between the UAV and a network. Furthermore, the C2 link may be a link for remote identification.

[0157] Next, the network refers to at least a part of the access network _B, the core network _B, and the DN. Furthermore, one or more devices included in at least a part of the access network _B, the core network _B, and the DN may be referred to as a network or a network device.

[0158] That is, when a network transmits, receives, and / or processes messages, it may mean that devices in the network (network devices and / or control devices) transmit, receive, and / or process messages. Conversely, when a device in the network transmits, receives, receives, and / or processes messages, it may mean that the network transmits, receives, receives, and / or processes messages.

[0159] Next, PC5 is a reference point, and PC5 may be a reference point between ProSe-enabled UEs, a reference point between UAS-enabled UEs, a reference point between A2X-enabled UEs, a reference point between UEs, or a reference point between terminal devices.

[0160] Next, a PC5 path may be a communication path on PC5. Also, the PC5 path may be a communication path between ProSe-enabled UEs, a communication path between UAS-enabled UEs, a communication path between A2X-enabled UEs, a communication path between UEs, or a communication path between terminal devices. Note that the PC5 path may also be referred to as a PC5 interface.

[0161] Next, Uu may be a radio interface, and Uu may be a radio interface between a 5G AN and a UE.

[0162] Next, the Uu path may be a communication path on Uu. Also, the Uu path may be a communication path between the 5G AN and the UE. Note that the Uu path may also be referred to as a communication path via Uu, a communication path via a Uu reference point, or simply a Uu interface.

[0163] Next, the initiating UE may be a UE that transmits and receives messages to and from the target UE.

[0164] Next, the target UE may be a UE that transmits and receives messages to and from the initiating UE.

[0165] Next, A2X (Aircraft-to-Anything) communication is communication for supporting A2X services utilizing the PC5 reference point. Here, the A2X service may be realized by various types of A2X applications, such as BRID (Broadcast Remote ID) and DAA (Detect And Avoid). A2X communication may be communication on PC5.

[0166] Next, A2X services are A2X applications and data services provided by A2X application servers. An A2X service may belong to one A2X service type. An A2X service can be associated with one or more A2X applications, and an A2X application can be associated with one or more A2X services.

[0167] Next, DAA (Detect And Avoid) is the ability to see, sense, or detect conflicting traffic or other hazards and take appropriate action. Furthermore, DAA may include DDAA (Direct Detect And Avoid), and / or Ground-based DAA, and / or NWDAA (Network-Based / Assisted DAA).

[0168] Here, DDAA is a DAA that utilizes communication over the PC5 reference point. In DDAA, UAVs may perform communication for DAA through direct communication via PC5. Ground-based DAA is a DAA in which the AAM (described below) and UAVs communicate directly via PC5. NWDAA may be a network-assisted / ground-based DAA mechanism for collision avoidance and UAV flight path control using UTM. NWDAA may complement DDAA, a conventional DAA based on PC5 reference points, and NWDAA and DDAA may be used together.

[0169] An AAM (Area Airspace Manager) is one or more UEs installed in a specific area to provide a network-assisted (ground-based) DAA solution. The AAM has a function for managing the area airspace and may further have a function for communicating directly with UAVs via PC5. The AAM may also grasp detailed spatial information about facilities in the specific area and apply local DAA rules defined based on this information to UAVs in the managed airspace.

[0170] A No-Transmit Zone (NTZ) may be a geographical area in which aerial UEs or UAVs are not permitted to communicate and perform communication-related operations in a specific frequency band. Furthermore, an NTZ may be defined at a national level as a geographical area in which aerial UEs or UAVs are not permitted or prohibited from communicating and performing communication-related operations in a specific frequency band based on the need for spectrum operational restrictions. The NTZ and NTZ-related functions described in this embodiment may be referred to by other names. An NTZ may also be a geographical area in which aerial UEs or UAVs are not permitted to communicate and perform communication-related operations in a specific frequency band and / or carrier frequency.

[0171] Additionally, the UE, and / or the network, and / or each device / function of the network may or may not support NTZ. Unless otherwise specified herein, the UE, and / or the network, and / or each device of the network may support NTZ. Details regarding support for NTZ by the UE and / or each device are described in this chapter and subsequent chapters.

[0172] Here, the restriction by the NTZ may be indicated by information about the NTZ (also referred to as NTZ information), which may be information in which information about the region (also referred to as a zone or area) to which the NTZ is applied and information about frequency bands in which communication and communication-related operations are not permitted in the region are associated. In other words, for example, the NTZ information may be information in which the region restricted by the NTZ is associated with one or more frequency bands corresponding to the region. Conversely, for example, the NTZ information may be information in which one or more NTZ-restricted regions are associated with frequency bands in which communication and communication-related operations are not permitted in the NTZ. Note that the area restricted by the NTZ may be one or more entire cells, may be composed of a part of one or more cells, may be an area indicated by a tracking area (TA) or TAI, or may be indicated as a geographical area, but is not limited to these. More specifically, for example, the information about the area restricted by the NTZ may be indicated by a geographical area, a cell ID, a TA, a TAI, an RA, etc.

[0173] Furthermore, for example, when a UE or UAV that supports NTZ enters an NTZ while moving, it may recognize that communication, message transmission, etc. using a specific frequency band included in the corresponding information about the NTZ is prohibited in a specific area included in the information about the NTZ that has been received and stored or pre-stored (preconfigured) by the UE.

[0174] Note that within the NTZ, transmission by a base station device (eNB or gNB) may or may not be prohibited.

[0175] Next, when a terminal device is "not served by E-UTRA" and / or "not served by NR", it may mean that the terminal device cannot communicate with the network, or it may mean that the terminal device is only available for communication over PC5.

[0176] Next, when a terminal device is "served by E-UTRA" and / or "served by NR", it may mean that the terminal device can communicate with the network, or that the terminal device can use communication on PC5 and / or communication on Uu.

[0177] Additionally, a terminal device being "not served by E-UTRA" may mean that the terminal device is unable to communicate with a base station or network using E-UTRA technology.

[0178] Additionally, a terminal device being "not served by NR" may mean that the terminal device cannot communicate with a base station or network using NR technology.

[0179] [3.2. Description of Identification Information in Each Embodiment] Next, the identification information used in each procedure of each embodiment will be described. In this specification, unless otherwise specified, UE may mean UE or UAV.

[0180] The first identification information in this embodiment is the capability information of the UE. The first identification information may be capability information indicating that the UE supports NTZ or does not support it. Unless otherwise specified in this specification, the first identification information may be information indicating that the UE supports NTZ.

[0181] In addition, in this specification, support for NTZ by a UE is also referred to as communication by the UE that takes NTZ into consideration, support for NTZ communication by the UE, support for the NTZ function by the UE, or the like.

[0182] Here, when a UE supports NTZ, it may mean that the UE supports sending and receiving information about NTZ, and / or recognizing and / or storing information about NTZ, and / or behaving based on information about NTZ.

[0183] Furthermore, the first identification information may be a 5GMM capability, a 5GMM capability IE (Information Element), or information included as part of the 5GMM capability. And / or the first identification information may be a 5GSM capability, a 5GSM capability IE (Information Element), or information included as part of the 5GSM capability. And / or the first identification information may be a Radio capability in an RRC message, or information included as part of the Radio capability.

[0184] That is, the first identification information may be identification information included in one or more, or all, of the MM message, and / or the SM message, and / or the RRC message.

[0185] Here, when the UE indicates the first identification information to the network, the network and each device may recognize that the UE supports NTZ. Furthermore, when the network receives the first identification information from the UE, it may recognize that the UE performs communication taking NTZ into consideration, or transitions to or activates a mode for performing NTZ communication.

[0186] In addition, when a network that does not support NTZ receives second identification information from a UE, the network may ignore or discard the first identification information.

[0187] Further details of the behavior of the UE and NW based on the first identification information are also described in Chapter 4 and / or Chapter 5.

[0188] The second identification information in this embodiment is information indicating the capability or function support of the network (NW). The second identification information may be information indicating that the network or each device on the network (also referred to as the network or NW) supports or does not support NTZ. Unless otherwise specified in this specification, the second identification information may be information indicating that the network or each device on the network supports NTZ.

[0189] In this specification, support for NTZ by a network or each device on the network is also referred to as network-based communication that takes NTZ into consideration, network-based support for NTZ communication, network-based support for NTZ functions, or the like.

[0190] Here, a network supporting NTZ may mean that the network supports sending and receiving information about NTZ, and / or recognizing and / or storing information about NTZ, and / or acting based on information about NTZ.

[0191] Furthermore, the second identification information may be information included in 5GS network feature support, or a 5GS network feature support IE, or as part of 5GS network feature support. And / or the second identification information may be information included in 5GSM network feature support, or a 5GSM network feature support IE (Information Element), or as part of 5GSM network feature support. And / or the second identification information may be information included in an RRC message or a part of an RRC message. And / or may be information included in broadcast information.

[0192] That is, the second identification information may be identification information included in one or more, or all, of the MM message, and / or the SM message, and / or the RRC message, and / or the broadcast information. Furthermore, for example, the second identification information may be information that the network transmits by being included in a response message when the network receives the first identification information included in any of the messages from the UE. Alternatively, the second identification information may be information that the network transmits when it does not receive any of the messages including the first identification information.

[0193] Here, the network may indicate the second identification information to the UE, so that the UE may recognize that the network and each device support NTZ. Furthermore, the UE that receives the second identification information from the network may recognize that the network performs communication taking NTZ into consideration, or has transitioned to or activated a mode for performing NTZ communication.

[0194] In addition, when a UE that does not support NTZ receives second identification information from the NW, the UE may ignore or discard the second identification information.

[0195] Further details of the behavior of the UE and NW based on the second identification information are also described in Chapter 4 and / or Chapter 5.

[0196] The third identification information in this embodiment may be information about the NTZ. The information about the NTZ may simply be referred to as NTZ information. The information about the NTZ indicated by the third identification information may include at least information related to the area or region (zone) to which the NTZ applies and / or information related to frequencies subject to regulation in the NTZ.

[0197] Furthermore, the third identification information may be information configured by associating information related to the area or region (zone) to which the NTZ is applied with information related to frequencies subject to regulation in the NTZ. Furthermore, the third identification information may be information configured by a plurality of combinations of information related to the area or region (zone) to which the NTZ is applied and information related to frequencies subject to regulation in the NTZ.

[0198] Furthermore, here, the frequency that is subject to regulation in the NTZ and that is included in the third identification information may be a frequency at which transmission by a UE or aerial UE is restricted in the NTZ. Note that in this specification, information related to the frequency that is subject to regulation in the NTZ and that is included in the third identification information is also referred to as frequency-related information, etc. More specifically, for example, the information related to the frequency that is subject to regulation in the NTZ and that is included in the third identification information may be a frequency band and / or a carrier frequency.

[0199] Here, the information regarding the area or region to which the NTZ is applied, which is included in the third identification information, may include one or more of geographical location information indicating the region (also referred to as area or zone) to which the NTZ is applied, and / or a cell ID, and / or information indicating a tracking area (TA), and / or a TAI, and / or a registration area (RA), etc. Here, the information indicating the tracking area may be a TAI or a TAC, or may be information indicating a tracking area other than these. Unless otherwise specified in this specification, the information indicating the tracking area may be a TAI.

[0200] In other words, for example, the third identification information is information relating to the area or region to which the NTZ applies, and one or more of geographical location information, and / or cell ID, and / or TAI, and / or Registration Area, etc. indicating the region to which the NTZ applies (also referred to as area or zone) may be included in the third identification information in association with information relating to the frequencies subject to regulation in the NTZ.

[0201] Here, for example, the geolocation area information, and / or cell ID, and / or TAI, and / or Registration Area included in the information related to the NTZ may be information indicating an area or zone where an aerial UE or UAV is not permitted to use a specific frequency band. Furthermore, for example, the area where the NTZ is applied may be an area or region indicated by information related to the area or region (zone) where the NTZ is applied, which is included in the third identification. Note that the area where the NTZ is applied may be an area where one or more NTZs are applied.

[0202] Here, the area where one or more NTZs are applied may be an area where multiple different NTZs are applied in the same area. In other words, for example, an aerial UE may receive multiple pieces of third identification information related to the same area and recognize that multiple NTZs are applied in the area, and transmission using the frequencies indicated by each piece of third identification information may be restricted in the area.

[0203] Furthermore, the third identification information may be identification information prepared for each PLMN. A UE that receives the third identification information for each PLMN may store the content indicated by the third identification information as information for each PLMN.

[0204] Furthermore, the frequency-related information included in the information regarding the NTZ indicated by the third identification information may be a frequency band and / or a carrier frequency, etc., and may be a frequency band and / or a carrier frequency that a UE and / or an aerial UE or UAV is not permitted to use in a specific geographical area where the NTZ is applied. In other words, the frequency-related information included in the third identification information may be information related to frequencies, such as a frequency band and / or a carrier frequency, that a UE or a UAV cannot use for communication in an area where the NTZ is applied. Unless otherwise specified herein, the frequency-related information included in the third identification information may be information related to frequencies, such as a frequency band and / or a carrier frequency, that a UE or a UAV cannot use for communication in an area where the NTZ is applied, and is also referred to herein as "frequency-related information that a UE cannot use for communication." Note that, in this specification, information related to frequencies, such as a frequency band and / or a carrier frequency, which is frequency-related information included in the third identification information, is also simply referred to as a frequency band, a carrier frequency, etc. Conversely, when the term "frequency band" or "carrier frequency" is used, it may refer to information related to frequencies, such as the frequency band and / or carrier frequency, which are frequency-related information included in the third identification information.

[0205] Alternatively, the frequency-related information included in the third identification information, which is the NTZ information, may be a frequency band and / or a carrier frequency that the UE and / or aerial UE or UAV is permitted to use in a specific geographical area where the NTZ is applied, etc. That is, the frequency-related information included in the third identification information may be information related to frequencies, such as a frequency band and / or a carrier frequency, that the UE or UAV can use for communication in an area where the NTZ is applied, and is also referred to herein as "frequency-related information that the UE can use for communication," etc. In this specification, specific examples of the behavior of the UE and / or each device in the network when the frequency-related information included in the third identification information is information related to frequencies, such as a frequency band and / or a carrier frequency, that the UE or UAV can use for communication in an area where the NTZ is applied, will also be described in the sixth embodiment. Furthermore, if the third identification information is frequency-related information that the UE can use for communication, the frequency-related information that the UE cannot use for communication and the associated behavior of the UE or network in this specification may be read as the behavior of the UE or network based on the frequency-related information that the UE can use for communication and the contents indicated by the frequency-related information that the UE can use for communication.

[0206] Alternatively, the frequency-related information included in the third identification information, which is the NTZ information, may be information including both frequency bands and / or carrier frequencies, etc. that the UE and / or aerial UE or UAV is not permitted to use in a specific geographical area to which the NTZ is applied, and frequency bands and / or carrier frequencies, etc. that the UE and / or aerial UE or UAV is permitted to use in a specific geographical area to which the NTZ is applied. That is, the third identification information may be identification information including both content indicated by frequency-related information that the UE cannot use for communication and content indicated by frequency-related information that the UE can use for communication. Herein, this information is also referred to as frequency-related information that the UE cannot use for communication and available frequency-related information, etc. When a UE receives third identification information including frequency-related information that the UE cannot use for communication and available frequency-related information, if the frequency-related information that the UE cannot use in the third identification information is information related to frequencies that the UE can use for communication, and if the frequency band and / or carrier frequency, etc. used in the NTZ application area do not match the information included in the third identification information, the UE may recognize that the UE is using a frequency band and / or carrier frequency, etc. that is not permitted in the NTZ application area. Furthermore, the UE may select, switch, and use a frequency band, etc. to be used by the UE from the frequency-related information that the UE can use, included in the third identification information. Here, when the third identification information is frequency-related information that the UE can use for communication, the frequency-related information that the UE cannot use for communication and the associated behavior of the UE or network in this specification may be interpreted as the UE or network behaving based on the frequency-related information that the UE can use for communication and the content indicated by the frequency-related information that the UE can use for communication.

[0207] Here, the third identification information may be information generated and stored by a network operator and / or each device in the network. The UE may receive the third identification information from an access network, a gNB that is one of the devices constituting the access network, a core network, or each device in the core network. More specifically, for example, the UE or UAV may receive the NTZ information indicated by the third identification information included in an RRC message transmitted from the gNB. Alternatively, for example, the UE or UAV may recognize and store the content of the NTZ information indicated by the third identification information received from the access network and / or the core network.

[0208] Here, for example, the third identification information may be configured as information that associates information about the area of ​​the NTZ with information about the frequency of the NTZ, such as the frequency band and / or carrier frequency.

[0209] Furthermore, the third identification information may be information listed for each of a plurality of areas. More specifically, for example, if there are a plurality of NTZs, such as NTZ #1 and NTZ #2, the third identification information may be listed or configured as a list in which geographical location information, cell ID, TAI, and / or frequency band for each NTZ are associated with each other.

[0210] Furthermore, the third identification information may be included in broadcast information (MIB and / or SIB), and / or an RRC (Radio Resource Control) message, and / or an MM message, and / or an SM message, and transmitted or delivered from the network to the UE. More specifically, for example, a UE supporting NTZ may store broadcast information (MIB and / or SIB) or an RRC message containing the third identification information when it receives the broadcast information. Alternatively, for example, a UE supporting NTZ may include the first identification information in an MM message and transmit it, and the network that receives the MM message containing the first identification information may transmit an MM message containing the second and / or third identification information to the UE, but this is not limited thereto.

[0211] Furthermore, the network may include the third identification information in one or more of the aforementioned messages and send it to the UE to indicate the network's NTZ support indicated by the second identification information. In other words, for example, the network may include only the third identification information in one or more of the aforementioned messages and send it to the UE to indicate to the UE that the network supports NTZ.

[0212] Here, for example, a network (access network or core network) or each device of the network may receive a first identification from a UE, and if the network supports NTZ, may transmit a third identification and / or a second identification to the UE.

[0213] The information indicated by the third identification information may be preconfigured in the UE, i.e., information that has been set and stored in advance. Here, when the UE preconfigured with the third identification information has not received the third identification information from the network, the UE may perform communication taking NTZ into consideration based on the information indicated by the preconfigured third identification information.

[0214] Furthermore, when a UE that has received and stored or preconfigured third identification information further receives a message including new third identification information, the UE may replace or add the preconfigured third identification information. Furthermore, when the third identification information received by the UE is null, the UE may delete the information indicated by the already stored third identification information.

[0215] Further details of the behavior of the UE and NW based on the third identification information are also described in Chapter 4 and / or Chapter 5.

[0216] The second and third identification information may be included in the message as individual pieces of identification information, or may be included in the message as a single piece of information combining one or more pieces of identification information. Furthermore, a single piece of information combining one or more pieces of the second and third identification information may represent a combination of the matters indicated by the identification information described in this chapter. In other words, when multiple pieces of identification information are transmitted and received, two or more pieces of this identification information may be configured as one or more pieces of identification information. Furthermore, the information indicating support for each function and the information indicating a request for use of each function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

[0217] Details of the behavior of the UE and the network based on one or a combination of the above first to third identification information are not limited to those described in this chapter, but are also described in Chapter 4 and / or Chapter 5.

[0218] [4. Description of procedures used in each embodiment] Next, procedures used in each embodiment will be described. Here, the procedures used in each embodiment may include broadcast information / RRC messages, procedures for mobility management, and various procedures for session management.

[0219] Unless otherwise specified, the UE and the network may support NTZ in each procedure described in this chapter. In other words, NTZ information may be transmitted or broadcast from the network to the UE during each procedure described in this chapter.

[0220] In each embodiment, as shown in FIG. 2, the HSS and UDM, PCF and PCRF, SMF and PGW-C, and UPF and PGW-U are each configured as the same device (i.e., the same physical hardware, the same logical hardware, or the same software). However, the contents described in this embodiment are also applicable to cases where these are configured as different devices (i.e., different physical hardware, different logical hardware, or different software). For example, data may be transmitted and received directly between these devices, or data may be transmitted and received via the N26 interface between the AMF and MME, or data may be transmitted and received via the UE.

[0221] [4.1. Broadcast Information / RRC Messages] The broadcast information may be information included in a message, a signal, and / or a beacon frame transmitted to the UE from an AN and / or a gNB, which is a device constituting the AN. The broadcast information may also be referred to as system information. Furthermore, the broadcast information may include a MIB (Master Information Block) and / or a SIB (System Information Block).

[0222] And / or, the RRC message may be a message transmitted and received as an RRC message executed between the UE and the AN and / or a gNB that is a device constituting the AN. In this specification, unless otherwise specified, the RRC message may be an RRC message received by the UE.

[0223] On the other hand, if the gNB does not receive first identification information indicating that NTZ is supported from any UE in the cell of the gNB, or if the gNB receives first identification information indicating that NTZ is not supported from all UEs in the cell of the gNB, the gNB may not need to transmit the second and / or third identification information to the UE or the cell of the gNB.

[0224] Here, for example, the UE or UAV may include first identification information indicating that NTZ is supported as the UE radio capability (also simply referred to as radio capability) of the UE or UAV in the RRC message and transmit the first identification information to the gNB. Furthermore, for example, the gNB may transmit a response RRC message to the UE or UAV in response to the RRC message including the first identification information, the response message including the second identification information and / or the third identification information.

[0225] The broadcast information or the RRC message may include the third identification information, or the gNB may transmit the broadcast information or the RRC message including the third identification information to the UE. Furthermore, the UE may receive the broadcast information or the RRC message including the third identification information from the gNB. Here, the UE may recognize that the network supports NTZ because the received broadcast information or the RRC message includes the third identification information. Furthermore, the UE may store the received third identification information in the context it holds.

[0226] Furthermore, the gNB may transmit broadcast information or an RRC message including the third identification information regardless of whether or not it receives the first identification information from the UE and / or whether or not the UE supports NTZ. In other words, for example, the gNB may transmit broadcast information or an RRC message including the third identification information to the UE even if the UE does not support NTZ. Furthermore, for example, when a UE that does not support NTZ receives broadcast information or an RRC message including the third identification information, the UE may ignore the information indicated by the third identification information, may recognize it as an error, or may not be subject to the NTZ restriction regardless of whether or not it enters NTZ.

[0227] [4.2. Mobility Management Procedures] The Mobility Management (MM) procedure will now be described.

[0228] Here, the MM procedure may include a registration procedure, a de-registration procedure, a generic UE configuration update procedure, a NAS transport procedure, a service request procedure, a notification procedure, etc.

[0229] These MM procedures may include UE-initiated (or UE-requested) procedures and network-initiated (or NW-requested) procedures. In this specification, a network-initiated procedure is also referred to as a network-initiated (NW-init) procedure, and a UE-initiated procedure is also referred to as a UE-initiated (UE-init) procedure.

[0230] More specifically, for example, the non-registration procedure and the NAS transport procedure may include both UE-initiated and NW-initiated procedures. Also, for example, the registration procedure and the service request procedure may only include UE-initiated procedures. Also, for example, the UE configuration update procedure and the notification procedure may only include NW-initiated procedures.

[0231] Furthermore, the UE may include the first identification information in an initial message initiating the UE-initiated MM procedure and transmit the message to the network, or the network may receive a message including the first identification information from the UE. Furthermore, the network that receives the first identification information from the UE may recognize that the UE supports NTZ, and based on this recognition, may include the second and / or third identification information in a response message to the request message received from the UE and transmit the response message to the UE. Conversely, if the network does not receive from the UE first identification information indicating that NTZ is supported or receives from the UE first identification information indicating that NTZ is not supported, the network may transmit the response message to the request message received from the UE without including the second and / or third identification information.

[0232] Here, in a UE-initiated MM procedure, the first message including the first identification information that the UE sends to the network may be a registration request message in a registration procedure, or a deregistration request (DEREGISTRATION REQUEST) message in a deregistration procedure, or a service request message in a service request procedure, or a UL NAS TRANSPORT message in a NAS transport procedure.

[0233] Furthermore, in a UE-initiated MM procedure, the response message including the second and / or third identification information may be a registration accept message or a registration reject message in a registration procedure, or a deregistration accept message in a deregistration procedure, or a service accept message or a service reject message in a service request procedure, or a DL NAS TRANSPORT message in a NAS transport procedure.

[0234] The NW may also include the second and / or third identification information in an initial message initiating a NW-initiated MM procedure and send it to the UE, or the UE may receive a message from the NW including the second and / or third identification information. Furthermore, a UE that supports NTZ and receives the second and / or third identification information from the NW may recognize that the NW supports NTZ and may store the third identification information if it is included.

[0235] Here, in a NW-initiated MM procedure, the first message including the second and / or third identification information that the NW sends to the UE may be a non-registration request message in a non-registration procedure, or a configuration update command message in a UE configuration update procedure, or a DL NAS TRANSPORT message in a NAS transport procedure.

[0236] In addition, when the NW transmits the second and / or third identification information to the UE in the NW-initiated MM procedure, the NW may recognize that the UE supports NTZ from another procedure, subscription information of the UE, etc. In other words, for example, when the NW or the AMF recognizes that the UE supports NTZ, the NW or the AMF may transmit a message including the second and / or third identification information to the UE.

[0237] In addition, the network may indicate that it supports NTZ by sending a message to the UE containing only the third identification information and not the second identification information, and a UE that receives a message containing the third identification information but not the second identification information may recognize that the network supports NTZ.

[0238] Below, as an example of a mobility management procedure, a registration procedure will be explained using FIG. 6. The registration procedure is a procedure in 5GS. Hereinafter, in this section, this procedure refers to the registration procedure. The registration procedure is a procedure initiated by the UE to register with the access network _B and / or the core network _B and / or the DN. If the UE is not registered with the network, it can execute this procedure at any time, for example, when powered on. In other words, if the UE is in the unregistered state (RM-DEREGISTERED state), it can start this procedure at any time. Furthermore, each device (especially the UE and AMF) can transition to the registered state (RM-REGISTERED state) based on the completion of the registration procedure.

[0239] The registration procedure may be an initial registration initiated by the UE, or a mobility and periodic registration update, or a mobility registration update procedure. Here, the mobility registration update procedure may also be referred to as a registration procedure for mobility update. These registration procedures may also be MM procedures.

[0240] Furthermore, the registration procedure may be a procedure for updating the location registration information of the UE in the network, and / or for the UE to periodically notify the network of the status of the UE, and / or for updating certain parameters related to the UE in the network, or may be a mobility registration update procedure performed after the completion of the initial registration procedure and the expiration of the unavailability period to resume normal service.

[0241] This procedure may also be a procedure for registration by a UE via NR satellite access. Furthermore, the PDU session established after completion of this procedure may be a PDU session via the satellite NG-RAN or NR satellite access. In other words, for example, a PDU session established by a PDU session establishment procedure performed after completion of the registration procedure via NR satellite access may be a PDU session via NR satellite access. Alternatively, for example, a PDU session via NR satellite access may be established based on completion of this procedure.

[0242] A UE may initiate a registration procedure when performing mobility across TAs. More specifically, a UE may initiate a Mobility Registration Update procedure to re-register when it moves to a TA different from the TA indicated in the TA list it holds. Furthermore, a UE may initiate this procedure when a running timer expires. Furthermore, a UE may initiate a registration procedure when a context update for each device is required due to a PDU session disconnection or invalidation. Furthermore, a UE may initiate a registration procedure when a change occurs in the capability information and / or preferences related to the establishment of a PDU session. Furthermore, a UE may initiate a registration procedure periodically. Furthermore, a UE may initiate a registration procedure based on the completion of a UE Configuration Update procedure. However, the UE may perform the registration procedure at any timing, not limited to these.

[0243] Furthermore, even when the UE is in a registered state, the UE may periodically initiate the registration procedure. In other words, the UE may initiate the registration procedure based on the expiration of a timer. In other words, the registration procedure performed periodically may be a periodic registration update procedure.

[0244] The registration procedure performed based on the mobility of the UE and the registration procedure performed periodically are also referred to as a registration procedure for mobility and registration update or a registration update procedure. In other words, the registration procedure for mobility and registration update may be a registration procedure performed based on the mobility of the UE, or may be a registration procedure performed periodically. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed based on a configuration update of the UE. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed to establish a communication path for transmitting and receiving user data. Furthermore, the registration procedure for mobility and registration update may be a registration procedure performed based on a request from the network. Furthermore, in other words, the registration procedure for mobility and registration update may be a registration procedure other than the initial registration procedure. Hereinafter, the registration procedure for mobility and registration update may be referred to as the main procedure.

[0245] Next, each step of the registration procedure will be described. Note that the registration procedure described below may be an initial registration procedure or a registration procedure for mobility and registration renewal.

[0246] First, the UE starts the registration procedure by sending a registration request message to the AMF (S600) (S602) (S604). Specifically, the UE sends an RRC message including a registration request message to the 5G AN (or gNB) (S600). The registration request message is a NAS message. The RRC message may be a control message transmitted and received between the UE and the 5G AN (or gNB). The NAS message is processed in the NAS layer, and the RRC message is processed in the RRC layer. The NAS layer is a layer higher than the RRC layer.

[0247] Here, the UE may send the first identification information in a registration request message. By sending the first identification information in the registration request message, the UE may indicate to the network that the UE supports NTZ.

[0248] The UE may also initiate the PDU session establishment procedure during the registration procedure by sending an SM message included in or together with a registration request message, where the SM message may be a PDU session establishment request message.

[0249] When a 5G AN (or gNB) receives an RRC message including a registration request message or a NAS message indicating a registration request, the 5G AN (or gNB) selects an AMF to which to forward the registration request message (S602). Note that the 5G AN (or gNB) can select an AMF based on information included in the registration request message and / or the RRC message. The 5G AN (or gNB) extracts the registration request message from the received RRC message and forwards the registration request message to the selected AMF (S604). Here, the registration request message may include first identification information.

[0250] Here, the AMF that receives the registration request message including the first identification information from the UE may recognize and store the meaning of the first identification information included in the registration request message. That is, the network may recognize and store that the UE supports NTZ by receiving the first identification information.

[0251] When the AMF receives the registration request message, the AMF can perform a first condition determination. The first condition determination is for determining whether the network (or the AMF) accepts the UE's request. If the first condition determination is true, the AMF starts the procedure of (A) in Figure 6, while if the first condition determination is false, the AMF starts the procedure of (B) in Figure 6.

[0252] The first condition determination may be performed based on the reception of a registration request message, and / or each identification information included in the registration request message, and / or subscriber information, and / or network capability information, and / or operator policy, and / or network status, and / or user registration information, and / or a context held by the AMF, etc. For example, if the network permits the UE's request, the first condition determination may be true, and if the network does not permit the UE's request, the first condition determination may be false. Furthermore, if the network to which the UE is registered and / or a device within the network supports a function requested by the UE, the first condition determination may be true, and if the function requested by the UE is not supported, the first condition determination may be false. Furthermore, if the identification information to be transmitted and received is permitted, the first condition determination may be true, and if the identification information to be transmitted and received is not permitted, the first condition determination may be false. The conditions for determining whether the first condition determination is true or false do not have to be limited to the above-described conditions.

[0253] First, we will explain the case where the first condition determination is true. In the procedure of (A) in Figure 6, the AMF can first execute the fourth condition determination. The fourth condition determination is for determining whether the AMF transmits and receives SM messages to and from the SMF.

[0254] Furthermore, the fourth condition determination may be performed based on whether the AMF has received an SM message. Furthermore, the fourth condition determination may be performed based on whether an SM message is included in the registration request message. For example, if the AMF has received an SM message and / or if the registration request message includes an SM message, the fourth condition determination may be true, and if the AMF has not received an SM message and / or if the registration request message does not include an SM message, the fourth condition determination may be false. Furthermore, the conditions that determine the truth or falsity of the fourth condition determination do not have to be limited to the conditions described above.

[0255] Next, the AMF transmits a registration accept message to the UE via the 5G AN (or gNB) as a response message to the registration request message based on the reception of the registration request message and / or the completion of the transmission and reception of an SM message with the SMF (S608). For example, if the fourth condition determination is false, the AMF may transmit the registration accept message based on the reception of the registration request message from the UE. Also, if the fourth condition determination is true, the AMF may transmit the registration accept message based on the completion of the transmission and reception of an SM message with the SMF. Note that the registration accept message is a NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the 5G AN (gNB) included in an RRC message.

[0256] The AMF may include any one or more of the second to third identities in a registration accept message or a registration reject message, where the AMF may indicate that the network supports NTZ by including the second and / or third identities in the registration accept message or the registration reject message.

[0257] Here, when the AMF receives the first identification information or a message including the first identification information from the UE and recognizes that the UE supports NTZ, the AMF may include the second and / or third identification information in a registration accept message or a registration reject message, which is a response message to the registration request message received from the UE, and send the message to the UE. In other words, when the AMF receives the first identification information indicating that the UE supports NTZ from the UE, the AMF may not include the second and / or third identification information in the registration accept message or the registration reject message.

[0258] Conversely, if the AMF does not receive first identification information from the UE indicating that it supports NTZ in a registration request message, or if the AMF receives first identification information from the UE indicating that it does not support NTZ, the AMF may send a registration accept message, which is a response message to the registration request message received from the UE, or the registration accept message to the UE without including the second and / or third identification information.

[0259] Furthermore, when multiple pieces of identification information are transmitted and received, two or more of these pieces of identification information may be configured as one or more pieces of identification information. Note that the information indicating support for each function and the information indicating a request for use of the function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

[0260] Furthermore, whether or not to include one or more of the second to third identification information in the registration acceptance message may be selected or determined based on each identification information received by the AMF from the UE or each device, and / or subscriber information, and / or network capability information, and / or operator policy, and / or network status, and / or user registration information, and / or context held by the AMF, etc.

[0261] Furthermore, the AMF can include and transmit an SM message in a registration accept message, or can transmit an SM message together with the registration accept message. However, this transmission method may be performed when the SM message is included in the registration request message and the fourth condition determination is true. Also, this transmission method may be performed when the SM message is included together with the registration request message and the fourth condition determination is true. By performing such a transmission method, the AMF can indicate that the procedure for SM has been accepted in the registration procedure. Here, the SM message may be a PDU session establishment request message or a PDU session establishment accept message.

[0262] The AMF may also indicate that the UE's request has been accepted by sending a registration acceptance message based on the received identification information, and / or subscription information, and / or network capability information, and / or operator policy, and / or network status, and / or user registration information, and / or context held by the AMF, etc.

[0263] Furthermore, the AMF may include information indicating that some of the UE's requests have been rejected in the registration acceptance message and send it, or may indicate the reason why some of the UE's requests have been rejected by sending the information indicating that some of the UE's requests have been rejected. Furthermore, the UE may recognize the reason why some of the UE's requests have been rejected by receiving the information indicating that some of the UE's requests have been rejected. Note that the reason for the rejection may be information indicating that the content indicated by the identification information received by the AMF is not permitted.

[0264] The UE receives a registration acceptance message from the AMF via the 5G AN (gNB) (S608). By receiving the registration acceptance message, the UE can recognize that the UE's request via the registration request message has been accepted and the contents of various identification information included in the registration acceptance message.

[0265] Here, a UE that receives a registration accept message from the AMF may recognize and store the information indicated by any one or more of the received second and third identification information. That is, the UE may recognize and store that the network supports NTZ by receiving the second and / or third identification information. Also, for example, if the UE has stored NTZ information and receives new NTZ information as the third identification information, the UE may replace the stored NTZ information with the newly received NTZ information.

[0266] Furthermore, the UE may send a registration completion message to the AMF via the 5G AN (gNB) as a response message to the registration acceptance message (S610). Here, the registration completion message is an NAS message transmitted and received on the N1 interface, but is included in an RRC message and transmitted and received between the UE and the 5G AN (gNB).

[0267] The AMF receives a registration completion message via the 5G AN (gNB) (S610). In addition, each device completes the procedure of (A) in FIG. 6 based on the transmission and reception of the registration acceptance message and / or the registration completion message.

[0268] Next, a case where the first condition determination is false will be described. In the procedure of (B) of Fig. 6, the AMF transmits a registration reject message to the UE via the 5G AN (gNB) as a response message to the registration request message (S612). Here, the registration reject message is an NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the 5G AN (gNB) as an RRC message.

[0269] Furthermore, the AMF may indicate that the UE's request via the registration request message has been rejected by sending a registration rejection message. Furthermore, the AMF may include information indicating the reason for the rejection in the registration rejection message and send it, or may indicate the reason for the rejection by sending the reason for the rejection. Furthermore, the UE may recognize the reason for the rejection of the UE's request by receiving information indicating the reason for the rejection of the UE's request. Note that the reason for the rejection may be information indicating that the content indicated by the identification information received by the AMF is not permitted.

[0270] The UE receives a registration rejection message from the AMF via the 5G AN (gNB) (S612). By receiving the registration rejection message, the UE can recognize that the UE's request via the registration request message has been rejected and the contents of the various identification information included in the registration rejection message. Furthermore, if the UE does not receive a registration rejection message even after a predetermined period has elapsed since sending the registration request message, the UE may recognize that the UE's request has been rejected. Each device completes the procedure (B) in this procedure based on the transmission and reception of the registration rejection message.

[0271] The procedure in FIG. 6(B) may be started when the procedure in FIG. 6(A) is stopped.

[0272] Each device completes the registration procedure based on the completion of the procedure of (A) or (B) in Figure 6. Note that each device may transition to a state in which the UE is registered in the network (RM-REGISTERED state) based on the completion of the procedure of (A) in Figure 6, or may maintain a state in which the UE is not registered in the network (RM-DEREGISTERED state) or transition to a state in which the UE is not registered in the network based on the completion of the procedure of (B) in Figure 6. Furthermore, the transition of each device to each state may be based on the completion of the registration procedure or the establishment of a PDU session.

[0273] The UE may also complete the registration procedure based on receiving a registration accept message or a registration reject message.

[0274] Furthermore, each device may perform processing based on the information transmitted and received during the registration procedure based on the completion of the registration procedure. For example, if the device transmits or receives information indicating that some of the UE's requests have been rejected, the device may recognize the reason why the UE's requests have been rejected. Furthermore, each device may perform this procedure again based on the reason why the UE's requests have been rejected, or may perform the registration procedure for the core network_B or another cell.

[0275] Furthermore, the UE may store the identification information received with the registration accept message and / or the registration reject message and may recognize the network's decision based on the completion of the registration procedure.

[0276] The UE may recognize the content of the above identification information by receiving a registration acceptance message or a registration rejection message.

[0277] The behavior to be performed when each piece of identification information is received may be performed based on the received identification information.

[0278] An example of an MM procedure that takes NTZ into account is given in Chapter 5.

[0279] 4.3. Session Management Procedures The Session Management (SM) procedure will be explained with reference to FIG.

[0280] Here, the SM procedure may include a PDU Session Establishment procedure, a PDU Session Modification procedure, a PDU Session Release procedure, or a PDU session authentication and authorization procedure.

[0281] These session management procedures may include procedures initiated by a UE request (UE-requested) and procedures initiated by a network request (NW-requested). In this specification, a procedure initiated by a network request is also referred to as a network initiated (NW-init) procedure, and a procedure initiated by a UE request is also referred to as a UE initiated (UE-init) procedure.

[0282] More specifically, for example, the PDU session establishment procedure may include only a UE-requested procedure, for example, the PDU session modification procedure or the PDU session release procedure may include both a UE-requested procedure and a NW-requested procedure, and for example, the PDU session authentication and authorization procedure may include only a NW-requested procedure.

[0283] Additionally, the first identification information may be included in an initial message that initiates the UW-initiated SM procedure and sent to the network, or the network may receive a message from the UE that includes the first identification information.

[0284] Here, when the network receives first identification information from the UE indicating that the UE supports NTZ, the network may recognize that the UE supports NTZ, and based on this recognition, may include the second and / or third identification information in a response message to the request message received from the UE and send it to the UE.

[0285] Conversely, if the network does not receive the first identification information from the UE or receives the first identification information from the UE indicating that the UE does not support NTZ, the network may recognize that the UE does not support NTZ, and based on this recognition, may send to the UE a response message to the request message received from the UE without including the second and / or third identification information. In other words, if the network does not receive the first identification information from the UE or receives the first identification information indicating that the UE does not support NTZ, the network may send to the UE a response message to the request message received from the UE without including the second and / or third identification information.

[0286] Here, in a UE-initiated SM procedure, the first message including the first identification information that the UE sends to the network may be a PDU session establishment request message in a PDU session establishment procedure, or a PDU session modification request (PDU Session Modification Request) message in a PDU session modification procedure, or a PDU session release request message in a PDU session release procedure.

[0287] Furthermore, in a UE-initiated SM procedure, the response message including the second and / or third identification information may be a PDU session establishment acceptance message or a PDU session establishment rejection message in a PDU session establishment procedure, or a PDU session modification acceptance message or a PDU session modification rejection message in a PDU session modification procedure, or a PDU session release acceptance message or a DU session release rejection message in a PDU session release procedure.

[0288] The NW may also include the second and / or third identification information in an initial message initiating a NW-initiated MM procedure and send it to the UE, or the UE may receive a message from the NW including the second and / or third identification information. Furthermore, a UE that supports NTZ and receives the second and / or third identification information from the NW may recognize that the NW supports NTZ and may store the third identification information if it is included.

[0289] Here, in a NW-initiated SM procedure, the first message including the second and / or third identification information that the NW sends to the UE may be a PDU Session Release Command message in a PDU session release procedure, or a PDU Session Modification Command message in a PDU session modification procedure.

[0290] In addition, when the NW transmits the second and / or third identification information to the UE in the NW-initiated SM procedure, the NW may recognize that the UE supports NTZ from another procedure, the UE's subscription information, etc. In other words, for example, when the NW or the SMF recognizes that the UE supports NTZ, the NW or the SMF may transmit a message including the second and / or third identification information to the UE.

[0291] In addition, the UE-requested PDU session change procedure or the UE-requested PDU session release procedure may be initiated by the UE sending a request message, and the respective procedure may then be executed or completed by executing the network-requested PDU session change procedure or the network-requested PDU session release procedure, or by sending a response message (e.g., a rejection message) from the NW to the UE, as will be described in more detail below.

[0292] Next, each of the above-mentioned session management procedures will be explained.

[0293] The process (A) in the session management procedure shown in Fig. 7 may be a process that is executed only in the UE-requested PDU session change procedure and the UE-requested PDU session release procedure. In other words, in the PDU session establishment procedure or the PDU session authentication and authorization procedure, the process (A) in the session management procedure shown in Fig. 7 does not need to be executed, and only the transmission of a session management request message from the UE to the SMF (S700) and the transmission of a response message to the session management request message from the SMF to the UE (S706) may be executed.

[0294] Furthermore, in the network-requested PDU session modification procedure and the network-requested PDU session release procedure, only the process (A) in the session management procedure (hereinafter also simply referred to as the process (A)) may be executed. In other words, in the network-requested PDU session modification procedure and the network-requested PDU session release procedure, only the transmission of a command message from the SMF to the UE (S702) and the transmission of a response message to the command message from the UE to the SMF (S704) may be executed. In other words, the process (A) in the session management procedure may be the network-requested PDU session modification procedure or the network-requested PDU session release procedure.

[0295] Next, each step of the session management procedure will be explained.

[0296] First, the UE sends a session management request message to the core network (S700). Here, the UE may include first identification information in the SM request message. More specifically, the UE sends the session management request message (also referred to as an SM request message) to the SMF via the gNB ((R)AN) and the AMF. In addition, the UE may send the session management request message to the network to start a UE-requested session management procedure.

[0297] Here, the session management request message may be, for example, a PDU session establishment request message in a UE-requested PDU session establishment procedure, a PDU session modification request message in a UE-requested PDU session modification procedure, a PDU session release request message in a UE-requested PDU session release procedure, or a 5GSM status message in a 5GSM status procedure. Note that, for example, in a network-requested PDU session modification procedure, a network-requested PDU session release procedure, or a PDU session authentication and authorization procedure, transmission of a session management request message from the UE to the SMF may not be performed.

[0298] Next, the SMF that receives the session management request message from the UE may perform the process of (A) or may transmit a response message to the session management request to the UE (S706). Here, the NW or the SMF may include the second and / or third identification information in the response message and transmit it to the UE.

[0299] Next, the process (A) during the session management procedure will be described. In the process (A), the SMF sends a command message to the UE via the AMF and the gNB. More specifically, the command message may be, for example, a PDU session modification command message, a PDU session release command message, or a PDU session authentication command message in the PDU session authentication and authorization procedure.

[0300] Subsequently, the UE that has received the command message from the SMF via the AMF and the gNB (S702) may transmit a response message to the command message to the network (S706). More specifically, the response message to the command message may be, for example, a PDU session modification complete message or a PDU session modification command reject message in a PDU session modification procedure, a PDU session release complete message in a PDU session release procedure, or a PDU session authentication complete message in a PDU session authentication and authorization procedure.

[0301] Here, the network-requested PDU session change procedure and the network-requested PDU session change procedure complete or terminate the session management procedure upon receiving a response message corresponding to the command from the UE, and there is no need to perform the subsequent procedures described in Figure 7.

[0302] Alternatively, when responding to a session management request message received from the UE, or when rejecting each procedure or a response from the UE in each procedure without performing the process of (A), the SMF transmits a response message to the session management request message (also referred to as an SM response message) to the UE (S706). More specifically, for example, in a PDU session establishment procedure, when the SMF receives a PDU session establishment request message from the UE (S700), it may transmit a PDU session establishment accept message or a PDU session establishment reject message to the UE (S706). Note that in the PDU session establishment procedure, it is not necessary to perform the process of (A).

[0303] Also, for example, in a PDU session modification procedure or a PDU session release procedure, if the SMF rejects a PDU session modification request message or a PDU session release request message (S702) received from the UE, it may send a PDU session modification rejection message or a PDU session release rejection message to the UE (S706). Here, the NW may include the second and / or third identification information in each rejection message and send it to the UE.

[0304] Here, a PDU session establishment procedure will be described in more detail as a specific example of a session management procedure. The UE may start the PDU session procedure by sending a PDU session establishment request message including second and / or third identification information to the network as a session management request message (S700). More specifically, the UE may send the PDU session establishment request message to the SMF via the gNB ((R)AN) and the AMF.

[0305] Next, the network includes the second and / or third identification information in a response message to the session management request message received from the UE and transmits the response message to the UE (S706). More specifically, the SMF may transmit a PDU session establishment accept message or a PDU session establishment reject message to the UE as a response message to the PDU session request message received from the UE, or may transmit these messages by including the second and / or third identification information in the messages. When the UE receives the PDU session establishment accept message or the PDU session establishment reject message transmitted by the SMF via the AMF and the gNB((R)AN), the UE and each device may terminate the PDU session establishment procedure.

[0306] The above describes a specific example of a PDU session establishment procedure as a specific example of a session management procedure, but other SM procedures may also operate in accordance with the explanation in this chapter, and each message sent and received in the procedure of this embodiment may be replaced with the message name of each other SM procedure.

[0307] An example of an SM procedure that takes NTZ into account is given in Chapter 5.

[0308] 5. Embodiment Next, each embodiment of this example will be described. Note that each embodiment described in this chapter may be implemented based on the definitions of terms and various identification information explained in Chapter 3, and the procedures explained in Chapter 4.

[0309] Furthermore, the UE, UAV, access network, or core network of each embodiment described in this chapter may be an embodiment executed after completing any one or more of the procedures in Chapter 4.

[0310] Furthermore, the UE in each embodiment described in this chapter may be a normal UE, a UAV, an aerial UE, a UAV-C (Unmanned Aerial Vehicle-Controller; UAV-Controller), or an AAM (Area Airspace Manager). In other words, when referred to as a UE in this chapter, it may be a normal UE, a UAV, an aerial UE, a UAV-C, or an AAM. Furthermore, the UAV, aerial UE, or UE in each embodiment in this chapter will also be simply referred to as a UAV.

[0311] Furthermore, the UE, UAV, access network, or core network of each embodiment described in this chapter may have completed one or more of the procedures in Chapter 4, and the UE may have received and stored third identification information from the access network and / or core network. That is, unless otherwise specified, the UAV, aerial UE, or UE of each embodiment described in this chapter may start in a state in which the third identification information is stored. Here, unless otherwise specified, the procedures performed or completed by the UAV, aerial UE, UE, access network, or core network of each embodiment described in this chapter may be the procedures in Chapter 4.2 and / or Chapter 4.3.

[0312] Furthermore, unless otherwise specified, the embodiments in this example are not limited to being implemented individually and independently as each embodiment described in each section of this chapter, but may be implemented as a combination of one or more embodiments described in each section, or one or more embodiments described in each section may be implemented in any order or combination.

[0313] More specifically, for example, a UAV that supports NTZ may be able to perform any of the first to third embodiments in combination with the fourth or fifth embodiment when initiating or executing a mobility management procedure or a session management procedure.

[0314] Furthermore, the transmission and reception of the first to third identification information between the UE or UAV and the network (access network or core network) does not have to be limited to the same procedure. More specifically, for example, the UE may transmit the first identification information to the network in the MM procedure, and the UE may receive broadcast information or an RRC message including the third identification information from the gNB, but this is not limited to this.

[0315] Furthermore, when the UAV of the first to fifth embodiments leaves the NTZ, it may receive information indicating that it has left the NTZ or third identification information indicating that it has left the NTZ through each procedure or message transmission / reception in Chapter 4, and the UAV may recognize that it has left the NTZ.

[0316] In addition, the UAV in each embodiment can be read as aerial UE or UE.

[0317] Each embodiment of the examples will be described below.

[0318] 5.1. First embodiment A first embodiment of this example will be described. Hereinafter, in this section, the first embodiment will also be referred to as this embodiment.

[0319] The UAV, or aerial UE, or UE (also simply referred to as UAV) of this embodiment transmits capability information indicating that it supports NTZ (No-Transmit Zone) to the network during the transmission and reception of any of the procedures or messages described in Chapter 4, and receives NTZ information from the network during the transmission and reception of any of the procedures or messages described in Chapter 4.

[0320] More specifically, for example, in a registration procedure, the UAV of this embodiment may first transmit a registration request message to the network including first identification information indicating that the UAV supports NTZ. Here, the registration procedure may be an initial registration procedure or a registration procedure for mobility and periodic registration update. Furthermore, the first identification information may be included in a 5GMM capability IE included in the registration request message.

[0321] Subsequently, the UAV of this embodiment may receive, for example, a registration accept message, a UE configuration update command message, a DL NAS transport message, or a notification message including the third identification information as NTZ information from the network. Here, for example, the registration accept message including the third identification information may be a response message to a registration request message including the first identification information sent by the UE to the network. Also, the UE configuration update command message, the DL NAS transport message, or the notification message including the third identification information may be sent in a procedure manually performed by the network based on the network's decision.

[0322] Furthermore, a UE that receives a message including third identification information as NTZ information may store the third identification information, or may recognize the information indicated by the third identification information.

[0323] Here, the third identification information is NTZ information, and as described in Chapter 3.2, may include the frequency bands subject to regulation within the NTZ, and / or the cell IDs subject to regulation in the NTZ, and / or the geographical location areas subject to regulation in the NTZ, and / or the TAs (Tracking Areas) or information indicating the TAs subject to regulation in the NTZ, and / or the Registration Areas (RAs) subject to regulation in the NTZ.

[0324] Furthermore, if a UAV that supports NTZ that has received the third identification information changes its registration area while within the NTZ or moving within the NTZ, the UAV may not initiate or perform a registration procedure for mobility registration update, or may be restricted or prohibited from initiating or performing a registration procedure for mobility registration update.

[0325] In other words, if a UAV that supports NTZ detects or recognizes that its registration area has changed, and if it is within the NTZ, the UAV may not initiate or perform, or may be prohibited from initiating or performing, registration procedures for mobility and periodic registration updates.

[0326] Here, the detection or recognition by the UAV that the registration area has changed may be the UAV detecting or recognizing that the UAV's current TAI is not within the list of tracking areas previously or last registered with the AMF.

[0327] [5.2. Second embodiment] A second embodiment of this example will be described. In this section, the second embodiment will also be referred to as this embodiment.

[0328] The UAV, or aerial UE, or UE (also simply referred to as UAV) of this embodiment transmits capability information indicating that it supports NTZ (No-Transmit Zone) to the network during the transmission and reception of any of the procedures or messages described in Chapter 4, and receives NTZ information from the network during the transmission and reception of any of the procedures or messages described in Chapter 4.

[0329] More specifically, for example, in a registration procedure, the UAV of this embodiment may first transmit a registration request message to the network including first identification information indicating that the UAV supports NTZ. Here, the registration procedure may be an initial registration procedure or a registration procedure for mobility and periodic registration update. Furthermore, the first identification information may be included in a 5GMM capability IE included in the registration request message.

[0330] Subsequently, the UAV of this embodiment may receive, for example, a registration accept message, a UE configuration update command message, a DL NAS transport message, or a notification message including the third identification information as NTZ information from the network. Here, for example, the registration accept message including the third identification information may be a response message to a registration request message including the first identification information sent by the UE to the network. Also, the UE configuration update command message, the DL NAS transport message, or the notification message including the third identification information may be sent in a procedure manually performed by the network based on the network's decision.

[0331] Furthermore, a UE that receives a message including third identification information as NTZ information may store the third identification information, or may recognize the information indicated by the third identification information.

[0332] Here, the third identification information is NTZ information, and as described in Chapter 3.2, may include the frequency bands subject to regulation within the NTZ, and / or the cell IDs subject to regulation in the NTZ, and / or the geographical location areas subject to regulation in the NTZ, and / or the TAs (Tracking Areas) or information indicating the TAs subject to regulation in the NTZ, and / or the Registration Areas (RAs) subject to regulation in the NTZ.

[0333] Furthermore, if a UAV that supports the NTZ that has received the third identification information has a timer for periodic registration updates expire while it is within the NTZ or moving within the NTZ, the UAV may not initiate or perform a registration procedure for periodic registration updates, or may be restricted or prohibited from initiating or performing a registration procedure for periodic registration updates.

[0334] In other words, if a UAV that supports NTZ has a timer for periodic registration updates running within the UAV that expires and the UAV is within the NTZ, the UAV may not initiate or perform the registration procedure for periodic registration updates, or may be prohibited from initiating or performing the registration procedure.

[0335] Here, the timer for periodic registration update running in the UAV may be, for example, timer T3512, or may be another mobility management timer other than timer T3512. Furthermore, the UE running timer T3512 may be in 5GMM-IDLE mode, or may not be registered for emergency services.

[0336] [5.3. Third embodiment] A third embodiment of this example will be described. In this section, the third embodiment will also be referred to as this embodiment.

[0337] The UAV, or aerial UE, or UE (also simply referred to as UAV) of this embodiment transmits capability information indicating that it supports NTZ (No-Transmit Zone) to the network during the transmission and reception of any of the procedures or messages described in Chapter 4, and receives NTZ information from the network during the transmission and reception of any of the procedures or messages described in Chapter 4.

[0338] More specifically, for example, in a registration procedure, the UAV of this embodiment may first transmit a registration request message to the network including first identification information indicating that the UAV supports NTZ. Here, the registration procedure may be an initial registration procedure or a registration procedure for mobility and periodic registration update. Furthermore, the first identification information may be included in a 5GMM capability IE included in the registration request message.

[0339] Subsequently, the UAV of this embodiment may receive, for example, a registration accept message, a UE configuration update command message, a DL NAS transport message, or a notification message including the third identification information as NTZ information from the network. Here, for example, the registration accept message including the third identification information may be a response message to a registration request message including the first identification information sent by the UE to the network. Also, the UE configuration update command message, the DL NAS transport message, or the notification message including the third identification information may be sent in a procedure manually performed by the network based on the network's decision.

[0340] Furthermore, a UE that receives a message including third identification information as NTZ information may store the third identification information, or may recognize the information indicated by the third identification information.

[0341] Here, the third identification information is NTZ information, and as described in Chapter 3.2, may include the frequency bands subject to regulation within the NTZ, and / or the cell IDs subject to regulation in the NTZ, and / or the geographical location areas subject to regulation in the NTZ, and / or the TAs (Tracking Areas) or information indicating the TAs subject to regulation in the NTZ, and / or the Registration Areas (RAs) subject to regulation in the NTZ.

[0342] Furthermore, a UAV that supports the NTZ that receives the third identification information may not initiate or perform mobility management procedures and session management procedures within the NTZ or while moving within the NTZ, or may be restricted or prohibited from initiating or performing mobility management procedures and session management procedures.

[0343] Here, for example, when a UAV that supports NTZ is within the NTZ, it may be possible to initiate or execute a mobility management procedure for emergency services and / or a session management procedure for emergency services. In other words, for example, when a UAV that supports NTZ is within the NTZ, it may not be necessary to initiate or execute a mobility management procedure for emergency services and / or a session management procedure other than a session management procedure for emergency services, or the initiation or execution of such procedures may be restricted or prohibited. In other words, for example, when a UAV that supports NTZ is within the NTZ, it may execute a mobility management procedure for emergency services and / or a session management procedure for emergency services, but it may not be necessary to initiate or execute a mobility management procedure and / or a session management procedure other than a session management procedure for emergency services, or the initiation or execution of such procedures may be restricted or prohibited.

[0344] Or, for example, when a UAV supporting NTZ is within an NTZ, it may not initiate or perform mobility management procedures for emergency services and / or session management procedures for emergency services, or the initiation or execution of such procedures may be restricted or prohibited. In other words, when a UAV supporting NTZ is within an NTZ, it may not initiate or perform mobility management procedures and / or session management procedures including mobility management procedures for emergency services and / or session management procedures for emergency services, or the initiation or execution of such procedures may be restricted or prohibited.

[0345] [5.4. Fourth embodiment] A fourth embodiment of this example will be described. In this section, the fourth embodiment will also be referred to as this embodiment.

[0346] A UAV that supports the NTZ of this embodiment may be a UAV that can request a slice associated with an NTZ or store an NTZ and a slice in association with each other.

[0347] More specifically, for example, the UAV of this embodiment may be able to recognize a request for PDU session establishment to an S-NSSAI that considers or supports NTZ, and / or an acceptance of PDU session establishment to an S-NSSAI that considers or supports NTZ.

[0348] In addition, here, if a UAV requests one or more specific S-NSSAIs when establishing a PDU session, it may include the one or more S-NSSAIs in the requested NSSAI in the PDU session establishment request message and send it to the network, and the one or more S-NSSAIs may be one or more S-NSSAIs that support NTZ.

[0349] Alternatively, the UAV may select one or more S-NSSAIs that support NTZ from one or more S-NSSAIs that support NTZ included in the configured NSSAI pre-configured in the UAV, or from one or more S-NSSAIs included in the configured NSSAI, include them in the requested NSSAI in the PDU session establishment message, and send them to the network.

[0350] The network may also send one or more allowed S-NSSAIs to the UAV by including the allowed one or more S-NSSAIs in the allowed NSSAI in the PDU session establishment accept message, and the allowed one or more S-NSSAIs may be one or more allowed S-NSSAIs that support NTZ.

[0351] Furthermore, even if the requested NSSAI in the PDU session establishment request message received from the UAV does not include an S-NSSAI that supports NTZ, or even if the requested NSSAI is not included in the PDU session establishment request message, the network may decide to include one or more S-NSSAIs that support NTZ in the allowed NSSAI in the PDU session establishment accept message and send it to the UAV.

[0352] The S-NSSAI may be configured taking into consideration whether or not the UAV or the network supports NTZ. More specifically, for example, an S-NSSAI that takes NTZ into consideration or an S-NSSAI that does not take NTZ into consideration may be configured.

[0353] [5.5. Fifth embodiment] A fifth embodiment of this example will be described. In this section, the fifth embodiment will also be referred to as the present embodiment.

[0354] This embodiment may be an embodiment in which, during the registration procedure, the UAV includes first identification information indicating that it does not support NTZ in the registration request message, or does not include the first identification information in the registration request message.

[0355] When a network receives a registration request message from a UAV that includes first identification information indicating that the UAV does not support NTZ, or a registration request message that does not include the first identification information, the network may recognize or determine that the UAV does not support NTZ. Note that the network's recognition or determination that the UAV does not support NTZ is not limited to this.

[0356] A network that recognizes or determines that a UAV does not support NTZ may send a registration rejection message to the UAV including a rejection reason value indicating that the rejection is due to the UAV not supporting NTZ.

[0357] A UAV that receives a registration request message that includes a rejection reason value indicating that the rejection is due to the UAV not supporting NTZ may recognize the contents of the reason value.

[0358] Here, the rejection reason value in the registration rejection message indicating that the rejection is due to the UAV not supporting NTZ may be information included in the 5GMM cause information element. Also, the rejection reason value in the registration rejection message indicating that the rejection is due to the UAV not supporting NTZ may be a reason value indicating that the UAV needs to support NTZ.

[0359] Furthermore, the UAV of this embodiment may further include one or more of "A2X over E-UTRA-PC5 (A2XEPC5)," "A2X over NR-PC5 (A2XNPC5)," or "A2X over Uu capability (A2X-Uu)" in the 5GMM capability information element, which is capability information included in the registration request message. [6. Modification] The program that runs on the device according to one aspect of this embodiment may be a program that controls a central processing unit (CPU) or the like to cause a computer to function so as to realize the functions of the embodiment according to one aspect of this embodiment. The program or information handled by the program is temporarily stored in a volatile memory such as a random access memory (RAM), a non-volatile memory such as a flash memory, a hard disk drive (HDD), or another storage device system.

[0360] A program for realizing the functions of an embodiment according to one aspect of this example may be recorded on a computer-readable recording medium. The program may be read into a computer system and executed. The term "computer system" as used herein refers to a computer system built into a device, including hardware such as an operating system and peripheral devices. The term "computer-readable recording medium" may refer to a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a medium that dynamically stores a program for a short period of time, or any other computer-readable recording medium.

[0361] Additionally, each functional block or feature of the device used in the above-described embodiments may be implemented or performed by an electrical circuit, such as an integrated circuit or multiple integrated circuits. The electrical circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or a conventional processor, controller, microcontroller, or state machine. The electrical circuit may be composed of digital circuits or analog circuits. Furthermore, as advances in semiconductor technology emerge, one or more aspects of the present embodiments may utilize new integrated circuit technologies that replace current integrated circuits.

[0362] It should be noted that this example is not limited to the above-described embodiment. In the embodiment, one example of a device is described, but this example is not limited to this and can be applied to stationary or non-movable electronic devices installed indoors or outdoors, such as terminal devices or communication devices for AV equipment, kitchen equipment, cleaning / washing equipment, air conditioning equipment, office equipment, vending machines, and other household appliances.

[0363] Although the embodiment of this example has been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment, and design modifications within the scope of this example are also included. Furthermore, various modifications of this example are possible within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of this example. Furthermore, configurations in which elements described in each of the above embodiments are substituted with elements that achieve the same effect are also included. [Explanation of symbols]

[0364] 1. Mobile communication systems 10 UE_A 30 PGW-U 32 PGW-C 35 SGW 40 MME 45 eNB 50 HSS 60 PCRF 80 Access Network_A (E-UTRAN) 90 Core Network_A 120 Access Network_B (5G AN) 122 gNB 130 UPF 132 SMF 140 AMF 150 UDM 160 PCF 190 Core Network_B 235 UPF_A 239 UPF_C

Claims

1. A UAV (Uncrewed Aerial Vehicle) equipped with a transceiver unit and a control unit, The transmitting / receiving unit Transmitting capability information to the network indicating that it supports NTZ (No-Transmit Zone); receiving NTZ information from the network; The control unit does not start a mobility registration update procedure when a registration area is changed within the NTZ. A UAV characterized by:

2. A UAV (Uncrewed Aerial Vehicle) equipped with a transceiver unit and a control unit, The transmitting / receiving unit Transmitting capability information to the network indicating that it supports NTZ (No-Transmit Zone); receiving NTZ information from the network; The control unit does not initiate a registration update procedure when a periodic registration update timer expires within the NTZ. A UAV characterized by:

3. The NTZ information includes a frequency band subject to regulation in the NTZ, and / or a cell ID subject to regulation in the NTZ, and / or a geographic location area subject to regulation in the NTZ, and / or a Tracking Area (TA) subject to regulation in the NTZ, and / or a Registration Area (RA) subject to regulation in the NTZ, 2. The UAV of claim 1 .

4. A UAV (Uncrewed Aerial Vehicle) equipped with a transceiver unit and a control unit, The transmitting / receiving unit Transmitting capability information to the network indicating that it supports NTZ (No-Transmit Zone); receiving NTZ information from the network; The control unit does not initiate a mobility management procedure and a session management procedure when the UAV is within the NTZ; A UAV characterized by:

5. The control unit initiates a management procedure for emergency services and a session management procedure for emergency services when the UAV is within the NTZ.

5. The UAV according to claim 4.

Images