Network slicing

Abstract

One disclosure of the specification provides a method. The method can include receiving a message including information related to a requested NSSAI; and transmitting a registration request message including the requested NSSAI.

Description

Technical Field

[0001] This disclosure relates to mobile communications. Background Technology

[0002] The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is a technology for achieving high-speed packet communication. Many proposals have been put forward for LTE goals, including those aimed at reducing user and vendor costs, improving service quality, and expanding and increasing coverage and system capacity. 3GPP LTE requires lower cost per bit, increased service availability, flexible use of frequency bands, a simple architecture, open interfaces, and appropriate power consumption in terminals as upper-layer requirements.

[0003] Work has begun within the International Telecommunication Union (ITU) and 3GPP to develop requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components necessary for the successful standardization of the new RAT, meeting both pressing market demands and the longer-term requirements outlined in the ITU Radiocommunication Sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. Furthermore, NR should be able to utilize any frequency band within at least the 100 GHz range, and these bands should be available for wireless communication even in the more distant future.

[0004] The goal of NR is to address all use cases, requirements, and deployment scenarios with a single technology framework, including enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable and low-latency communications (URLLC). NR should inherently be backward compatible.

[0005] Communication based on network slices is being discussed. However, according to existing technology, there is a problem that it may not be able to effectively support communication based on various types of network slices (such as allowed NSSAI, partially allowed NSSAI, and on-demand NSSAI). Summary of the Invention

[0006] Technical solution

[0007] According to embodiments of this disclosure, a method is provided. The method may include: receiving a message including information related to On-Demand NSSAI; and sending a registration request message for NSSAI including the request.

[0008] According to an embodiment, an apparatus for implementing the method is provided. Attached Figure Description

[0009] Figure 1 An example of a communication system that applies the implementation of this disclosure is shown.

[0010] Figure 2An example of a wireless device that applies an implementation of the present disclosure is shown.

[0011] Figure 3 An example of a UE that applies the implementation of this disclosure is shown.

[0012] Figure 4 An example of a 5G system architecture applying the implementation of this disclosure is shown.

[0013] Figure 5 and Figure 6 An example of a registration process applying the implementation of this disclosure is shown.

[0014] Figure 7 This is an example of the process by which a UE obtains URSP information.

[0015] Figure 8 A first example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0016] Figure 9 A second example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0017] Figure 10 A third example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0018] Figure 11 This is an example of a registration process based on an implementation method disclosed in this specification.

[0019] Figure 12 Examples of operation of embodiments based on the disclosure of this specification are shown. Detailed Implementation

[0020] The following technologies, devices, and systems can be applied to a variety of wireless multiple access systems. Examples of multiple access systems include Code Division Multiple Access (CDMA) systems, Frequency Division Multiple Access (FDMA) systems, Time Division Multiple Access (TDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single-Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Multi-Carrier Frequency Division Multiple Access (MC-FDMA) systems. CDMA can be implemented using radio technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented using radio technologies such as Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data Rate GSM Evolution (EDGE). OFDMA can be implemented using radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is part of the Evolved UMTS (E-UMTS) using E-UTRA. 3GPP LTE employs OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). The evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and / or 5G New Radio (NR).

[0021] For ease of description, the implementation of this disclosure is primarily described with respect to 3GPP-based wireless communication systems. However, the technical features of this disclosure are not limited thereto. For example, although the following detailed description is based on mobile communication systems corresponding to 3GPP-based wireless communication systems, the aspects of this disclosure that are not limited to 3GPP-based wireless communication systems are applicable to other mobile communication systems.

[0022] For any terms and techniques used in this disclosure that are not specifically described in this disclosure, please refer to wireless communication standards documents published prior to this disclosure.

[0023] In this disclosure, "A or B" can mean "A only", "B only", or "both A and B". In other words, "A or B" in this disclosure can be interpreted as "A and / or B". For example, "A, B or C" in this disclosure can mean "A only", "B only", "C only", or "any combination of A, B and C".

[0024] In this disclosure, a forward slash ( / ) or a comma (,) can mean "and / or". For example, "A / B" can mean "A and / or B". Therefore, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

[0025] In this disclosure, "at least one of A and B" can mean "only A", "only B" or "both A and B". Furthermore, the expressions "at least one of A or B" or "at least one of A and / or B" in this disclosure can be interpreted as the same as "at least one of A and B".

[0026] Additionally, in this disclosure, "at least one of A, B, and C" may mean "only A," "only B," "only C," or "any combination of A, B, and C." Furthermore, "at least one of A, B, or C" or "at least one of A, B, and / or C" may mean "at least one of A, B, and C."

[0027] Furthermore, the brackets used in this disclosure may mean "for example". Specifically, when it is shown as "Control Information (PDCCH)", "PDCCH" can be cited as an example of "Control Information". In other words, "Control Information" in this disclosure is not limited to "PDCCH", and "PDCCH" can be cited as an example of "Control Information". In addition, even when shown as "Control Information (i.e., PDCCH)", "PDCCH" can be cited as an example of "Control Information".

[0028] The technical features described individually in one of the accompanying drawings of this disclosure can be implemented individually or simultaneously.

[0029] Although not limited thereto, the various descriptions, functions, processes, suggestions, methods and / or operation flowcharts disclosed herein can be applied to various fields requiring wireless communication and / or connectivity between devices (e.g., 5G).

[0030] In the following description, this disclosure will be described in more detail with reference to the accompanying drawings. Unless otherwise stated, the same reference numerals in the following drawings and / or description may refer to the same and / or corresponding hardware blocks, software blocks and / or functional blocks.

[0031] Figure 1 An example of a communication system that applies the implementation of this disclosure is shown.

[0032] Figure 1 The 5G use cases shown are merely illustrative, and the technical features of this disclosure can be applied to... Figure 1 Other 5G use cases not shown.

[0033] The three main requirement categories for 5G include (1) Enhanced Mobile Broadband (eMBB), (2) Massive Machine Type Communications (mMTC), and (3) Ultra Reliable and Low Latency Communications (URLLC).

[0034] Reference Figure 1The communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200, and a network 300. Although Figure 1 An example of a 5G network as a network of communication system 1 is shown, but the implementation of this disclosure is not limited to 5G systems and can be applied to future communication systems other than 5G systems.

[0035] BS 200 and network 300 can be implemented as wireless devices, and a particular wireless device can operate as a BS / network node relative to other wireless devices.

[0036] Wireless devices 100a to 100f represent devices that perform communication using radio access technology (RAT) (e.g., 5G New RAT (NR) or LTE) and may be referred to as communication / radio / 5G devices. Wireless devices 100a to 100f may include (but are not limited to) robots 100a, vehicles 100b-1 and 100b-2, extended reality (XR) devices 100c, handheld devices 100d, home appliances 100e, IoT devices 100f, and artificial intelligence (AI) devices / servers 400. For example, vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of performing communication between vehicles. Vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR / VR / mixed reality (MR) devices and may be implemented in the form of head-mounted displays (HMDs), head-up displays (HUDs) installed in vehicles, televisions, smartphones, computers, wearable devices, home appliance devices, digital signage, vehicles, robots, etc. Handheld devices may include smartphones, smart tablets, wearable devices (e.g., smartwatches or smart glasses), and computers (e.g., laptops). Home appliances may include TVs, refrigerators, and washing machines. IoT devices may include sensors and smart meters.

[0037] In this disclosure, wireless devices 100a to 100f may be referred to as user equipment (UE). UE may include, for example, cellular phones, smartphones, laptops, digital broadcasting terminals, personal digital assistants (PDAs), portable multimedia players (PMPs), navigation systems, tablet PCs, tablet PCs, ultrabooks, vehicles, vehicles with autonomous driving capabilities, connected cars, UAVs, AI modules, robots, AR devices, VR devices, MR devices, holographic devices, public safety devices, MTC devices, IoT devices, medical devices, fintech devices (or financial devices), security devices, weather / environment devices, devices related to 5G services, or devices related to the Fourth Industrial Revolution.

[0038] Wireless devices 100a to 100f can connect to network 300 via BS 200. AI technology can be applied to wireless devices 100a to 100f, and wireless devices 100a to 100f can connect to AI server 400 via network 300. Network 300 can be configured using 3G, 4G (e.g., LTE), 5G (e.g., NR), and super 5G networks. Although wireless devices 100a to 100f can communicate with each other via BS 200 / network 300, wireless devices 100a to 100f can also perform direct communication (e.g., sidelink communication) without going through BS 200 / network 300. For example, vehicles 100b-1 and 100b-2 can perform direct communication (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). IoT devices (e.g., sensors) can perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

[0039] Wireless communication / connections 150a, 150b, and 150c can be established between wireless devices 100a to 100f and / or between wireless devices 100a to 100f and BS 200 and / or between BS 200. In this document, wireless communication / connections can be established via various RATs (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication (or device-to-device (D2D) communication) 150b, and inter-base station communication 150c (e.g., relay, integrated access and backhaul (IAB)). Wireless devices 100a to 100f and BS 200 / wireless devices 100a to 100f can send / receive radio signals to / from each other via wireless communication / connections 150a, 150b, and 150c. For example, wireless communication / connections 150a, 150b, and 150c can send / receive signals via various physical channels. Therefore, at least a portion of various configuration information configuration processes, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, and resource mapping / demapping), and resource allocation processes for transmitting / receiving radio signals can be performed based on various proposals of this disclosure.

[0040] NR supports multiple parameter sets (and / or multiple subcarrier spacings (SCS)) to support a variety of 5G services. For example, if the SCS is 15kHz, wide-area coverage can be supported in traditional cellular bands, and if the SCS is 30kHz / 60kHz, dense urban areas, lower latency, and wider carrier bandwidth can be supported. If the SCS is 60kHz or higher, bandwidths greater than 24.25GHz can be supported to overcome phase noise.

[0041] NR bands can be defined as two types of frequency ranges, namely FR1 and FR2. The numerical values ​​of the frequency ranges can be changed. For example, the frequency ranges of the two types (FR1 and FR2) can be shown in Table 1 below. For ease of explanation, in the frequency ranges used in NR systems, FR1 can represent "below 6 GHz" and FR2 can represent "above 6 GHz," and can also be referred to as millimeter wave (mmW).

[0042] [Table 1]

[0043] As mentioned above, the frequency range of the NR system can be varied. For example, FR1 can include a frequency band from 410MHz to 7125MHz, as shown in Table 2 below. That is, FR1 can include a frequency band of 6GHz (or 5850MHz, 5900MHz, 5925MHz, etc.) or higher. For example, the 6GHz (or 5850MHz, 5900MHz, 5925MHz, etc.) or higher frequency bands included in FR1 can include unlicensed frequency bands. Unlicensed frequency bands can be used for various purposes, such as for vehicle (e.g., autonomous driving) communications.

[0044] [Table 2]

[0045] Here, the radio communication technologies implemented in the wireless devices of this disclosure may include narrowband IoT (NB-IoT) technologies for low-power communication, as well as LTE, NR, and 6G. For example, NB-IoT technology may be an example of low-power wide-area network (LPWAN) technology, implemented in specifications such as LTE Cat NB1 and / or LTE Cat NB2, and may not be limited to the names mentioned above. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices of this disclosure may communicate based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as enhanced machine-type communication (eMTC). For example, LTE-M technology may be implemented in at least one of various specifications such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-bandwidth limited (non-BL), 5) LTE-MTC, 6) LTE machine-type communication, and / or 7) LTE M, and may not be limited to the names mentioned above. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices of this disclosure may include at least one of ZigBee, Bluetooth, and / or LPWAN, which take into account low-power communication, and may not be limited to the names mentioned above. For example, ZigBee technology may generate personal area networks (PANs) associated with low-power / low-power digital communication based on various specifications such as IEEE 802.15.4, and may be referred to by various names.

[0046] Figure 2 An example of a wireless device that applies an implementation of the present disclosure is shown.

[0047] exist Figure 2 In this context, the first wireless device 100 and / or the second wireless device 200 can be implemented in various forms depending on the use case / service. For example, {the first wireless device 100 and the second wireless device 200} can correspond to... Figure 1 At least one of {wireless devices 100a to 100f and BS 200}, {wireless devices 100a to 100f and wireless devices 100a to 100f} and / or {BS 200 and BS 200}. The first wireless device 100 and / or the second wireless device 200 may be configured from various elements, devices / components and / or modules.

[0048] The first wireless device 100 may include at least one transceiver (e.g., transceiver 106), at least one processing chip (e.g., processing chip 101), and / or one or more antennas 108.

[0049] The processing chip 101 may include at least one processor (e.g., processor 102) and at least one memory (e.g., memory 104). Additionally and / or alternatively, the memory 104 may be located outside the processing chip 101.

[0050] Processor 102 can control memory 104 and / or transceiver 106, and can be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in this disclosure. For example, processor 102 can process information in memory 104 to generate first information / signal, and then transmit a radio signal including the first information / signal via transceiver 106. Processor 102 can receive a radio signal including a second information / signal via transceiver 106, and then store the information obtained by processing the second information / signal in memory 104.

[0051] Memory 104 may be operatively connected to processor 102. Memory 104 may store various types of information and / or instructions. Memory 104 may store firmware and / or software code 105 that implements code, commands, and / or command sets, which, when executed by processor 102, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, firmware and / or software code 105 may implement instructions that, when executed by processor 102, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, firmware and / or software code 105 may control processor 102 to execute one or more protocols. For example, firmware and / or software code 105 may control processor 102 to execute one or more layers of a radio interface protocol.

[0052] In this document, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). Transceiver 106 may be connected to processor 102 and transmit and / or receive radio signals via one or more antennas 108. Each transceiver 106 may include a transmitter and / or a receiver. Transceiver 106 may be used interchangeably with radio frequency (RF) units. In this disclosure, first wireless device 100 may represent a communication modem / circuit / chip.

[0053] The second wireless device 200 may include at least one transceiver (e.g., transceiver 206), at least one processing chip (e.g., processing chip 201), and / or one or more antennas 208.

[0054] The processing chip 201 may include at least one processor (e.g., processor 202) and at least one memory (e.g., memory 204). Additionally and / or alternatively, the memory 204 may be located outside the processing chip 201.

[0055] Processor 202 can control memory 204 and / or transceiver 206, and can be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in this disclosure. For example, processor 202 can process information in memory 204 to generate third information / signal, and then transmit a radio signal including the third information / signal via transceiver 206. Processor 202 can receive a radio signal including a fourth information / signal via transceiver 106, and then store the information obtained by processing the fourth information / signal in memory 204.

[0056] Memory 204 may be operatively connected to processor 202. Memory 204 may store various types of information and / or instructions. Memory 204 may store firmware and / or software code 205 that implements code, commands, and / or command sets, which, when executed by processor 202, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, firmware and / or software code 205 may implement instructions that, when executed by processor 202, execute the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, firmware and / or software code 205 may control processor 202 to execute one or more protocols. For example, firmware and / or software code 205 may control processor 202 to execute one or more layers of a radio interface protocol.

[0057] In this document, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). Transceiver 206 may be connected to processor 202 and transmit and / or receive radio signals via one or more antennas 208. Each transceiver 206 may include a transmitter and / or a receiver. Transceiver 206 may be used interchangeably with an RF unit. In this disclosure, second wireless device 200 may represent a communication modem / circuit / chip.

[0058] The hardware elements of wireless devices 100 and 200 will be described in more detail below. One or more protocol layers can be implemented by (but are not limited to) one or more processors 102 and 202. For example, one or more processors 102 and 202 can implement one or more layers (e.g., functional layers such as the Physical (PHY) layer, Medium Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC) layer, and Service Data Adaptation Protocol (SDAP) layer). One or more processors 102 and 202 can generate one or more Protocol Data Units (PDUs), one or more Service Data Units (SDUs), messages, control information, data, or information in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information, in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure, and provide the generated signals to one or more transceivers 106 and 206. One or more processors 102 and 202 may receive signals (e.g., baseband signals) from one or more transceivers 106 and 206, and acquire PDUs, SDUs, messages, control information, data, or information, in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure.

[0059] One or more processors 102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. As an example, one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field-programmable gate arrays (FPGAs) may be included in one or more processors 102 and 202. For example, one or more processors 102 and 202 may be configured by a set of communication control processors, application processors (APs), electronic control units (ECUs), central processing units (CPUs), graphics processing units (GPUs), and memory control processors. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, codes, instructions, and / or commands. One or more memories 104 and 204 may be configured with random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EPROM), flash memory, volatile memory, non-volatile memory, hard disk drive, registers, buffer memory, computer-readable storage media, and / or combinations thereof. One or more memories 104 and 204 may be located internally and / or externally to one or more processors 102 and 202. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 via various technologies such as wired or wireless connections.

[0060] One or more transceivers 106 and 206 can transmit user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure to one or more other devices. One or more transceivers 106 and 206 can receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure from one or more other devices. For example, one or more transceivers 106 and 206 can be connected to one or more processors 102 and 202 and transmit and receive radio signals. For example, one or more processors 102 and 202 can perform control to enable one or more transceivers 106 and 206 to transmit user data, control information, or radio signals to one or more other devices. One or more processors 102 and 202 can perform control to enable one or more transceivers 106 and 206 to receive user data, control information, or radio signals from one or more other devices.

[0061] One or more transceivers 106 and 206 may be connected to one or more antennas 108 and 208. Additionally and / or alternatively, one or more transceivers 106 and 206 may include one or more antennas 108 and 208. One or more transceivers 106 and 206 may be adapted to transmit and receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein via one or more antennas 108 and 208. In this disclosure, one or more antennas 108 and 208 may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

[0062] One or more transceivers 106 and 206 can convert received user data, control information, radio signals / channels, etc., from RF band signals into baseband signals so that the received user data, control information, radio signals / channels, etc., can be processed by one or more processors 102 and 202. One or more transceivers 106 and 206 can also convert user data, control information, radio signals / channels, etc., processed by one or more processors 102 and 202 from baseband signals into RF band signals. For this purpose, one or more transceivers 106 and 206 may include (analog) oscillators and / or filters. For example, one or more transceivers 106 and 206, under the control of one or more processors 102 and 202, can up-convert OFDM baseband signals to OFDM signals using their (analog) oscillators and / or filters, and transmit the up-converted OFDM signals at the carrier frequency. One or more transceivers 106 and 206 can receive OFDM signals at a carrier frequency and, under the control of one or more processors 102 and 202, downconvert the OFDM signals to OFDM baseband signals via their (analog) oscillators and / or filters.

[0063] although Figure 2 Not shown, but wireless devices 100 and 200 may also include additional components. Additional component 140 may be configured differently depending on the type of wireless devices 100 and 200. For example, additional component 140 may include at least one of a power unit / battery, input / output (I / O) devices (e.g., audio I / O ports, video I / O ports), drive devices, and computing devices. Additional component 140 may be coupled to one or more processors 102 and 202 via various technologies such as wired or wireless connections.

[0064] In the implementation of this disclosure, the UE can operate as a transmitting device in the UL and as a receiving device in the DL. In the implementation of this disclosure, the BS can operate as a receiving device in the UL and as a transmitting device in the DL. Hereinafter, for ease of description, it is primarily assumed that the first wireless device 100 acts as the UE and the second wireless device 200 acts as the BS. For example, a processor 102 connected to, installed on, or started in the first wireless device 100 can be adapted to perform UE operations according to the implementation of this disclosure, or to control the transceiver 106 to perform UE operations according to the implementation of this disclosure. A processor 202 connected to, installed on, or started in the second wireless device 200 can be adapted to perform BS operations according to the implementation of this disclosure, or to control the transceiver 206 to perform BS operations according to the implementation of this disclosure.

[0065] In this disclosure, BS is also referred to as Node B (NB), eNodeB (eNB), or gNB.

[0066] Figure 3 An example of a UE that applies the implementation of this disclosure is shown.

[0067] Reference Figure 3 UE 100 can correspond to Figure 2 The first wireless device 100.

[0068] The UE 100 includes a processor 102, a memory 104, a transceiver 106, one or more antennas 108, a power management module 141, a battery 142, a display 143, a keyboard 144, a subscriber identification module (SIM) card 145, a speaker 146, and a microphone 147.

[0069] Processor 102 may be adapted to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. Processor 102 may be adapted to control one or more other components of UE 100 to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. A layer of the radio interface protocol may be implemented in processor 102. Processor 102 may include an ASIC, other chipsets, logic circuits, and / or data processing devices. Processor 102 may be an application processor. Processor 102 may include at least one of a DSP, CPU, GPU, and modem (modulator and demodulator). Examples of processor 102 may be found in the SNAPDRAGON™ series processors manufactured by Qualcomm®, the EXYNOS™ series processors manufactured by Samsung®, the A-series processors manufactured by Apple®, the HELIO™ series processors manufactured by MediaTek®, the ATOM™ series processors manufactured by Intel®, or corresponding next-generation processors.

[0070] Memory 104 is operatively coupled to processor 102 and stores various information for operating processor 102. Memory 104 may include ROM, RAM, flash memory, memory card, storage medium, and / or other storage devices. When the implementation is software-based, the techniques described herein can be implemented using modules (e.g., processes, functions, etc.) that perform the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. Modules may be stored in memory 104 and executed by processor 102. Memory 104 may be implemented within or outside processor 102, in which case those memories may be communicatively coupled to processor 102 via various means known in the art.

[0071] Transceiver 106 is operatively coupled to processor 102 and transmits and / or receives radio signals. Transceiver 106 includes a transmitter and a receiver. Transceiver 106 may include baseband circuitry for processing radio frequency signals. Transceiver 106 controls one or more antennas 108 to transmit and / or receive radio signals.

[0072] The power management module 141 manages the power of the processor 102 and / or transceiver 106. The battery 142 supplies power to the power management module 141.

[0073] Display 143 outputs the results processed by processor 102. Keyboard 144 receives input that will be used by processor 102. Keyboard 144 can be displayed on display 143.

[0074] The SIM 145 is an integrated circuit designed to securely store the International Mobile Subscriber Identity (IMSI) number and its associated keys. The IMSI number and its associated keys are used to identify and authenticate subscribers on mobile devices such as mobile phones and computers. It can also store contact information associated with many SIM cards.

[0075] Speaker 146 outputs sound-related results processed by processor 102. Microphone 147 receives sound-related input to be used by processor 102.

[0076] Figure 4 An example of a 5G system architecture applying the implementation of this disclosure is shown.

[0077] The 5G system (5GS) architecture includes the following network functions (NFs).

[0078] - Authentication Server Function (AUSF)

[0079] - Access and Mobility Management Function (AMF)

[0080] - Data networks (DN), such as carrier services, internet access, or third-party services.

[0081] - Unstructured Data Storage Function (UDSF)

[0082] - Network Exposure Function (NEF)

[0083] - Intermediate NEF (I-NEF)

[0084] - Network Repository Function (NRF)

[0085] - Network Slice Selection Function (NSSF)

[0086] - Policy Control Function (PCF)

[0087] - Session Management Function (SMF)

[0088] - Unified Data Management (UDM)

[0089] - Unified Data Repository (UDR)

[0090] - User Plane Function (UPF)

[0091] - UE Radio Capability Management Function (UCMF)

[0092] - Application Functionality (AF)

[0093] - User Equipment (UE)

[0094] - (Radio) Access Network ((R)AN)

[0095] - 5G-Device Identifier Register (5G-EIR)

[0096] - Network Data Analysis Function (NWDAF)

[0097] - Billing Function (CHF)

[0098] In addition, the following network functions can be considered.

[0099] - Non-3GPP Interoperability Function (N3IWF)

[0100] - Trusted Non-3GPP Gateway Function (TNGF)

[0101] - Wired Access Gateway Function (W-AGF)

[0102] Figure 4 The architecture of a 5G system in a non-roaming scenario is depicted, using reference point representations to show how various network functions interact with each other.

[0103] exist Figure 4 For clarity of the point-to-point graph, UDSF, NEF, and NRF are not depicted. However, all depicted network functions can interact with UDSF, UDR, NEF, and NRF as needed.

[0104] For clarity, Figure 4 The document does not depict the UDR or its connections to other NFs (e.g., PCFs). For clarity, Figure 4 The NWDAF and its connections with other NFs (e.g., PCF) are not described.

[0105] The 5G system architecture includes the following reference points: - N1: Reference point between UE and AMF.

[0106] - N2: Reference point between (R)AN and AMF.

[0107] - N3: Reference point between (R)AN and UPF.

[0108] - N4: Reference point between SMF and UPF.

[0109] - N6: Reference point between UPF and data network.

[0110] - N9: Reference point between the two UPFs.

[0111] The reference points below illustrate the interactions that exist between NF services in NF.

[0112] - N5: Reference point between PCF and AF.

[0113] - N7: Reference point between SMF and PCF.

[0114] - N8: Reference point between UDM and AMF.

[0115] - N10: Reference point between UDM and SMF.

[0116] - N11: Reference point between AMF and SMF.

[0117] - N12: Reference point between AMF and AUSF.

[0118] - N13: Reference point between UDM and AUSF.

[0119] - N14: Reference point between the two AMFs.

[0120] - N15: Reference point between PCF and AMF in non-roaming scenarios, and reference point between PCF and AMF in the surveyed network in roaming scenarios.

[0121] - N16: A reference point between two SMFs (between an SMF in the visited network and an SMF in the home network in a roaming situation).

[0122] - N22: Reference point between AMF and NSSF.

[0123] In some cases, several NFs may need to be associated with each other to serve the UE.

[0124] A registration process is described. See section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0125] Figure 5 and Figure 6 An example of a registration process applying the implementation of this disclosure is shown.

[0126] The UE needs to register with the network to obtain authorization to receive services, thereby enabling mobility tracking and reachability. The UE initiates the registration process using one of the following registration types: - Initial registration with 5GS; or - Mobility registration update; or - Periodic registration and updates; or - Urgent registration.

[0127] Figure 5 and Figure 6The general registration process applies to all of these registration processes, but periodic registration updates do not need to include all the parameters used in other registration cases.

[0128] Figure 5 and Figure 6 The general registration process is also used when a UE is already registered in a non-3GPP access scenario and then registers in a 3GPP access scenario, and vice versa. When a UE is already registered in a non-3GPP access scenario, the registration in the 3GPP access scenario may require an AMF change.

[0129] First, description Figure 5 The process.

[0130] (1) Step 1: The UE sends a registration request message to the (R)AN. The registration request message corresponds to the AN message.

[0131] The registration request message may include AN parameters. In the case of NG-RAN, AN parameters include, for example, the 5G SAE Temporary Mobile Subscriber Identifier (5G-S-TMSI) or Globally Unique AMF ID (GUAMI), the selected Public Land Mobile Network (PLMN) ID (or PLMN ID and Network Identifier (NID)), and the requested Network Slice Selection Auxiliary Information (NSSAI). AN parameters also include the establishment reason. The establishment reason provides the reason for requesting to establish an RRC connection. Whether and how the UE includes the requested NSSAI as part of the AN parameters depends on the value of the Access Stratum Connection Establishment NSSAI Include Mode parameter.

[0132] The registration request message may include a registration type. The registration type indicates whether the UE wants to perform an initial registration (i.e., the UE is in the RM-DEREGISTERED state), a mobility registration update (i.e., the UE is in the RM-REGISTERED state and initiates the registration process due to mobility issues or because the UE needs to update its capabilities or protocol parameters or requests a change in the set of network slices it is allowed to use), a periodic registration update (i.e., the UE is in the RM-REGISTERED state and initiates the registration process because the periodic registration update timer has expired), or an emergency registration (i.e., the UE is in a restricted service state).

[0133] When a UE is performing initial registration, the UE should indicate its UE identity in the registration request message, listed in a preferred descending order: i) If the UE has a valid EPS GUTI, then the 5G globally unique temporary identifier (5G-GUTI) mapped from the Evolved Packet System (EPS) GUTI.

[0134] ii) The UE attempts to assign a local 5G-GUTI to the PLMN it is registered with, if available; iii) The local 5G-GUTI assigned by the equivalent PLMN to the PLMN to which the UE attempts to register, if available; iv) Local 5G-GUTI assigned by any other PLMN, if available.

[0135] v) Otherwise, the UE should include its Subscriber Hidden Identifier (SUCI) in the registration request message.

[0136] When a UE performing initial registration has both a valid EPS GUTI and a local 5G-GUTI, the UE should also indicate the local 5G-GUTI as an additional GUTI. If more than one local 5G-GUTI is available, the UE should select the 5G-GUTI in descending order of preference from items (ii) to (iv) in the list above.

[0137] When a UE performs initial registration using its local 5G-GUTI, the UE should indicate the relevant GUAMI information in the AN parameters. When a UE performs initial registration using its SUCI, the UE should not indicate any GUAMI information in the AN parameters.

[0138] For emergency registration, if the UE does not have a valid 5G-GUTI available, the SUCI should be included; when the UE does not have a Subscriber Permanent Identifier (SUPI) and does not have a valid 5G-GUTI, the Permanent Device Identifier (PEI) should be included. In other cases, the 5G-GUTI should be included, and it should indicate the last serving AMF.

[0139] The registration request message may also include security parameters, PDU session status, etc. Security parameters are used for authentication and integrity protection. PDU session status indicates the previously established PDU sessions in the UE. When the UE is connected to two AMFs belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status indicates the established PDU sessions in the current PLMN of the UE.

[0140] (2) Step 2: (R)AN selects AMF.

[0141] If 5G-S-TMSI or GUAMI is not included, or if 5G-S-TMSI or GUAMI does not indicate a valid AMF, then (R)AN selects the AMF based on (R)AT and the requested NSSAI (if available).

[0142] If the UE is in CM-CONNECTED state, the (R)AN can forward the registration request message to the AMF based on the UE's N2 connection.

[0143] If (R)AN cannot select an appropriate AMF, it will forward the registration request message to the AMF in (R)AN that has been configured to perform AMF selection.

[0144] (3) Step 3: (R)AN sends a registration request message to the new AMF. The registration request message corresponds to the N2 message.

[0145] The registration request message may include all and / or a portion of the information included in the registration request message received from the UE as described in step 1.

[0146] The registration request message may include N2 parameters. When using NG-RAN, the N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell identifier related to the cell where the UE is camped, and a UE context request indicating that a UE context including security information needs to be established at NG-RAN. When using NG-RAN, the N2 parameters should also include the reason for establishment.

[0147] If the registration type indicated by the UE is periodic registration update, steps 4 to 19 can be omitted.

[0148] (4) Step 4: If the UE’s 5G-GUTI is included in the registration request message and the service AMF has changed since the last registration process, the new AMF can call the Namf_Communication_UEContextTransfer service operation against the old AMF by including the full registration request non-access stratum (NAS) message to request the UE’s SUPI and UE context.

[0149] (5) Step 5: The old AMF can respond to the new AMF by including the UE's SUPI and UE context in response to the Namf_Communication_UEContextTransfer call.

[0150] (6) Step 6: If the UE neither provides SUCI nor retrieves SUCI from the old AMF, it can initiate the identity request process by sending an identity request message to the UE requesting SUCI through the new AMF.

[0151] (7) Step 7: The UE can respond with an identity response message that includes the SUCI. The UE derives the SUCI by using the provisioning public key of the home PLMN (HPLMN).

[0152] (8) Step 8: The new AMF can decide to initiate UE authentication by calling AUSF. In this case, the new AMF selects AUSF based on SUPI or SUCI.

[0153] (9) Step 9: Authentication / security can be established by UE, new AMF, AUSF and / or UDM.

[0154] (10) Step 10: If the AMF has changed, the new AMF can notify the old AMF of the UE's registration completion in the new AMF by calling the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication / security process fails, registration will be rejected, and the new AMF can call the Namf_Communication_RegistrationCompleteNotify service operation with the rejection indication reason code against the old AMF. The old AMF can continue as if it had never received the UE context delivery service operation.

[0155] (11) Step 11: If the UE has neither provided a PEI nor retrieved a PEI from the old AMF, the identity request process can be initiated by sending an identity request message to the UE through the new AMF to retrieve the PEI. The PEI should be transmitted encrypted unless the UE performs emergency registration and cannot be authenticated.

[0156] (12) Step 12: Optionally, the new AMF can initiate an ME identity check by calling the N5g-eir_EquipmentIdentityCheck_Get service operation.

[0157] Now, the description is in Figure 5 After the process Figure 6 The process.

[0158] (13) Step 13: If you want to perform step 14 below, the new AMF can select UDM based on SUPI, and then UDM can select UDR instance.

[0159] (14) Step 14: The new AMF can register with the UDM.

[0160] (15) Step 15: The new AMF can select PCF.

[0161] (16) Step 16: The new AMF can optionally perform AM policy association establishment / modification.

[0162] (17) Step 17: The new AMF can send an update / release SM context message to the SMF (e.g., Nsmf_PDUSession_UpdateSMContext and / or Nsmf_PDUSession_ReleaseSMContext).

[0163] (18) Step 18: If the new AMF and the old AMF are in the same PLMN, the new AMF can send a UE context modification request to N3IWF / TNGF / W-AGF.

[0164] (19) Step 19: N3IWF / TNGF / W-AGF can send a UE context modification response to the new AMF.

[0165] (20) Step 20: After the new AMF receives the response message from N3IWF / TNGF / W-AGF in step 19, the new AMF can register with UDM.

[0166] (21) Step 21: The new AMF sends a registration acceptance message to the UE.

[0167] The new AMF sends a registration acceptance message to the UE indicating that the registration request has been accepted. If the new AMF assigns a new 5G-GUTI, this 5G-GUTI is included. If the UE is already in RM-REGISTERED state via another access within the same PLMN, the UE should use the 5G-GUTI received in the registration acceptance message for both registrations. If the registration acceptance message does not include a 5G-GUTI, the UE will also use the 5G-GUTI assigned to the existing registration for the new registration. If the new AMF assigns a new registration area, it will send that registration area to the UE via the registration acceptance message. If the registration acceptance message does not include a registration area, the UE will consider the old registration area valid. Mobility restrictions are included if they apply to the UE and the registration type is not emergency registration. The new AMF indicates established PDU sessions to the UE in the PDU session state. The UE locally removes any internal resources associated with PDU sessions not marked as established in the received PDU session state. When a UE connects to two AMFs belonging to different PLMNs via 3GPP access and non-3GPP access, the UE locally removes any internal resources associated with the current PLMN that are not marked as established in the received PDU session state. If the PDU session state information is in the registration request message, the new AMF will indicate the PDU session state to the UE.

[0168] The allowed NSSAIs (either fully allowed or partially allowed) provided in the registration acceptance message are valid within the registered region, and this applies to all PLMNs whose tracking regions are included in the registered region. The mapping of allowed NSSAIs (partially allowed NSSAIs) can be each S-NSSAI that maps HPLMN S-NSSAIs to allowed NSSAIs. The mapping of configured NSSAIs (configured NSSAIs) can be each S-NSSAI that maps HPLMN S-NSSAIs to configured NSSAIs used to serve the PLMN.

[0169] In addition, optionally, the new AMF performs UE policy association establishment.

[0170] (22) Step 22: The UE can send a registration completion message to the new AMF when it has successfully updated itself.

[0171] The UE can send a registration completion message to the new AMF to confirm whether a new 5G-GUTI has been assigned.

[0172] (23) Step 23: For registration via 3GPP access, if the new AMF has not released the signaling connection, the new AMF can send RRC inactivation assistance information to the NG-RAN. For registration via non-3GPP access, if the UE is also in CM-CONNECTED state on 3GPP access, the new AMF can send RRC inactivation assistance information to the NG-RAN.

[0173] (24) Step 24: The new AMF can perform information updates against the UDM.

[0174] (25) Step 25: The UE can perform the Network Slice Specific Authentication and Authorization (NSSAA) process.

[0175] Communication based on network slices is being discussed. However, according to existing technologies, there are issues that may not be effective in supporting communication based on various types of network slices, such as Allowed Network Slice Selection Auxiliary Information (NSSAI), Partially Allowed NSSAI, and On-Demand NSSAI.

[0176] For example, when service transmission is required, in order to check whether an existing PDU session can be used or whether a new PDU session connection is needed for service transmission, the NAS layer of the terminal (e.g., UE) can exchange information with the upper layer of the terminal (e.g., URSP layer). At this time, the URSP (UE Routing Policy) layer can utilize the stored service descriptor and routing descriptor information.

[0177] According to existing technology, the URSP layer of a terminal can check network slice information. For example, the URSP layer of the terminal can send the corresponding S-NSSAI information to the NAS layer only if a single NSSAI (S-NSSAI) matching the service to be transmitted exists in the routing descriptor and the S-NSSAI exists in the allowed NSSAIs.

[0178] On the other hand, although information for managing other types of network slices, such as partially permitted NSSAI and on-demand NSSAI, has been defined, the existing technology does not take into account various types of information such as partially permitted NSSAI and on-demand NSSAI.

[0179] Since the operation between the URSP layer and the NAS layer according to the existing technology cannot define the accurate URSP-based operation, this needs to be improved.

[0180] For reference, the following may be consulted for prior art not described in the disclosure of this specification: TS 24.501 V18.5.0 (e.g., 5.5.1.2.2 Initial Registration Initiation, 5.5.1.3.2 Mobility and Periodic Registration Update Initiation, 6.2.9 Interaction with Upper Layers, 6.4.1 UE-Requested PDU Session Establishment Procedure Initiation). TS24.526 V18.5.0 (e.g., 4.2.2.2 Association between Application and PDU Session, Non-Seamless Non-3GPP Offload by UE or 5G ProSe Layer 3 UE-to-Network Relay Offload).

[0181] To establish a PDU session or request network slice registration, the UE can attempt to find a valid network slice within the route descriptor (RSD) specified in the UE Routing Policy (URSP). According to TS 24.526 V18.5.0, the UE's URSP layer can indicate the valid S-NSSAI when the valid S-NSSAI within the RSD is within the allowed NSSAI stored in the UE.

[0182] For example, the following operations can be performed. For operations not described below, please refer to TS 24.526 V18.5.0S4.2.2.2: 1) The UE selects a route descriptor with the next lowest priority value that has not yet been evaluated; 2) If: vi) If the selected routing descriptor does not include a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, then the UE's URSP processing layer requests the UE NAS layer to establish a PDU session that provides the following PDU session attributes based on the selected routing descriptor: A) SSC mode, if SSC mode exists in the route selection descriptor; B) An S-NSSAI if the S-NSSAI is in the routing descriptor and is within the allowed NSSAIs. Additionally, if the UE supports LADNs per DNN and S-NSSAI, the request is for a PDU session for the LADN, extended LADN information is available for that LADN, and the S-NSSAI is associated with that LADN in its service area; then, an S-NSSAI is included. If none of the S-NSSAIs in the routing descriptor are included in the allowed NSSAIs, the UE proceeds to step II) 4). At the same time, a new set of network slices called On-Demand NSSAI has been defined. UEs can use On-Demand NSSAI, and the network can register on-demand network slices only when generating user services.

[0183] To this end, firstly, the network (e.g., AMF) can send an on-demand S-NSSAI list to the UE. For example, based on the registration process, UE configuration update process, etc., such as sending rejected / accepted NSSAIs, the network (e.g., AMF) can send an on-demand S-NSSAI list to the UE. For example, the network (e.g., AMF) can send a registration acceptance message or a UE configuration update command message to the UE that includes the on-demand S-NSSAI list. Since the network slice is not registered, the network (e.g., AMF) does not include the on-demand S-NSSAI in the allowed NSSAIs, and the network (e.g., AMF) includes the on-demand S-NSSAI in the on-demand NSSAI. Subsequently, when the UE needs to transmit user services, the UE can request slice registration during the mobility registration update process. Then, when the requested on-demand S-NSSAI is successfully registered, and the allowed NSSAI including the on-demand S-NSSAI is delivered to the UE, the UE can use the S-NSSAI (e.g., the on-demand S-NSSAI) to initiate a PDU session establishment request. For example, the UE can send a PDU session establishment request message that includes the S-NSSAI (e.g., on-demand S-NSSAI).

[0184] In the case of on-demand slice registration, the NAS layer can request all S-NSSAIs stored in the on-demand NSSAI. However, in this case, the S-NSSAI requested by the UE may not be allowed to be used, depending on the UE policy. Therefore, it has been discussed that when all S-NSSAIs in the RSD are not in the (partially) allowed NSSAIs, the UE should attempt to include the S-NSSAI in the RSD to add it to the (partially) allowed NSSAIs through the Mobility Registration Update (MRU) procedure.

[0185] A URSP rule's routing descriptor is considered valid only if all of the following conditions are met: 1) If any S-NSSAI exists, for non-roaming, the S-NSSAI is in the allowed NSSAI or (partially) allowed NSSAI, and for roaming, the S-NSSAI is in the mapping from allowed NSSAI (or (partially) allowed NSSAI) to HPLMNS-NSSAI. (If any S-NSSAI exists, it is in the allowed NSSAI or (partially) allowed NSSAI in the non-roaming case, and in the mapping from allowed NSSAI (or (partially) allowed NSSAI) to HPLMNS-NSSAI in the roaming case.) During the verification of the route descriptor, the condition in 1) may not be met for any of the S-NSSAIs of the RSD. In this case, the UE may attempt to satisfy the condition by requesting the addition of the S-NSSAI of the RSD to the allowed NSSAIs (or (partially) allowed NSSAIs) through the mobility registration update procedure as specified in Section 5.15.5.2.2 of TS 23.501 V18.4.0.

[0186] A UE may attempt a mobility registration update for S-NSSAI only if the S-NSSAI is in the configured NSSAI, or for roaming, in the mapping of the S-NSSAI to the corresponding S-NSSAI value for the HPLMN in the configured NSSAI for the VPLMN, and if there are any other restrictions as defined in TS 24.501 V18.5.0 that prevent triggering a mobility registration update. (The UE will only attempt a mobility registration update for an S-NSSAI if the S-NSSAI is in the configured NSSAI, or in roaming cases, in the mapping of the S-NSSAI to the corresponding S-NSSAI value for the HPLMN in the configured NSSAI used for the VPLMN, and if any other restrictions as defined in TS 24.501 V18.5.0 exist to prevent triggering a mobility registration update.) For example, to determine the S-NSSAI for a PDU session, i) when the UE finds a matching HPLMN S-NSSAI in the URSP rules, the UE can perform a mobility registration update (MRU) procedure by sending a registration request message that includes that S-NSSAI. ii) when the UE does not find a matching HPLMN S-NSSAI in the URSP rules, the UE can perform a mobility registration update procedure by sending a registration request message that includes the HPLMN S-NSSAI from the configured NSSAI. iii) When no HPLMN S-NSSAI is found in either the URSP rules or the configured NSSAI, the UE can send a PDU session establishment request message that does not include S-NSSAI information without triggering the MRU procedure.

[0187] In order to properly support operations such as those in the examples above when considering on-demand NSSAI, several issues need to be clarified.

[0188] First, it is unclear whether the network configuration of the URSP for the UE guarantees that all on-demand S-NSSAIs are listed in all RSDs of the URSP. If this is not guaranteed, then when the UE requests one of the S-NSSAIs in the RSD, it cannot be guaranteed that the UE is requesting an on-demand S-NSSAI used for registration.

[0189] Therefore, secondly, when it is necessary to check whether the S-NSSAI of the RSD is in the on-demand NSSAI, it is necessary to determine whether it is the NAS layer, the URSP layer, or one of these two layers that checks whether the S-NSSAI of the RSD is in the on-demand NSSAI.

[0190] For reference, the UE can receive URSP information as shown in the following example.

[0191] The UE can receive messages that include URSP information.

[0192] For example, the network (e.g., PCF) can send a NAS message including URSP information to the UE via the AMF. This NAS message can be a DL NAS TRANSPORT message.

[0193] For example, a network can be based on, such as Figure 7 The example message delivers URSP information to the terminal. Regarding... Figure 7 For an example, see Appendix D of TS 24.501 V18.5.0.

[0194] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0195] Figure 7 This is an example of the process by which a UE obtains URSP information.

[0196] Figure 7 This could be an example of a UE policy management process requested by the network. According to... Figure 7 For example, the PCF can send a MANAGE UE POLICY COMMAND message to the UE. The PCF can send this message and start a timer (e.g., a T3501 timer).

[0197] The UE can send a MANAGE UE POLICY COMPLETE message or a MANAGE UE POLICY COMMAND REJECT message to the PCF. In this case, the PCF can stop the timer (e.g., the T3501 timer).

[0198] For example, according to Figure 7 Example messages can be delivered to the UE via the NAS transport procedure. For instance, when the PCF sends a MANAGE UE POLICY COMMAND message to the AMF, the AMF can send a NAS message to the UE that piggybacks the MANAGE UE POLICY COMMAND message. The payload container type of this NAS message can be set to "UE Policy Container".

[0199] For information on NAS transfer processes, please refer to TS 24.501 V18.5.0 S4.1 and S5.4.5.3.

[0200] For example, according to TS 24.501 V18.5.0 S4.1, an example of NAS is as follows.

[0201] The Non-Access Layer (NAS) described in this disclosure forms the top layer of the control plane between the UE and the AMF for both 3GPP access and non-3GPP access.

[0202] The main functions of the protocol, which is part of NAS, are as follows: a) Support UE mobility, including general processes such as authentication, identification, general UE configuration updates, and security mode control processes; b) Supports session management procedures for establishing and maintaining data connections between the UE and the data network; and c) NAS transmission procedures used to provide the transmission of payloads for SMS, LPP, SLPP, LCS, UPP-CMI containers, UE policy containers, SOR transparent containers, and UE parameter update information. Here, URSP information may be included in the UE policy container.

[0203] For example, the NAS transfer process according to TS 24.501 V18.5.0 S5.4.5.3 is shown below.

[0204] The purpose of a network-initiated NAS transfer process is to provide the transfer of the following: a) A single 5GSM message; b) SMS; c) LPP message; c1) SLPP message; d) SOR transparent container; e) A single uplink 5GSM message that was not delivered due to routing failure; f) A single uplink 5GSM message that was not delivered due to congestion control; g) UE policy container; h) A single uplink 5GSM message that was not forwarded due to reaching the maximum number of PDU sessions in the PLMN; h1) A single uplink 5GSM message that was not forwarded because the maximum number of PDU sessions with active user plane resources was reached; h2) A single uplink 5GSM message that was not forwarded because a network slice-specific authentication and authorization process for the requested S-NSSAI was in progress; h3) A single uplink 5GSM message that was not delivered because the UE requested to establish an MA PDU session for the LADN DNN; For example, a "UE policy container" can be included in a payload container IE. The UE policy container of the payload container IE can be processed in the UE policy delivery process specified in Appendix D of 3GPP TS 24.501 V18.5.0.

[0205] The UE may include a NAS layer and a URSP layer (or a URSP processing layer). These two layers may be physically separate and / or logically separate within the UE. For example, the UE's processor may perform operations associated with each of the NAS layer and the URSP layer.

[0206] The NAS layer of the UE can perform interactions with the URSP layer of the UE. For example, the NAS layer of the UE can perform operations based on URSP rules.

[0207] For example, refer to the description related to session management in TS 24.501 V18.5.0 S4.6.3.

[0208] To activate PDU transmission within a network slice, when no suitable PDU session for PDU transmission is established within the network slice, the UE may request the establishment of a PDU session for the data network (DN) associated with the S-NSSAI and the data network name (DNN). The S-NSSAI included as part of the permitted NSSAI of the serving PLMN or SNPN is a valid S-NSSAI value in the serving PLMN or SNPN, and in roaming scenarios, the mapped S-NSSAI is also included for the PDU session if available. See section 6.4.1 of TS 24.501 V18.5.0 for details. As described in section 4.2.2 of 3GPP TS 24.526 V18.5.0, the UE may determine whether to establish a new PDU session or use one of the existing PDU sessions based on URSP rules that include the S-NSSAI (if present) or based on the UE's local configuration.

[0209] Refer to TS 24.501 V18.5.0 S6.2.9 for an example of interaction with the upper layer.

[0210] 5GSM entities interact with upper layers. Section 6.2.9.2 of TS 24.501 V18.5.0 describes how 5GSM entities interact with upper layers regarding URSP. Section 6.2.9.3 of TS 24.501 V18.5.0 describes how 5GSM entities interact with upper layers regarding ProSeP.

[0211] URSP requires interaction between upper layers (e.g., the application layer) and 5GSM entities. Refer to 3GPP TS 24.526V18.5.0. Each 5GSM entity within the UE can indicate the attributes of a newly established PDU session to the upper layer (e.g., PDU session ID, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address). When a PDU session is released, the 5GSM entity handling that PDU session can notify the upper layer of the released PDU session ID. The upper layer can request the 5GSM entity to: a) Request the establishment of a PDU session that indicates one or more PDU session attributes; b) Request the release of the existing PDU session; or c) Request the creation of a PDU session that indicates one or more PDU session attributes and release the existing PDU session.

[0212] Refer to TS 24.501 V18.5.0 6.4.1.2 for an example of a UE requesting the initiation of a PDU session establishment process.

[0213] When a UE requests to establish a new non-urgent PDU session via DN, the UE may include the PDU session type IE in the PDU session establishment request message. Based on the URSP rules, the UE's local configuration, and / or the IP version capabilities specified in Section 6.2.4.2 of TS 24.501 V18.5.0, the UE may set the PDU session type IE to one of the following values: "IPv4", "IPv6", "IPv4v6", "Unstructured", or "Ethernet".

[0214] UE can send: a) PDU session establishment request message; b) The PDU session ID of a PDU session that is being established, being handed over, being transferred, or has been established as an MA PDU session; c) If the request type is set as follows, the UE can send the request type: 1) If the UE determines to establish a new PDU session or MA PDU session based on URSP rules that include one or more S-NSSAIs in the URSP or the UE's local configuration, the UE can send an "Initial Request" or an "MA PDU Request": i) If the UE is in an HPLMN or a subscribed SNPN, then the S-NSSAI corresponding to one of the allowed NSSAIs of the matching URSP rules (if any), or the S-NSSAI corresponding to the S-NSSAI configured locally by the UE, or the S-NSSAI corresponding to one of the allowed NSSAIs of the default URSP rules, as given in Clause 4.2.2 of 3GPP TS 24.526 V18.5.0.

[0215] ii) If the UE is in a non-subscribed SNPN, the UE determines to establish a new PDU session or MA PDU session based on the conditions presented in Clause 4.2.2 of 3GPP TS 24.526 V18.5.0, according to URSP rules including one or more S-NSSAIs. These URSP rules may be part of the URSP signaled by the non-subscribed SNPN.

[0216] Based on various examples disclosed in this specification, various examples are proposed to implement mechanisms for processing network slice information in NSSAI during the Mobility Registration Update (MRU) process for network slice registration.

[0217] For reference, traditionally, the URSP layer has an interface with a 5GSM entity. However, according to the embodiments disclosed in this specification, the URSP layer may have interfaces with both a 5GMM entity and a 5GSM.

[0218] According to the first example (for example, refer to...) Figure 8 (As a first example of terminal operation), the URSP layer can check on-demand NSSAI to perform network slice verification in the routing descriptor (RSD).

[0219] According to the second example (for example, refer to...) Figure 9 (A second example of terminal operation) Even if S-NSSAI is not included in the (partially) permitted NSSAIs, the URSP layer can indicate S-NSSAI in the RSD, and the NAS layer can determine whether to request on-demand S-NSSAI or requested configured NSSAI network slices.

[0220] Third example (for example, refer to) Figure 10 (A third example of terminal operation) allows the URSP layer to instruct S-NSSAI in the RSD when the UE supports a specific function.

[0221] Reference Figure 8This describes a first example of terminal operation. For example, the URSP layer can inspect on-demand NSSAI. This first example of terminal operation may affect the operation of the URSP layer.

[0222] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0223] Figure 8 A first example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0224] Figure 8 The operations performed in the UE can be executed by the UE's URSP layer (or URSP processing layer).

[0225] In step S801, the UE can determine the service descriptor.

[0226] For example, a URSP rule can include a service descriptor and a list of multiple routing descriptors (RSDs).

[0227] For example, in step S801, the UE can find a service descriptor that matches the application information within a non-default URSP rule. The UE can evaluate URSP rules that include service descriptors that match the application information.

[0228] In step S802, the UE can check the RSD.

[0229] For example, the UE can sequentially check the RSD list, which includes URSP rules that match application information. For example, the UE can check the RSDs based on their priority and determine the S-NSSAI within the RSDs.

[0230] In step S803, the UE can determine whether the S-NSSAI in the RSD is among the (partially) allowed NSSAIs.

[0231] In step S804, the UE can determine whether S-NSSAI in RSD is in on-demand NSSAI.

[0232] For reference, Figure 8 In the example, steps S803 and S804 are illustrated as separate operations, but this is only an example. For instance, without going through two steps, the UE can determine whether the S-NSSAI in the RSD is in (partially) permitted NSSAI or on-demand NSSAI.

[0233] For reference, in step S804, when the S-NSSAI in the RSD is not in the on-demand NSSAI, the following operations can be performed. For example, to determine the S-NSSAI for the PDU session, i) when the UE finds an S-NSSAI in the URSP rules that matches an S-NSSAI existing in the partial (allowed) NSSAI or on-demand NSSAI, the UE can perform a mobility registration update procedure by sending a registration request message including that S-NSSAI. ii) when the UE does not find an S-NSSAI in the URSP rules that matches an S-NSSAI existing in the partial (allowed) NSSAI or on-demand NSSAI, the UE can perform a mobility registration update procedure by sending a registration request message including the HPLMN S-NSSAI in the configured NSSAI. iii) When no S-NSSAI matching the S-NSSAI present in the partial (allowed) NSSAI or on-demand NSSAI is found in the URSP rules, or when no HPLMN S-NSSAI is found in the configured NSSAI, the UE may send a PDU session establishment request message that does not include S-NSSAI information without triggering the MRU procedure.

[0234] In step S805, the UE may indicate S-NSSAI to the NAS layer. For example, the UE's URSP layer may indicate S-NSSAI to the NAS layer. For reference, the term "indicates" in the disclosure of this specification may mean "indicate". Additionally, "indicate" may also be used to mean providing, delivering, sending, or notifying.

[0235] Reference Figure 9 This is a second example describing terminal operation.

[0236] For example, when an RSD exists for a business descriptor, the URSP layer can indicate the S-NSSAI in the RSD.

[0237] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0238] Figure 9 A second example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0239] In step S901, the UE can determine the service descriptor.

[0240] In step S902, the UE can check the RSD.

[0241] In step S903, the UE can determine whether S-NSSAI is in the RSD.

[0242] In step S904, the UE can indicate a failure. For example, the UE's URSP layer can indicate a failure to an upper layer (e.g., the application layer or a layer higher than the application layer, a layer between the URSP layer and the application layer, etc.).

[0243] In step S905, the UE can indicate S-NSSAI to the NAS layer.

[0244] When executing step S905, the NAS layer can check whether the S-NSSAI indicated by the URSP layer is in the On-Demand NSSAI. If the S-NSSAI is in the On-Demand NSSAI, the NAS layer includes the S-NSSAI of the requested NSSAI in the registration request message. Otherwise, the NAS layer can include both the S-NSSAI indicated by the URSP and the S-NSSAI of the On-Demand NSSAI in the requested NSSAI of the registration request message.

[0245] In step S905, the URSP layer can notify all S-NSSAIs in the RSD, regardless of whether the S-NSSAI is in the (partially) allowed NSSAIs. The NAS layer can check whether the S-NSSAI is in the (partially) allowed NSSAIs (compared to the S-NSSAIs indicated by the URSP layer). Otherwise, the NAS layer can trigger a mobility registration update process to register the S-NSSAI by including it in the requested NSSAIs.

[0246] For reference only. Figure 9 The operations included in the example can be performed by the UE's URSP layer.

[0247] Reference Figure 10 This is the third example describing UE operation.

[0248] For example, the URSP layer can instruct S-NSSAI in the RSD only when the UE supports specific functions such as network slicing use control.

[0249] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0250] Figure 10 A third example of terminal operation is shown, illustrating an implementation of the method disclosed in this specification.

[0251] In step S1001, the UE can determine the service descriptor.

[0252] In step S1002, the UE can check the RSD.

[0253] In step S1003, the UE can determine whether the S-NSSAI in the RSD is among the (partially) allowed NSSAIs.

[0254] In step S1004, when the UE supports a specific function (e.g., network slicing use control), the UE's URSP layer can indicate S-NSSAI in the RSD to the NAS layer.

[0255] In step S1005, the UE can indicate S-NSSAI to the NAS layer.

[0256] For reference only. Figure 10 The operations included in the example can be performed by the UE's URSP layer.

[0257] According to reference Figure 8 This is a first example of an operation, and its primary impact may only be on URSP operations. For instance, the UE's URSP layer can additionally indicate a valid On-Demand S-NSSAI in the RSD to the NAS layer. The NAS layer can then perform conventional operations.

[0258] According to reference Figure 10 In a second example of operation, the URSP may no longer need to check the list of network slices stored in the UE, such as (partially) allowed NSSAIs. When an S-NSSAI for a specific service descriptor is found, the URSP can notify the NAS layer of that S-NSSAI. Additionally, the NAS layer can determine the S-NSSAI to be included in the requested NSSAIs of the registration update request message from the configured NSSAIs, considering either (partially) allowed NSSAIs or on-demand NSSAIs. When including an S-NSSAI in the requested NSSAI during the MRU procedure if the RSD condition of the S-NSSAI is not met, the appropriate method can be applied based on... Figure 9 Example of URSP operation.

[0259] According to reference Figure 10 A third example of the operation is that the URSP layer can indicate the S-NSSAI in the RSD to the NAS layer only when the UE supports a specific function such as network slice use control. UEs that support specific functions (e.g., network slice use control) may require new S-NSSAI information (e.g., when the S-NSSAI in the RSD is not included in the (partially) allowed NSSAIs).

[0260] Hereinafter, an example of a first example of terminal operation based on an implementation according to the disclosure of this specification will be described. For reference, Figure 8The specific operation of the first example of terminal operation according to the implementation of the disclosure in this specification described herein is merely an example. For example, Figure 8 The operation can be performed without pressing Figure 8 The sequential execution described in the text Figure 8 Some operations can be omitted, or operations can be performed according to the description below.

[0261] The first example describing the first instance of terminal-based operation.

[0262] For example, the following can be applied to Section 4.2.2.2 of 3GPP TS 24.526 V18.5.0 (e.g., association between application and PDU sessions, non-seamless non-3GPP offloading by the UE, or 5G ProSe Layer 3 UE-to-network relay offloading). The following description will primarily focus on the content set forth in this specification; for omitted content, please refer to Section 4.2.2.2 of 3GPP TS 24.526 V18.5.0.

[0263] In order to send an application's PDU or PIN, the upper layer (e.g., the application layer or a layer higher than the application layer, the layer between the URSP layer and the application layer, etc.) may need information about the PDU session through which the application's PDU or PIN is sent (e.g., the PDU address).

[0264] When an upper layer (e.g., the application layer or a layer higher than the application layer, the layer between the URSP layer and the application layer, etc.) requests PDU session information to send the application's PDU; - If a non-seamless non-3GPP offload is requested due to UE local configuration, the URSP layer can provide information about non-3GPP access outside the PDU session to the upper layers without evaluating URSP rules; or - If a 5G ProSe Layer 3 UE requests to offload to a network relay due to its local UE configuration, the URSP layer can provide information about the 5G ProSe Layer 3 UE to the network relay to the upper layers without evaluating the URSP rules; Otherwise, the UE can execute the following sequence: a) The UE may evaluate URSP rules (excluding the default URSP rule) in ascending order of priority value. These URSP rules have service descriptors (if any) that match application information or PIN information. If a service descriptor includes two or more different types of service descriptor component types, all types should match. If a service descriptor includes two or more service descriptor components of the same service descriptor component type, at least one of the service descriptor components of the same service descriptor component type should match the application information. If no information corresponding to the application information or PIN exists for a particular component of the service descriptor, or if the information corresponding to the application information or PIN does not match any value of the service descriptor component specified in Clause 6.6.2.1 of 3GPP TS 23.503 V18.4.0, then the URSP rule is determined to be inapplicable.

[0265] When the UE finds a service descriptor that matches the application information or PIN information in a non-default URSP rule, the following description may apply: I) If a non-3GPP access connection is established, a connection is established between a 5G ProSe Layer 3 UE and a network relay UE, or one or more established PDU sessions exist, or a combination thereof, the UE may evaluate the routing descriptor of the URSP rule in the following order: For the description of conditions 1), 1a), 1b) and 2), refer to Clause 4.2.2.2 of 3GPP TS 24.526 V18.5.0.

[0266] II) Otherwise, the following description may apply: 1) The UE can select a route descriptor that has not yet been evaluated and has the next lowest priority value; 2) If: For the description of conditions i), ia), ib), ii), iii), iv), v), and va), refer to Clause 4.2.2.2 of 3GPP TS 24.526V18.5.0; vi) If the selected routing descriptor does not include a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, then the UE's URSP processing layer requests the UE NAS layer to establish a PDU session that provides the following PDU session attributes based on the selected routing descriptor: A) SSC mode, if SSC mode is in the routing descriptor; B) An S-NSSAI if the S-NSSAI is in the routing descriptor and is within an allowed NSSAI or on-demand NSSAI (e.g., if on-demand NSSAI is available). For example, in this case, the UE's URSP layer (e.g., the URSP processing layer) can request the UE NAS layer to establish a PDU session based on the S-NSSAI. Additionally, if the UE supports LADNs per DNN and S-NSSAI, the URSP layer request is for a PDU session against the LADN, extended LADN information is available for that LADN, and the S-NSSAI can be associated with that LADN in its service area. If the S-NSSAI in the routing descriptor is not included in an allowed NSSAI or is not in an on-demand NSSAI (e.g., when on-demand NSSAI is available), the UE can proceed to step II) 4). C) A DNN if the DNN is in the routing descriptor; and a DNN if the DNN is an LADN DNN and the UE is in the LADN's service area; D) The PDU session type in the route selection descriptor; E) Preferred access type or multiple access default configuration, if the preferred access type or multiple access default configuration is in the route selection descriptor; F) PDU session pair ID, if the PDU session pair ID is in the routing descriptor; and G) RSN, if RSN is in the routing descriptor.

[0267] The UE NAS layer can indicate the result of PDU session establishment to the URSP layer (e.g., the URSP processing layer). When the PDU session configuration is successfully completed, the UE NAS layer can additionally indicate the attributes of the established PDU session (e.g., PDU session ID, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address) to the URSP processing layer, and provide information about the successfully established PDU session (e.g., PDU address) to higher layers (e.g., the application layer or a layer higher than the application layer, a layer between the URSP layer and the application layer, etc.).

[0268] The UE can stop selecting a routing descriptor that matches the application information or PIN information. If the PDU session establishment fails, the UE proceeds to steps 2) and 3). 3) Depending on the reason for rejection, if other available values ​​exist for the rejected component in the same routing descriptor, the UE uses that value of the rejected component to select another value combination for the currently selected routing descriptor and can proceed to step II) 2). Otherwise, the UE can proceed to step II) 4). 4) If there are route descriptors that have not yet been evaluated, the UE proceeds to step II) 1). If all route descriptors of the matching non-default URSP rules have been evaluated, and there are one or more non-default matching URSP rules that have not yet been evaluated, the UE proceeds to step a). If all non-default matching URSP rules have been evaluated, the UE notifies the upper layer of failure.

[0269] b) If no matching non-default URSP rule is found, and the UE's local configuration for the application or PIN is available, the UE can associate the application or PIN with the PDU session. If no matching PDU session exists, the UE NAS layer attempts to establish a PDU session using the UE's local configuration; and

[0270] If the PDU session is successfully established, the UE NAS layer can provide information about the successfully established PDU session (e.g., the PDU address) to the upper layer. Otherwise, the UE proceeds to step c). c) If no matching non-default URSP rule is found, and the applied UE local configuration is unavailable, or PDU session establishment based on the applied UE local configuration may fail. In this case, if a "match-all" service descriptor exists, the UE can perform application-to-PDU session connection, non-seamless non-3GPP offload, or 5G ProSe Layer 3 UE-to-network relay offload according to the default URSP rule. If the connection fails, the UE notifies the upper layer of the failure.

[0271] HPLMNs can pre-configure URSPs to the UE in the ME or USIM. Subscribed SNPNs can pre-configure URSPs to the UE in the corresponding entry of the "Subscriber Data List" stored in the ME. HPLMNs or subscribed SNPNs can pre-configure URSPs for non-subscribed SNPNs in the ME and associate the URSP with the entry of the subscribed SNPN in the "Subscriber Data List," or associate the URSP with the corresponding PLMN subscription of the HPLMN. As described in Appendix D of 3GPP TS 24.501 V18.5.0, HPLMNs, subscribed SNPNs, and / or non-subscribed SNPNs can provide URSPs to the UE via signaling. For example, the PCF of the HPLMN, subscribed SNPN, and / or non-subscribed SNPN can send a UE policy container including the URSP to the UE.

[0272] When a UE registered to a subscribed SNPN or PLMN has both a pre-configured URSP and a signaling URSP, the UE can use only the signaling URSP.

[0273] A second example describing the first example of terminal-based operation.

[0274] For example, the following can be applied to Section 4.2.2.2 of 3GPP TS 24.526 V18.5.0 (e.g., association between application and PDU sessions, non-seamless non-3GPP offloading by the UE, or 5G ProSe Layer 3 UE-to-network relay offloading). The following description will primarily focus on the content set forth in this specification; for omitted content, please refer to Section 4.2.2.2 of 3GPP TS 24.526 V18.5.0.

[0275] Traditionally, a URSP rule's routing descriptor is considered valid only if all of the following conditions are met: 1) If any S-NSSAI exists, for non-roaming, the S-NSSAI is in the allowed NSSAI or in the (partially) allowed NSSAI, and for roaming, the S-NSSAI is in the mapping from allowed NSSAI (or (partially) allowed NSSAI) to HPLMNS-NSSAI.

[0276] During the verification of the route descriptor, the condition in 1) may not be met for any of the S-NSSAIs of the RSD. In this case, the UE attempts to satisfy the condition by requesting the addition of the S-NSSAI of the RSD to the allowed NSSAIs (or (partially) allowed NSSAIs) through the mobility registration update procedure as specified in Section 5.15.5.2.2 of TS 23.501 V18.4.0.

[0277] Traditional condition 1) There is a problem that NSSAI on demand is not considered at all.

[0278] According to the implementation of the disclosure in this specification, the URSP processing layer indicates the S-NSSAI to the NAS layer only when the UE supports network slice use control and the S-NSSAI of the RSD is in the on-demand NSSAI, so that the NAS layer can use the S-NSSAI of the RSD to perform the MRU procedure.

[0279] On the other hand, according to existing technology, the NAS layer may not be able to trigger the MRU process using the S-NSSAI of the RSD. For example, S-NSSAI#1 included in the on-demand NSSAI may also be located in the RSD. In this case, S-NSSAI#1 does not exist in the (partially) allowed NSSAIs before slice registration is performed via MRU. According to existing technology, since S-NSSAI#1 is not in the allowed NSSAIs, the URSP layer has the following problem: after checking the URSP rules, it cannot notify the NAS layer of S-NSSAI#1 in the RSD. Then, the NAS layer sends the HPLMN S-NSSAI in the configured NSSAI based on the local configuration, or directly sends a PDU session without slice information without MRU. Then, the following problem exists: the network may assign an S-NSSAI that is not in the URSP rules of the terminal to the corresponding PDU session, and in some cases, PDU session re-establishment may also occur after the PDU session is established.

[0280] In order to send an application's PDU or PIN, the upper layer (e.g., the application layer or a layer higher than the application layer, the layer between the URSP layer and the application layer, etc.) may need information about the PDU session through which the application's PDU or PIN is sent (e.g., the PDU address).

[0281] When an upper layer (e.g., the application layer or a layer higher than the application layer, the layer between the URSP layer and the application layer, etc.) requests PDU session information to send the application's PDU; - If a non-seamless non-3GPP offload is requested due to UE local configuration, the URSP layer can provide information about non-3GPP access outside the PDU session to the upper layers without evaluating URSP rules; or - If a 5G ProSe Layer 3 UE requests to offload to a network relay due to its local UE configuration, the URSP layer can provide information about the 5G ProSe Layer 3 UE to the network relay to the upper layers without evaluating the URSP rules; Otherwise, the UE can execute the following sequence: a) The UE may evaluate URSP rules (excluding the default URSP rule) in ascending order of priority value if a service descriptor matches the application information or PIN information. If the service descriptor includes two or more different types of service descriptor component types, all types should match. If the service descriptor includes two or more service descriptor components of the same service descriptor component type, at least one of the service descriptor components of the same service descriptor component type should match the application information. If no information corresponding to the application information or PIN exists for a specific component of the service descriptor, or if the information corresponding to the application information or PIN does not match any value of the service descriptor component specified in Clause 6.6.2.1 of 3GPP TS 23.503 V18.4.0, then the URSP rule is determined to be inapplicable.

[0282] When the UE finds a service descriptor that matches the application information or PIN information in a non-default URSP rule, the following description may apply: I) If a non-3GPP access connection is established, a connection is established between a 5G ProSe Layer 3 UE and a network relay UE, or one or more established PDU sessions exist, or a combination thereof, the UE may evaluate the routing descriptor of the URSP rule in the following order: For the description of conditions 1), 1a), 1b) and 2), refer to Clause 4.2.2.2 of 3GPP TS 24.526 V18.5.0.

[0283] II) Otherwise, the following description may apply: 1) The UE can select a route descriptor that has not yet been evaluated and has the next lowest priority value; if: For the description of conditions i), ia), ib), ii), iii), iv), v), and va), refer to Clause 4.2.2.2 of 3GPP TS 24.526V18.5.0; vi) If the selected routing descriptor does not include a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, then the UE's URSP processing layer requests the UE NAS layer to establish a PDU session that provides the following PDU session attributes based on the selected routing descriptor: A) SSC mode, if SSC mode is in the routing descriptor; B) An S-NSSAI if the S-NSSAI is in the routing descriptor and is within an allowed NSSAI or on-demand NSSAI (e.g., if on-demand NSSAI is available). For example, in this case, the UE's URSP layer (e.g., the URSP processing layer) can request the UE NAS layer to establish a PDU session based on the S-NSSAI. Additionally, if the UE supports LADNs per DNN and S-NSSAI, the URSP layer request is for a PDU session against the LADN, extended LADN information is available for that LADN, and the S-NSSAI can be associated with that LADN in its service area. If the S-NSSAI in the routing descriptor is not included in an allowed NSSAI or is not in an on-demand NSSAI (e.g., when on-demand NSSAI is available), the UE can proceed to step II) 4). B) An S-NSSAI if it is in the routing descriptor and is within the allowed NSSAIs. For example, in this case, the UE's URSP layer (e.g., the URSP processing layer) can request the UE NAS layer to establish a PDU session based on the S-NSSAI. Additionally, if the UE supports LADNs per DNN and S-NSSAI, the URSP layer's request is for a PDU session for the LADN, extended LADN information is available for that LADN, and the S-NSSAI can be associated with that LADN in its service area. When none of the S-NSSAIs in the routing descriptor are included in the allowed NSSAIs, but there is an S-NSSAI included in the on-demand NSSAIs in the routing descriptor, the URSP processing layer can provide an on-demand S-NSSAI to the UE NAS layer before requesting the UE NAS layer to establish a PDU session. If the S-NSSAI in the routing descriptor does not exist in the allowed NSSAI, (partially) allowed NSSAI, or on-demand NSSAI, then the UE proceeds to step II) 4). Note: During the registration process, the UE NAS layer may include on-demand S-NSSAI in the requested NSSAI. For example, the UE NAS layer may send a registration request message that includes the requested NSSAI. The requested NSSAI may include on-demand S-NSSAI.

[0284] B) and the description following the note are the same as the first example of the first example based on terminal operation.

[0285] A third example describing the first example of terminal-based operation.

[0286] For example, the following can be applied to 3GPP TS 24.501 V18.5.0. The following description will primarily focus on the content presented in the disclosure of this specification; for any omitted content, please refer to 3GPP TS 24.501 V18.5.0 (e.g., S4.6.2.9, S5.5.1.3.2).

[0287] Traditionally, a URSP rule's routing descriptor is considered valid only if all of the following conditions are met: 1) If any S-NSSAI exists, for non-roaming, the S-NSSAI is in the allowed NSSAI or in the (partially) allowed NSSAI, and for roaming, the S-NSSAI is in the mapping from allowed NSSAI (or (partially) allowed NSSAI) to HPLMNS-NSSAI.

[0288] During the verification of the route descriptor, the condition in 1) may not be met for any of the S-NSSAIs of the RSD. In this case, the UE attempts to satisfy the condition by requesting the addition of the S-NSSAI of the RSD to the allowed NSSAIs (or (partially) allowed NSSAIs) through the mobility registration update procedure as specified in Section 5.15.5.2.2 of TS 23.501 V18.4.0.

[0289] The UE needs to request the S-NSSAI from the RSD through the MRU procedure in order to add the S-NSSAI to the (partially) allowed NSSAIs.

[0290] According to the third example based on the first example of terminal operation, by clarifying how the UE requests on-demand S-NSSAI during the registration process, the UE may attempt to request S-NSSAI in the RSD (e.g., when S-NSSAI in the RSD is available).

[0291] According to the third example of the first example based on terminal operation, the problem of the UE requesting on-demand S-NSSAI that is not in the RSD during the registration process can be solved.

[0292] This describes an example of network slicing control based on mobility management, according to the first example and the third example of terminal-based operation. For parts omitted in the following description, please refer to 3GPP TS 24.501 V18.5.0S4.6.2.9.

[0293] When the UE and network support network slice usage control, the AMF can monitor network slice usage by running slice registration inactivity timers based on S-NSSAI and access type. The AMF can also provide on-demand NSSAI to the UE in a registration accept message or a CONFIGURATION UPDATE COMMAND message. On-demand NSSAI consists of one or more on-demand S-NSSAIs and optionally, a slice registration inactivity timer for each on-demand S-NSSAI.

[0294] Slicing can be used to deregister inactive timers based on the following operations: a) When there is no established PDU session (including MA PDU session) associated with the corresponding access type S-NSSAI, start the slice to register the inactive timer.

[0295] b) When one or more PDU sessions (including MA PDU sessions) associated with S-NSSAI are successfully established for the corresponding access type, or when S-NSSAI is removed from the allowed NSSAIs, stop and reset the slice to register inactive timers.

[0296] When the value of the slice deregistered inactive timer is updated, the AMF can update the stored timer value and provide the updated timer value to the UE by including it in the REGISTRATION ACCEPT message or CONFIGURATION UPDATE COMMAND message.

[0297] When the UE receives an update value for the slice to register the inactive timer from the AMF in a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message, the UE updates the stored timer value.

[0298] When the slice deregistration inactivity timer expires, the AMF locally removes the S-NSSAI from the allowed NSSAIs for the corresponding access type. Additionally, the AMF can use the new allowed NSSAI to send a configuration update command message to the UE.

[0299] The UE can include the requested on-demand S-NSSAI in the requested NSSAI during the registration process. When the slice deregistration inactivity timer expires, the UE locally removes the S-NSSAI from the allowed NSSAIs of the access type.

[0300] When the UE determines the on-demand S-NSSAI for PDU session establishment as described in various examples disclosed in this specification, the UE may include the on-demand S-NSSAI in the requested NSSAI during the registration process.

[0301] When the UE supports network slice usage control, the AMF provides the UE with the configured NSSAI on-demand NSSAI in the registration accept message or UE configuration update command message. An on-demand NSSAI consists of one or more configured S-NSSAIs.

[0302] When the associated configuration of the S-NSSAI in the stored on-demand NSSAI is deleted by the UE, the on-demand S-NSSAI is removed from the stored configuration of NSSAI by the UE.

[0303] This describes an example of mobility and periodic registration update initiated based on the third example of the first example of terminal-based operation. For omitted content, please refer to Clause 5.5.1.3.2 of 3GPP TS 24.501 V18.5.0.

[0304] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0305] Figure 11 This is an example of a registration process based on an implementation method disclosed in this specification.

[0306] Figure 11 The example illustrates a registration process for mobility registration updates and / or periodic registration updates.

[0307] As an example, according to Figure 11 For example, the UE can send a registration request message to the AMF. The UE can start a timer (e.g., a T3510 timer). The AMF can send a registration accept message to the UE. The UE can stop the timer (e.g., a T3510 timer).

[0308] As another example, according to Figure 11 For example, the UE can send a registration request message to the AMF. The UE can start a timer (e.g., timer T3510). The AMF can send a registration accept message to the UE. The AMF can start a timer (e.g., timer T3550). The UE can stop the timer (e.g., timer T3510). The UE can send a registration complete message to the AMF. The AMF can stop the timer (e.g., timer T3550).

[0309] As yet another example, according to Figure 11For example, the UE can send a registration request message to the AMF. The UE can start a timer (e.g., the T3510 timer). The AMF can send a registration rejection message to the UE. The UE can stop the timer (e.g., the T3510 timer).

[0310] A UE in the 5GMM-REGISTERED state initiates a registration process for mobility and periodic registration updates by sending a registration request message to the AMF. Descriptions of conditions a) to zq) in section 5.5.1.3.2 of 3GPP TS 24.501 V18.5.0 are omitted.

[0311] For example, the UE can send a registration request message to the AMF along with a 5GS registration type IE indicating "mobility registration update".

[0312] The UE may include a requested NSSAI IE in the registration request message, which includes the S-NSSAI (if available) of the mapping associated with the S-NSSAI corresponding to the network slice to be registered.

[0313] When the UE determines the on-demand S-NSSAI for PDU session establishment, the UE may include the on-demand S-NSSAI in the requested NSSAI during the registration process. For example, as specified in various examples disclosed in this specification and / or Clause 4.2.2 of 3GPP TS24.526 V18.5.0, the UE may determine the on-demand S-NSSAI for PDU session establishment.

[0314] For reference, regarding the basis Figure 9 The following example is a second example of terminal operation, and the description of the example can also be applied to Section S4.2.2.3 of TS 24.526 V18.5.0.

[0315] For conditions a), i), and b) of section S4.2.2.3 of TS 24.526 V18.5.0, the following description applies. b) An S-NSSAI if the S-NSSAI is in the routing descriptor; and an S-NSSAI if the S-NSSAI is in an allowed NSSAI or (partially) allowed NSSAI. Additionally, if the UE supports LADN per DNN and S-NSSAI, the request is for a PDU session for the LADN, extended LADN information is available for that LADN, and the S-NSSAI is associated with that LADN in its service area. When none of the S-NSSAIs in the routing descriptor are in an allowed NSSAI or (partially) allowed NSSAI, proceed to step 4) for 5G-RG or W-AGF representing FN-RG. Note 5: During the verification of the route selection descriptor, for all S-NSSAIs of the RSD, if the S-NSSAI is not in the allowed NSSAIs or (partially) allowed NSSAIs for non-roaming, or for roaming, for all S-NSSAIs of the RSD, if the S-NSSAI is not in the mapping of allowed NSSAIs (or (partially) allowed NSSAIs) to HPLMN S-NSSAIs, the UE may attempt to add the S-NSSAI to the allowed NSSAIs (or (partially) allowed NSSAIs) by requesting the S-NSSAIs in the RSD through a mobility registration update procedure (e.g., as specified in Clause 5.15.5.2.2 of TS 23.501 V18.4.0). When a UE attempts to update its mobility registration for an S-NSSAI, the following conditions must be met: for non-roaming, the S-NSSAI is included in the configured NSSAI; for roaming, it is included in the HPLMNS-NSSAI mapped to the configured NSSAI for the VPLMN; and other restrictions as defined in TS 24.501 to prevent triggering a mobility registration update.

[0316] For reference, in various examples of the disclosure in this specification, "instruction" may also include the meaning of sending information related to the purpose of the instruction. For example, a statement that the URSP layer instructs the NAS layer to send A may include the meaning that the URSP layer sends information related to A to the NAS layer.

[0317] The following figures are provided to illustrate specific examples of this disclosure. Since the specific names of the devices or signals / messages / fields described in the figures are presented by way of example, the technical features of this disclosure are not limited to the specific names used in the following figures.

[0318] Figure 12 Examples of operation of embodiments based on the disclosure of this specification are shown.

[0319] For reference only. Figure 12 The procedures illustrated herein are merely examples, and the scope of this disclosure is not limited thereto. Figure 12 Example limitations.

[0320] For example, for Figure 12 Example, Figures 1 to 11 The operations described in the examples can also be applied. For example, even for Figure 12 Operations and content not directly described in the examples may also be applied to operations and content described in the various examples of this disclosure.

[0321] exist Figure 12 In the example, the first network entity can be a mobility-related network entity. For example, the first network entity could be an AMF (Active Mobile Provider).

[0322] Before executing step S1201, the UE can obtain the URSP rules.

[0323] For example, a UE can receive messages that include URSP rules. URSP rules may include RSDs.

[0324] For example, a first network entity can receive a message (e.g., a MANAGE UE POLICY COMMAND message) containing a UE policy container from another network entity (e.g., a PCF). The UE policy container may include URSP rules. The first network entity can send a NAS message containing the UE policy container to the UE.

[0325] As another example, URSP rules can be pre-configured in the UE.

[0326] In step S1201, the UE can receive messages from the first network entity.

[0327] For example, the message may include information related to on-demand NSSAI. This message may be sent to the UE during the initial registration process, MRU, periodic registration process, and / or UE configuration update process.

[0328] In step S1202, the UE may send a registration request message.

[0329] For example, a registration request message may include the requested NSSAI.

[0330] For example, the NSSAI registration request message that includes the request can be a request message used in the mobility registration update process.

[0331] For example, the routing descriptor (RSD) included in the URSP rule includes the first S-NSSAI, and since the first S-NSSAI is an on-demand NSSAI, the on-demand NSSAI can be included in the requested NSSAI.

[0332] For example, based on the fact that the first S-NSSAI is included in the RSD and the first S-NSSAI is an on-demand NSSAI, the first S-NSSAI can be provided to the UE's NAS layer by the UE's URSP layer.

[0333] For example, the first S-NSSAI can be provided to the mobility management entity of the device's NAS layer.

[0334] For example, the UE can determine the on-demand NSSAI used for PDU session establishment.

[0335] For example, based on establishing a defined on-demand S-NSSAI for a PDU session, the on-demand S-NSSAI can be included in the requested NSSAI.

[0336] For example, the UE's URSP processing layer can request the UE's NAS layer to establish a PDU session. For example, the UE's URSP processing layer can provide PDU session attributes to the UE's NAS layer based on RSD.

[0337] For example, the UE's URSP processing layer can provide an S-NSSAI to the UE's NAS layer. For example, when the S-NSSAI is included in the RSD and the S-NSSAI is included in the allowed NSSAI or (partially) allowed NSSAI, the URSP processing layer can provide an S-NSSAI to the UE's NAS layer.

[0338] For example, if none of the S-NSSAIs in the RSD are included in the allowed NSSAIs or (partially) allowed NSSAIs, but the S-NSSAI in the RSD is an on-demand NSSAI, the URSP processing layer can provide that on-demand S-NSSAI to the UE NAS layer. For example, the URSP processing layer can provide that on-demand S-NSSAI to the UE NAS layer before requesting the UE NAS layer to establish a PDU session.

[0339] For example, during the registration process, the UE NAS layer may include the on-demand S-NSSAI in the requested NSSAI and send a mobility registration update request.

[0340] For example, when the UE determines the on-demand S-NSSAI used for PDU session establishment, the UE can include the on-demand S-NSSAI in the requested NSSAI.

[0341] According to the implementation described in this specification, the UE's NAS layer can receive on-demand NSSAIs. Upper layers can generate user services. The URSP layer can execute URSP applications for server services. When an S-NSSAI found in the routing descriptor is among the on-demand NSSAIs, the URSP layer can indicate the S-NSSAI to the NAS layer. The NAS layer can send a registration update request message including the S-NSSAI indicated by the URSP layer. The NAS layer can receive a registration update acceptance message including an allowed NSSAI.

[0342] According to the implementation described in this specification, upper layers may require information about the PDU session. The URSP layer can evaluate URSP rules and provide the NAS layer with the S-NSSAI and on-demand NSSAI in the routing descriptor. The NAS layer can perform the registration update process by including the S-NSSAI provided by the URSP layer in the requested NSSAI.

[0343] According to the implementation described in this specification, when checking the S-NSSAI in the routing descriptor information, the terminal's URSP layer can check the S-NSSAI in the on-demand NSSAI list and (partially) allowed NSSAIs. When a matching S-NSSAI is found, the terminal's URSP layer notifies the NAS layer of the matching S-NSSAI, and the NAS layer can perform a registration update process by including the S-NSSAI in the requested NSSAI information.

[0344] For reference, according to existing technology, an interface with the NAS layer is created only when the URSP layer performs a NAS session management procedure (e.g., a PDU session establishment procedure). However, according to the implementation of the disclosure in this specification, the URSP layer may deliver information required for performing NAS mobility management procedures (e.g., registration updates for network slice registration) to the NAS layer.

[0345] This disclosure can have various effects.

[0346] For example, it can effectively support network slice-based communication.

[0347] For example, based on network slice information, a terminal can request to register an accurate network slice and / or request to use an accurate network slice. Therefore, policy-based service processing desired by the network can be achieved. Furthermore, by requesting network slices available in the corresponding area and having them confirmed by the network, registration rejection can be prevented. Additionally, by requesting network slices available in the corresponding area and having them confirmed by the network, additional network operations (e.g., URSP updates) required to find a network slice matching the service and configure the PDU session can be prevented.

[0348] The beneficial effects that can be obtained through specific embodiments of this disclosure are not limited to those listed above. For example, those skilled in the art can understand or deduce various technical effects from this disclosure. Therefore, the specific effects of this disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or deduced from the technical features of this disclosure.

[0349] For reference, the operation of the terminal (e.g., UE) described in this disclosure can be achieved through the above... Figures 1 to 3This is achieved through a device. For example, the terminal could be... Figure 2 The first device 100 or the second device 200. For example, the operation of the terminal described in this disclosure can be processed by one or more processors 102 or 202. The operation of the terminal described in this disclosure can be stored in one or more memories 104 or 204 in the form of instructions / programs (e.g., instructions, executable code) executable by one or more processors 102 or 202. One or more processors 102 or 202 can control one or more memories 104 or 204 and one or more transceivers 105 or 206, and execute the instructions / programs stored in one or more memories 104 or 204 to perform the operation of the terminal (e.g., UE) described in this disclosure.

[0350] Furthermore, instructions for performing the operations of the terminal described in this disclosure may be stored in a non-volatile computer-readable storage medium on which they are recorded. The storage medium may be included in one or more memories 104 or 204. The instructions recorded in the storage medium may be executed by one or more processors 102 or 202 to perform the operations of the terminal described in this disclosure.

[0351] For reference, the operation of network nodes (e.g., AMF, SMF, PCF, UDM, UAS-AF, LMF, etc.) or base stations (e.g., NG-RAN, gNB, RAN, eNB, (R)AN, etc.) described in this disclosure can be performed as described below. Figures 1 to 3 This is achieved through devices. For example, a network node or base station could be... Figure 2 The first device 100 or the second device 200. For example, the operation of the network node or base station described in this disclosure can be processed by one or more processors 102 or 202. The operation of the terminal described in this disclosure can be stored in one or more memories 104 or 204 in the form of instructions / programs (e.g., instructions, executable code) executable by one or more processors 102 or 202. One or more processors 102 or 202 can control one or more memories 104 or 204 and one or more transceivers 106 or 206, and execute the instructions / programs stored in one or more memories 104 or 204 to perform the operation of the network node or base station described in this disclosure.

[0352] Additionally, instructions for performing the operations of the network nodes or base stations described in this disclosure may be stored in a non-volatile (or non-transitory) computer-readable storage medium on which they are recorded. The storage medium may be included in one or more memories 104 or 204. The instructions recorded in the storage medium may be executed by one or more processors 102 or 202 to perform the operations of the network nodes or base stations described in this disclosure.

[0353] While preferred embodiments have been described above by way of example, this disclosure is not limited to such specific embodiments and may be modified, altered or improved in various forms within the spirit of this disclosure and within the scope of the claims.

[0354] In the exemplary system described above, the method is described as a series of steps or blocks based on the flowchart, but is not limited to the order of the described steps, and some steps may occur in a different order than described above or simultaneously with other steps. Furthermore, those skilled in the art will understand that the steps shown in the flowchart are not exclusive and may include other steps, or one or more steps of the flowchart may be deleted without affecting the scope of the claims.

[0355] The claims in this disclosure can be combined in various ways. For example, the technical features in the method claims of this disclosure can be combined to implement or perform in a device, and the technical features in the device claims can be combined to implement or perform in a method. Furthermore, the technical features in the method claims and device claims can be combined to implement or perform in a device. Other implementations are within the scope of the following claims.

Claims

1. A method comprising the following steps: Receive messages that include information related to on-demand network slice selection assistance information (NSSAI); as well as Send an NSSAI registration request message that includes the request. Specifically, the first single NSSAI (S-NSSAI) is included in the requested NSSAI based on the routing descriptor (RSD) included in the user equipment (UE) routing policy (URSP) rule, and the on-demand NSSAI is included in the requested NSSAI based on the first S-NSSAI being the on-demand NSSAI.

2. The method according to claim 1, in, The registration request message from NSSAI that includes the request is a request message used in the mobility registration update process.

3. The method according to claim 1 or 2, in, Based on the fact that the first S-NSSAI is included in the RSD, and based on the fact that the first S-NSSAI is the on-demand NSSAI, the first S-NSSAI is provided to the NAS layer of the device by the URSP layer of the device.

4. The method according to claim 3, in, The first S-NSSAI is provided to the mobility management entity of the NAS layer of the device, and The registration request message from NSSAI that includes the request is a request message used in the mobility registration update process.

5. The method according to any one of claims 1 to 4, further comprising the step of: The on-demand S-NSSAI used for Protocol Data Unit (PDU) session establishment is determined.

6. The method according to claim 5, in, The on-demand S-NSSAI is determined based on the establishment of the PDU session, and the on-demand S-NSSAI is included in the requested NSSAI.

7. The method according to any one of claims 1 to 6, further comprising the step of: Obtain the URSP rule that includes the RSD.

8. An apparatus, the apparatus comprising: One or more transceivers; One or more processors; as well as One or more memories, which store instructions and are operatively connectable to one or more processors. The operations performed based on the instructions being executed by the one or more processors include: the method according to any one of claims 1 to 7.

9. An apparatus, the apparatus comprising: At least one processor; as well as At least one memory, which stores instructions and is electrically connected to the at least one processor in operation. The operation performed based on the instruction being executed by the at least one processor includes: the method according to any one of claims 1 to 7.

10. A non-transitory computer-readable medium (CRM), said CRM recording instructions, in, When the instructions are executed by one or more processors, the one or more processors cause the processors to perform the method according to any one of claims 1 to 7.

Images