Network slice

Abstract

One disclosure of the present specification provides a method. The method may comprise the steps of: receiving a message including information related to on-demand NSSAI; and transmitting a registration request message including requested NSSAI.

Description

Network Slice

[0001] This specification relates to mobile communications.

[0002] 3GPP (3rd Generation Partnership Project) LTE (Long-Term Evolution) is a technology designed to enable high-speed packet communications. Numerous approaches have been proposed to achieve LTE's goals of reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. 3GPP LTE's high-level requirements include reduced cost per bit, improved service availability, flexible use of frequency bands, a simple architecture, open interfaces, and adequate power consumption for terminals.

[0003] The International Telecommunication Union (ITU) and 3GPP have begun work on developing requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components necessary to successfully standardize NR, meeting both urgent market needs and the longer-term requirements outlined by the ITU Radio communication sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. NR must also be able to utilize any spectrum band up to at least 100 GHz, ensuring that it remains available for wireless communications well into the future.

[0004] NR aims to be a single technology framework that addresses all deployment scenarios, usage scenarios, and requirements, including enhanced Mobile Broadband (eMBB), massive Machine Type Communications (mMTC), and Ultra-Reliable and Low Latency Communications (URLLC). NR must be inherently forward-compatible.

[0005] Network slice-based communication is being discussed. However, conventional technologies have a problem in that they do not effectively support various types of network slice-based communication, such as allowed NSSAI, partially allowed NSSAI, and on-demand NSSAI.

[0006] According to one embodiment of the present disclosure, a method is provided. The method may include receiving a message including information related to an on-demand NSSAI; and transmitting a registration request message including the requested NSSAI.

[0007] According to one embodiment, a device implementing the method is provided.

[0008] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.

[0009] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.

[0010] Figure 3 shows an example of a UE to which the implementation of this specification is applied.

[0011] Figure 4 shows an example of a 5G system structure to which the implementation of this specification is applied.

[0012] Figures 5 and 6 illustrate examples of registration procedures to which the implementation of the present specification applies.

[0013] Figure 7 is an example of a procedure for a UE to obtain URSP information.

[0014] FIG. 8 is a first example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0015] FIG. 9 is a second example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0016] FIG. 10 is a third example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0017] FIG. 11 is an example of a registration procedure according to one embodiment of the disclosure of the present specification.

[0018] FIG. 12 illustrates an example of operations according to one embodiment of the disclosure of the present specification.

[0019] The following techniques, devices, and systems can be applied to various 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 wireless technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented using wireless technologies such as Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data rates for GSM Evolution (EDGE). OFDMA can be implemented using wireless technologies such as IEEE (Institute of Electrical and Electronics Engineers) 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). 3GPP (3rd Generation Partnership Project) Long-Term Evolution (LTE) is part of E-UMTS (Evolved UMTS) that utilizes E-UTRA.3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and / or 5G NR (New Radio).

[0020] For convenience of explanation, the implementation of this specification is primarily described in relation to a 3GPP-based wireless communication system. However, the technical features of this specification are not limited thereto. For example, the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of this specification that are not limited to a 3GPP-based wireless communication system can be applied to other mobile communication systems.

[0021] For terms and technologies used in this specification that are not specifically described, reference may be made to wireless communication standard documents published prior to this specification.

[0022] As used herein, "A or B" can mean "only A," "only B," or "both A and B." Alternatively, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."

[0023] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0024] In this specification, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in this specification, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted identically to “at least one of A and B.”

[0025] Additionally, in this specification, “at least one of A, B and C” can mean “only A”, “only B”, “only C”, or “any combination of A, B and C”. Additionally, “at least one of A, B or C” or “at least one of A, B and / or C” can mean “at least one of A, B and C”.

[0026] Additionally, parentheses used in this specification may mean "for example." Specifically, when indicated as "control information (PDCCH)", "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (e.g., PDCCH)", "PDCCH" may be proposed as an example of "control information."

[0027] Technical features individually described in a single drawing in this specification may be implemented individually or simultaneously.

[0028] Although not limited thereto, the various descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein may be applied to various fields requiring wireless communication and / or connectivity between devices (e.g., 5G).

[0029] Hereinafter, the present specification will be described in more detail with reference to the drawings. In the following drawings and / or description, the same reference numbers may refer to the same or corresponding hardware blocks, software blocks, and / or functional blocks, unless otherwise indicated.

[0030] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.

[0031] The 5G usage scenario shown in FIG. 1 is only an example, and the technical features of this specification can be applied to other 5G usage scenarios not shown in FIG. 1.

[0032] The three main requirement categories for 5G are (1) enhanced mobile broadband (eMBB), (2) massive machine type communication (mMTC), and (3) ultra-reliable and low latency communications (URLLC).

[0033] Referring to FIG. 1, a communication system (1) includes wireless devices (100a to 100f), a base station (BS; 200), and a network (300). FIG. 1 illustrates a 5G network as an example of a network of the communication system (1), but the implementation of the present disclosure is not limited to a 5G system and can be applied to future communication systems beyond the 5G system.

[0034] The base station (200) and the network (300) may be implemented as wireless devices, and a particular wireless device may operate as a base station / network node in relation to other wireless devices.

[0035] The wireless devices (100a to 100f) represent devices that perform communication using Radio Access Technology (RAT) (e.g., 5G NR or LTE) and may also be referred to as communication / wireless / 5G devices. The wireless devices (100a to 100f) may include, but are not limited to, a robot (100a), a vehicle (100b-1 and 100b-2), an extended reality (XR) device (100c), a portable device (100d), a home appliance (100e), an Internet-of-Things (IoT) device (100f), and an artificial intelligence (AI) device / server (400). For example, the vehicles may include vehicles having wireless communication capabilities, autonomous vehicles, and vehicles capable of performing vehicle-to-vehicle communication. The vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR (Augmented Reality) / VR (Virtual Reality) / MR (Mixed Reality) devices, and may be implemented in the form of HMD (Head-Mounted Device) and HUD (Head-Up Display) mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. Portable devices may include smartphones, smart pads, wearable devices (e.g., smart watches 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.

[0036] In this specification, wireless devices (100a to 100f) may be referred to as user equipment (UE). The UE may include, for example, a mobile phone, a smartphone, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, a vehicle with autonomous driving function, a connected car, a UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a fintech device (or a financial device), a security device, a weather / environmental device, a 5G service-related device, or a 4th industrial revolution-related device.

[0037] Wireless devices (100a to 100f) can be connected to a network (300) via a base station (200). AI technology can be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) via the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a network after 5G. The wireless devices (100a to 100f) can communicate with each other via the base station (200) / network (300), but can also communicate directly (e.g., sidelink communication) without going through the base station (200) / network (300). For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). Additionally, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

[0038] Wireless communication / connection (150a, 150b, 150c) can be established between wireless devices (100a to 100f) and / or between wireless devices (100a to 100f) and a base station (200) and / or between base stations (200). Here, the wireless communication / connection can be established through various RATs (e.g., 5G NR), such as uplink / downlink communication (150a), sidelink communication (150b) (or, D2D (Device-To-Device) communication), and base station-to-base station communication (150c) (e.g., relay, IAB (Integrated Access and Backhaul)). Through the wireless communication / connection (150a, 150b, 150c), the wireless devices (100a to 100f) and the base station (200) can transmit / receive wireless signals to / from each other. For example, wireless communication / connection (150a, 150b, 150c) can transmit / receive signals through various physical channels. To this end, based on various proposals of this specification, at least some of various configuration information setting processes for transmitting / receiving wireless signals, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and resource allocation processes can be performed.

[0039] NR supports multiple numerologies, or subcarrier spacings (SCS), to support diverse 5G services. For example, an SCS of 15 kHz supports wide areas in traditional cellular bands; an SCS of 30 kHz / 60 kHz supports dense urban areas, lower latency, and wider carrier bandwidth; and an SCS of 60 kHz or higher supports bandwidths greater than 24.25 GHz to overcome phase noise.

[0040] The NR frequency band can be defined by two types of frequency ranges (FR1 and FR2). The numerical values ​​of the frequency ranges can be changed. For example, the two types of frequency ranges (FR1 and FR2) can be as shown in Table 1 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 can mean the "sub 6 GHz range," and FR2 can mean the "above 6 GHz range," which can be called millimeter wave (mmW).

[0041] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0042] As described above, the numerical value of the frequency range of the NR system can be changed. For example, FR1 may include a band from 410 MHz to 7125 MHz, as shown in Table 2 below. For example, FR1 may include a frequency band above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency band above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included within FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, such as for communications for vehicles (e.g., autonomous driving).

[0043] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0044] Here, the wireless communication technology implemented in the wireless device of the present specification may include not only LTE, NR, and 6G, but also Narrowband IoT (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology and may be implemented with standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be called by various names such as eMTC (enhanced MTC). For example, LTE-M technology can be implemented by at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (Non-Bandwidth Limited), 5) LTE-MTC, 6) LTE MTC, and / or 7) LTE M, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification can include at least one of ZigBee, Bluetooth, and / or LPWAN considering low-power communication, and is not limited to the above-described names. For example, ZigBee technology can create PANs (Personal Area Networks) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and can be called by various names.

[0045] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.

[0046] In FIG. 2, the first wireless device (100) and / or the second wireless device (200) may be implemented in various forms depending on the use case / service. For example, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of {the wireless devices (100a to 100f) and the base station (200)}, {the wireless devices (100a to 100f) and the wireless devices (100a to 100f)}, and / or {the base station (200) and the base station (200)} of FIG. 1. The first wireless device (100) and / or the second wireless device (200) may be configured by various components, devices / parts, and / or modules.

[0047] The first wireless device (100) may include at least one transceiver, such as a transceiver (106), at least one processing chip, such as a processing chip (101), and / or one or more antennas (108).

[0048] The processing chip (101) may include at least one processor, such as a processor (102), and at least one memory, such as a memory (104). Additionally and / or alternatively, the memory (104) may be located external to the processing chip (101).

[0049] The processor (102) may control the memory (104) and / or the transceiver (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. For example, the processor (102) may process information in the memory (104) to generate first information / signal and transmit a wireless signal including the first information / signal via the transceiver (106). The processor (102) may receive a wireless signal including second information / signal via the transceiver (106) and store information obtained by processing the second information / signal in the memory (104).

[0050] A memory (104) may be operatively connected to the processor (102). The memory (104) may store various types of information and / or instructions. The memory (104) may store firmware and / or software code (105) that implements code, instructions and / or sets of instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may implement instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more protocols. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more air interface protocol layers.

[0051] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and may transmit and / or receive wireless signals via one or more antennas (108). Each transceiver (106) may include a transmitter and / or a receiver. The transceiver (106) may be used interchangeably with an RF (Radio Frequency) unit. In the present specification, the first wireless device (100) may represent a communication modem / circuit / chip.

[0052] The second wireless device (200) may include at least one transceiver, such as a transceiver (206), at least one processing chip, such as a processing chip (201), and / or one or more antennas (208).

[0053] The processing chip (201) may include at least one processor, such as a processor (202), and at least one memory, such as a memory (204). Additionally and / or alternatively, the memory (204) may be located external to the processing chip (201).

[0054] The processor (202) may control the memory (204) and / or the transceiver (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein. For example, the processor (202) may process information in the memory (204) to generate third information / signal and transmit a wireless signal including the third information / signal via the transceiver (206). The processor (202) may receive a wireless signal including fourth information / signal via the transceiver (206) and store information obtained by processing the fourth information / signal in the memory (204).

[0055] A memory (204) may be operatively connected to the processor (202). The memory (204) may store various types of information and / or instructions. The memory (204) may store firmware and / or software code (205) that implements code, instructions and / or sets of instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may implement instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more protocols. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more air interface protocol layers.

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

[0057] Hereinafter, hardware elements of the wireless device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as a physical (PHY) layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Resource Control (RRC) layer, and a Service Data Adaptation Protocol (SDAP) layer). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs), one or more Service Data Units (SDUs), messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. One or more processors (102, 202) can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein and provide the signals to one or more transceivers (106, 206). One or more processors (102, 202) can receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and obtain PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein.

[0058] The one or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, and / or a microcomputer. The one or more processors (102, 202) may be implemented by hardware, firmware, software, and / or a combination thereof. For 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), and / or one or more Field Programmable Gate Arrays (FPGAs) may be included in the one or more processors (102, 202). For example, the one or more processors (102, 202) may be configured by a set of a communication control processor, an Application Processor (AP), an Electronic Control Unit (ECU), a Central Processing Unit (CPU), a Graphic Processing Unit (GPU), and a Memory Control Processor. One or more memories (104, 204) may be coupled to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions and / or commands. The one or more memories (104, 204) may be configured as random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, volatile memory, nonvolatile memory, hard drive, register, cache memory, computer readable storage media and / or combinations thereof.One or more memories (104, 204) may be located internally and / or externally to one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) via various technologies, such as wired or wireless connections.

[0059] One or more transceivers (106, 206) can transmit user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein to one or more other devices. One or more transceivers (106, 206) can receive user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein from one or more other devices. For example, one or more transceivers (106, 206) can be coupled to one or more processors (102, 202) and can transmit and receive wireless signals. For example, one or more processors (102, 202) can control one or more transceivers (106, 206) to transmit user data, control information, wireless signals, etc., to one or more other devices. Additionally, one or more processors (102, 202) may control one or more transceivers (106, 206) to receive user data, control information, wireless signals, etc. from one or more other devices.

[0060] One or more transceivers (106, 206) may be coupled to one or more antennas (108, 208). Additionally and / or alternatively, one or more transceivers (106, 206) may include one or more antennas (108, 208). One or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein via one or more antennas (108, 208). In the present disclosure, one or more antennas (108, 208) may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

[0061] One or more transceivers (106, 206) may convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process the received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) may convert processed user data, control information, wireless signals / channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and / or a filter. For example, one or more transceivers (106, 206) may up-convert an OFDM baseband signal to an OFDM signal via an (analog) oscillator and / or filter under the control of one or more processors (102, 202) and transmit the up-converted OFDM signal at a carrier frequency. One or more transceivers (106, 206) may receive an OFDM signal at a carrier frequency and down-convert the OFDM signal to an OFDM baseband signal via an (analog) oscillator and / or filter under the control of one or more processors (102, 202).

[0062] Although not illustrated in FIG. 2, the wireless device (100, 200) may further include additional components. The additional components (140) may be configured in various ways depending on the type of the wireless device (100, 200). For example, the additional components (140) may include at least one of a power unit / battery, an input / output (I / O) device (e.g., an audio I / O port, a video I / O port), a driving device, and a computing device. The additional components (140) may be connected to one or more processors (102, 202) via various technologies, such as a wired or wireless connection.

[0063] In the implementation of this specification, a UE can operate as a transmitter in the uplink and as a receiver in the downlink. In the implementation of this specification, a base station can operate as a receiver in the UL and as a transmitter in the DL. For the sake of convenience of description, it is mainly assumed below that the first wireless device (100) operates as a UE and the second wireless device (200) operates as a base station. For example, a processor (102) connected to, mounted on, or released in the first wireless device (100) can be configured to perform UE operations according to the implementation of this specification or to control a transceiver (106) to perform UE operations according to the implementation of this specification. A processor (202) connected to, mounted on, or released in the second wireless device (200) can be configured to perform base station operations according to the implementation of this specification or to control a transceiver (206) to perform base station operations according to the implementation of this specification.

[0064] In this specification, a base station may be referred to as a Node B, an eNode B (eNB), or a gNB.

[0065] Figure 3 shows an example of a UE to which the implementation of this specification is applied.

[0066] Referring to FIG. 3, the UE (100) can correspond to the first wireless device (100) of FIG. 2.

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

[0068] The processor (102) may be configured to implement the descriptions, functions, procedures, proposals, methods and / or flowcharts disclosed herein. The processor (102) may be configured to control one or more other components of the UE (100) to implement the descriptions, functions, procedures, proposals, methods and / or flowcharts disclosed herein. A layer of a radio interface protocol may be implemented in the processor (102). The processor (102) may include an ASIC, other chipsets, logic circuits and / or data processing devices. The processor (102) may be an application processor. The processor (102) may include at least one of a DSP, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a modem (modulator and demodulator). An example of the processor (102) is the SNAPDRAGON manufactured by Qualcomm®. TM Series processors, EXYNOS made by Samsung® TM Series processors, A-series processors made by Apple®, HELIO made by MediaTek® TM ATOM series processors made by Intel® TM It can be found in the series processors or the corresponding next-generation processors.

[0069] Memory (104) is operatively coupled to the processor (102) and stores various information for operating the processor (102). Memory (104) may include ROM, RAM, flash memory, memory cards, storage media, and / or other storage devices. When the implementation is implemented in software, the techniques described herein may be implemented using modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. The modules may be stored in memory (104) and executed by the processor (102). Memory (104) may be implemented within the processor (102) or external to the processor (102), in which case it may be communicatively coupled to the processor (102) via various methods known in the art.

[0070] A transceiver (106) is operably coupled to the processor (102) and transmits and / or receives a radio signal. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include a baseband circuit for processing a radio frequency signal. The transceiver (106) controls one or more antennas (108) to transmit and / or receive a radio signal.

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

[0072] The display (143) outputs the results processed by the processor (102). The keypad (144) receives input to be used by the processor (102). The keypad (144) can be displayed on the display (143).

[0073] A SIM card (145) is an integrated circuit that securely stores an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate subscribers in mobile devices such as mobile phones and computers. Additionally, many SIM cards can store contact information.

[0074] The speaker (146) outputs sound-related results processed by the processor (102). The microphone (147) receives sound-related input to be used by the processor (102).

[0075] Figure 4 shows an example of a 5G system structure to which the implementation of this specification is applied.

[0076] The 5G system (5GS; 5G system) structure consists of the following network functions (NF; Network Function).

[0077] - AUSF (Authentication Server Function)

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

[0079] - DN (Data Network), for example, operator services, Internet access, or third-party services.

[0080] - USDF (Unstructured Data Storage Function)

[0081] - NEF (Network Exposure Function)

[0082] - I-NEF (Intermediate NEF)

[0083] - NRF (Network Repository Function)

[0084] - NSSF (Network Slice Selection Function)

[0085] - PCF (Policy Control Function)

[0086] - SMF (Session Management Function)

[0087] - UDM (Unified Data Management)

[0088] - UDR (Unified Data Repository)

[0089] - UPF (User Plane Function)

[0090] - UCMF (UE radio Capability Management Function)

[0091] - AF (Application Function)

[0092] - UE (User Equipment)

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

[0094] - 5G-EIR (5G-Equipment Identity Register)

[0095] - NWDAF (Network Data Analytics Function)

[0096] - CHF (CHarging Function)

[0097] 또한, 다음과 같은 네트워크 기능이 고려될 수 있다.

[0098] - N3IWF (Non-3GPP InterWorking Function)

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

[0100] - W-AGF (Wireline Access Gateway Function)

[0101] Figure 4 illustrates the 5G system architecture for a non-roaming case using a reference point representation showing how various network functions interact with each other.

[0102] For clarity of the point-to-point diagram in Figure 4, UDSF, NEF, and NRF are not illustrated. However, all network functions shown can interact with UDSF, UDR, NEF, and NRF as needed.

[0103] For clarity, the connection between UDR and other NFs (e.g., PCF) is not shown in Fig. 4. For clarity, the connection between NWDAF and other NFs (e.g., PCF) is not shown in Fig. 4.

[0104] The 5G system architecture includes the following benchmarks:

[0105] - 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 two UPFs.

[0111] The following benchmarks 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 two AMFs.

[0120] - N15: Reference point between PCF and AMF for non-roaming scenarios, and reference point between PCF and AMF of visited network for roaming scenarios.

[0121] - N16: Reference point between two SMFs (in case of roaming, between the SMF of the visited network and the SMF of the home network)

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

[0123] In some cases, two NFs may need to be interconnected to serve a UE.

[0124] Describes the registration procedure. See section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0125] Figures 5 and 6 illustrate examples of registration procedures to which the implementation of the present specification applies.

[0126] A UE must register with the network to receive services, enable mobility tracking, and enable reachability. The UE initiates the registration process using one of the following registration types:

[0127] - Initial registration for 5GS; or

[0128] - mobility registration update; or

[0129] - Periodic registration update; or

[0130] - Emergency registration

[0131] The general registration procedures of Figures 5 and 6 apply to all registration procedures described above, but periodic registration updates do not need to include all parameters used in other registration procedures.

[0132] The general registration procedures of Figures 5 and 6 can also be used to register a UE for a 3GPP connection when it is already registered for a non-3GPP connection, and vice versa. Registering a UE for a 3GPP connection when it is already registered for a non-3GPP connection scenario may require an AMF change.

[0133] First, the procedure of Fig. 5 is described.

[0134] (1) Step 1: The UE transmits a Registration Request message to the (R)AN. The Registration Request message corresponds to an AN message.

[0135] The registration request message may include AN parameters. For NG-RAN, the AN parameters include, for example, the 5G SAE temporary mobile subscriber identity (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 assistance information (NSSAI). The AN parameters also include an establishment cause. The establishment cause provides the reason for requesting establishment of 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 inclusion mode parameter.

[0136] A registration request message may include a registration type. The registration type indicates whether the UE wants to perform an initial registration (e.g., the UE is in RM-DEREGISTERED state), or a mobility registration update (e.g., the UE is in RM-REGISTERED state and initiates a registration procedure because the UE moves, or the UE wants to update capabilities or protocol parameters, or requests a change in the set of network slices the UE is allowed to use), or a periodic registration update (e.g., the UE is in RM-REGISTERED state and initiates a registration procedure because a periodic registration update timer expires), or an emergency registration (e.g., the UE is in a restricted service state).

[0137] When a UE performs initial registration, the UE indicates its UE ID in the registration request message, listed in decreasing priority order.

[0138] i) If the UE has a valid evolved packet system (EPS) globally unique temporary identifier (GUTI), 5G-GUTI mapped from the EPS GUTI;

[0139] ii) Native 5G-GUTI (if available) allocated by the PLMN in which the UE is attempting to register;

[0140] iii) Native 5G-GUTI allocated by a PLMN equivalent to the PLMN in which the UE is attempting to register;

[0141] iv) Native 5G-GUTI allocated by another PLMN (if available);

[0142] v) Otherwise, the UE includes a subscriber concealed identifier (SUCI) in the registration request message.

[0143] If a UE performing initial registration has both a valid EPS GUTI and a native 5G-GUTI, the UE also indicates the native 5G-GUTI as an additional GUTI. If more than one native 5G-GUTI is available, the UE selects a 5G-GUTI from items (ii)-(iv) in decreasing priority order in the list above.

[0144] When the UE performs initial registration with native 5G-GUTI, the UE indicates relevant GUAMI information in the AN parameters. When the UE performs initial registration with SUCI, the UE does not indicate GUAMI information in the AN parameters.

[0145] For emergency registration, if the UE does not have a valid 5G-GUTI, the SUCI is included. If the UE does not have a subscriber permanent identifier (SUPI) and does not have a valid 5G-GUTI, the PEI (Permanent Equipment Identifier) ​​is included. Otherwise, the 5G-GUTI is included, indicating the last serving AMF.

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

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

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

[0149] When the UE is in CM-CONNECTED state, (R)AN can forward a registration request message to AMF based on the N2 connection of the UE.

[0150] If the (R)AN cannot select an appropriate AMF, the (R)AN performs AMF selection by forwarding a registration request message to the AMF configured in the (R)AN.

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

[0152] The registration request message may contain all of the information and / or part of the information contained in the registration request message received from the UE described in step 1.

[0153] The registration request message may include an N2 parameter. When NG-RAN is used, the N2 parameter includes the selected PLMN ID (or PLMN ID and NID), location information and cell ID related to the cell where the UE is camping, and a UE context request indicating that a UE context including security information should be established in the NG-RAN. When NG-RAN is used, the N2 parameter also includes an establishment cause.

[0154] If the registration type indicated by the UE is periodic registration update, steps 4-19 described below may be omitted.

[0155] (4) Step 4: If the UE's 5G-GUTI is included in the registration request message and the serving AMF has changed since the last registration procedure, the new AMF may invoke the Namf_Communication_UEContextTransfer service operation to the previous AMF, including the full registration request non-access stratum (NAS) message to request the UE's SUPI and UE context.

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

[0157] (6) Step 6: If SUCI is not provided by the UE or not retrieved from the previous AMF, the new AMF may initiate an ID request procedure by sending an Identity Request message to request SUCI from the UE.

[0158] (7) Step 7: The UE may respond with an Identity Response message including the SUCI. The UE derives the SUCI using the provided public key of the home PLMN (HPLMN).

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

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

[0161] (10) Step 10: If the AMF has changed, the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation to notify the old AMF that the UE registration with the new AMF is complete. If the authentication / security procedure fails, the registration is rejected and the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation with a reject indication reason code to the old AMF. The old AMF may continue as if the UE context transfer service operation was not received.

[0162] (11) Step 11: If the PEI was not provided by the UE or was not retrieved from the previous AMF, the new AMF may initiate the ID request procedure by sending an Identity Request message to the UE to retrieve the PEI. The PEI is transmitted encrypted, except when the UE performs emergency registration and cannot be authenticated.

[0163] (12) Step 12: Optionally, the new AMF can initiate ME ID checking by calling the N5g-eir_EquipmentIdentityCheck_Get service operation.

[0164] Now, the procedure of Fig. 6 following the procedure of Fig. 5 is described.

[0165] (13) Step 13: When step 14 below is performed, the new AMF can select a UDM based on SUPI, and the UDM can select a UDR instance.

[0166] (14) Step 14: New AMFs can be registered with UDM.

[0167] (15) Step 15: New AMF can select PCF.

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

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

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

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

[0172] (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.

[0173] (21) Step 21: The new AMF sends a Registration Accept message to the UE.

[0174] The new AMF sends the UE a Registration Accept message indicating that the registration request has been accepted. If the new AMF allocates a new 5G-GUTI, it includes the 5G-GUTI. If the UE is already in the RM-REGISTERED state through another connection to the same PLMN, the UE uses the 5G-GUTI received in the Registration Accept message for both registrations. If the Registration Accept message does not include a 5G-GUTI, the UE uses the 5G-GUTI assigned to the existing registration for the new registration. If the new AMF allocates a new registration area, it sends the registration area to the UE in the Registration Accept message. If the Registration Accept message does not include a registration area, the UE considers the previous registration area to be valid. Mobility Restrictions are included if mobility restrictions apply to the UE and the registration type is not emergency registration. The new AMF indicates the PDU sessions established for the UE in the PDU Session State. The UE locally removes internal resources associated with PDU sessions that are not marked as established in the received PDU Session State. When a UE is connected to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the UE locally removes internal resources associated with PDU sessions in the current PLMN that are not marked as established in the received PDU session status. If PDU session status information is present in the Registration Accept message, the new AMF indicates the PDU session status to the UE.

[0175] The allowed NSSAI (allowed NSSAI or partially allowed NSSAI) provided in the Registration Accept message is valid in the registration area and applies to all PLMNs that have a tracking area included in the registration area. The mapping of the allowed NSSAI (Mapping Of (partially) allowed NSSAI) maps the HPLMN S-NSSAI to each S-NSSAI of the allowed NSSAI. The mapping of the configured NSSAI maps the HPLMN S-NSSAI to each S-NSSAI of the configured NSSAI for the serving PLMN.

[0176] Additionally, optionally, the new AMF performs UE policy association establishment.

[0177] (22) Step 22: If the UE successfully updates itself, it can send a Registration Complete message to the new AMF.

[0178] The UE may send a registration complete message to the new AMF to confirm that a new 5G-GUTI has been allocated.

[0179] (23) Step 23: In case of registration via 3GPP connection, if the new AMF does not release the signaling connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN. In case of registration via non-3GPP connection, if the UE is in CM-CONTENED state on the 3GPP connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN.

[0180] (24) Step 24: AMF can perform information updates on UDM.

[0181] (25) Step 25: The UE may execute a network slice-specific authentication and authorization (NSSAA) procedure.

[0182] Network slice-based communication is being discussed. However, conventional technologies have a problem in that they do not effectively support various types of network slice-based communication, such as allowed Network Slice Selection Assistance Information (NSSAI), partially allowed NSSAI, and on-demand NSSAI.

[0183] For example, when traffic transmission is required, the NAS layer of a terminal (e.g., UE) can exchange information with the upper layers of the terminal (e.g., URSP layer) to determine whether an already connected PDU session can be used for the traffic transmission or whether a new PDU session connection is required. At this time, the URSP (UE Route Selection Policy) layer can utilize the traffic descriptor and route selection descriptor information that it has stored.

[0184] According to the prior art, the URSP layer of the terminal can check network slice information. For example, if a Single-NSSAI (S-NSSAI) matching the traffic to be transmitted exists in the route selection descriptor, and this S-NSSAI exists in the allowed NSSAI, the URSP layer of the terminal can transmit the corresponding S-NSSAI information to the NAS layer.

[0185] Meanwhile, although information for managing other types of network slices, such as partially allowed NSSAI and on-demand NSSAI, as well as allowed NSSAI, has been defined, the prior art has a problem in that it does not consider various types of information, such as partially allowed NSSAI and on-demand NSSAI, at all.

[0186] Since the operation between the URSP layer and the NAS layer according to the conventional technology cannot define accurate URSP-based operation, there is a need for improvement.

[0187] For reference, for prior art not described in the disclosure of this specification, reference may be made to: TS 24.501 V 18.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). TS 24.526 V 18.5.0 (e.g., 4.2.2.2 Association between an application and a PDU session, non-seamless non-3GPP offload or 5G ProSe layer-3 UE-to-network relay offload by a UE).

[0188] To establish a PDU session or request network slice registration, the UE may attempt to find a valid network slice within the route selection descriptor (RSD) specified in the UE route selection policy (URSP). According to TS 24.526 V18.5.0, the URSP layer of the UE may indicate a valid S-NSSAI within the RSD if it is within the allowed NSSAIs stored in the UE.

[0189] For example, the following actions may be performed. For actions not described below, TS 24.526 V18.5.0 S4.2.2.2 may be referenced:

[0190] 1) The UE selects the route selection descriptor with the next lowest priority value that has not yet been evaluated;

[0191] 2) If:

[0192] vi) If the selected path selection descriptor does not contain a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, the URSP handling layer of the UE requests the UE NAS layer to establish a PDU session providing the following PDU session attributes based on the selected path selection descriptor:

[0193] A) SSC mode if the path selection descriptor contains SSC mode;

[0194] B) If the path selection descriptor contains an S-NSSAI and this S-NSSAI is among the allowed NSSAIs, then one S-NSSAI. In addition, if the UE supports LADNs per DNN and S-NSSAI, and the request is a PDU session for a LADN, and extended LADN information is available for that LADN, and the S-NSSAI is associated with that LADN in the service area of ​​that LADN, then one S-NSSAI. If none of the S-NSSAIs in the path selection descriptor is among the allowed NSSAIs, the UE proceeds to step II) 4);

[0195] Meanwhile, 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 user traffic is generated.

[0196] To this end, the network (e.g., AMF) can first transmit an on-demand S-NSSAI list to the UE. For example, the network (e.g., AMF) can transmit the on-demand S-NSSAI list to the UE based on the registration procedure, UE configuration update procedure, etc., such as transmitting rejected NSSAI / allowed NSSAI. For example, the network (e.g., AMF) can transmit a registration acceptance message or a UE configuration update command message including the on-demand S-NSSAI list to the UE. Since the network slice is not registered, the network (e.g., AMF) does not include the on-demand S-NSSAI in the allowed NSSAI, and the network (e.g., AMF) includes the on-demand S-NSSAI in the on-demand NSSAI. After that, when the UE needs to transmit user traffic, the UE can request slice registration during the mobility registration update procedure. Then, if the requested on-demand S-NSSAI is successfully registered and the allowed NSSAI containing the on-demand S-NSSAI is delivered to the UE, the UE can initiate a PDU session establishment request using the S-NSSAI (e.g., the on-demand S-NSSAI). For example, the UE can transmit a PDU session establishment request message containing the S-NSSAI (e.g., the on-demand S-NSSAI).

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

[0198] A path selection descriptor in a URSP rule is considered valid only if it satisfies all of the following conditions:

[0199] 1) If any S-NSSAI(s) is present, the S-NSSAI(s) is in the allowed NSSAI or in the partially allowed NSSAI for the non-roaming case and in the mapping of the allowed NSSAI (or of the Partially allowed NSSAI) to HPLMN S-NSSAI(s) for the roaming case.

[0200] During the validation of the path selection descriptor, none of the conditions in 1) may be met for all the S-NSSAIs in the RSD. In this case, the UE may attempt to meet the conditions by requesting that the S-NSSAI in the RSD be added to the allowed NSSAIs (or (partially) allowed NSSAIs) via the mobility registration update procedure as specified in TS 23.501 V18.4.0 clause 5.15.5.2.2.

[0201] The UE may attempt a Mobility Registration Update for an S-NSSAI only if the S-NSSAI is in the Configured NSSAI or, in the roaming case, in the mapping of the S-NSSAIs of the Configured NSSAIs for the VPLMN to the corresponding S-NSSAI values ​​of the HPLMN, and any other restrictions to prevent triggering a Mobility Registration Update as defined in TS 24.501 V18.5.0. For example, to determine the S-NSSAI to be used for a PDU session, i) If the UE finds a matching HPLMN S-NSSAI within the URSP rules, it can perform the Mobility Registration Update (MRU) procedure by sending a registration request message including this S-NSSAI. ii) If the UE does not find a matching HPLMN S-NSSAI within the URSP rules, it can perform the Mobility Registration Update procedure by sending a registration request message including the HPLMN S-NSSAI within the configured NSSAI.iii) If the HPLMN S-NSSAI is not found in both the URSP rules and 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.

[0202] To properly support behavior like the example above, considering on-demand NSSAI, several issues need to be clarified.

[0203] First, it is unclear whether the network configuration of the URSP for a UE guarantees that all on-demand S-NSSAIs are listed in all RSDs of the URSP. If this is not the case, then when a UE requests one of the S-NSSAIs in an RSD, there is no guarantee that the UE is requesting the on-demand S-NSSAI for registration.

[0204] Therefore, secondly, if we need to check whether the S-NSSAI of the RSD is in the on-demand NSSAI, we need to decide whether to check whether the S-NSSAI of the RSD is in the on-demand NSSAI at the NAS layer, the URSP layer, or at both layers.

[0205] For reference, the UE can receive URSP information as in the example below.

[0206] The UE may receive a message containing URSP information.

[0207] For example, a network (e.g., PCF) may transmit a NAS message containing URSP information to the UE via the AMF. The NAS message may be a DL NAS TRANSPORT message.

[0208] For example, the network may transmit URSP information to the terminal based on a message such as the example of FIG. 7. With respect to the example of FIG. 7, reference may be made to TS 24.501 V18.5.0 Appendix D.

[0209] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0210] Figure 7 is an example of a procedure for a UE to obtain URSP information.

[0211] Figure 7 may be an example of a UE policy management procedure requested by a network. According to the example of Figure 7, the PCF may send a MANAGE UE policy command message to the UE. Upon sending this message, the PCF may start a timer (e.g., a T3501 timer).

[0212] The UE may send a MANAGE UE Policy Complete message or a MANAGE UE Policy Command Reject message to the PCF. In this case, the PCF may stop a timer (e.g., a T3501 timer).

[0213] For example, a message according to the example of FIG. 7 can be delivered to the UE via the NAS Transport procedure. For example, when the PCF sends a MANAGE UE policy command message to the AMF, the AMF can send a NAS message piggybacking the MANAGE UE policy command message to the UE. The payload container type of the NAS message can be set to “UE policy container.”

[0214] Regarding NAS transport procedures, TS 24.501 V18.5.0 S 4.1, S 5.4.5.3 may be referenced.

[0215] For example, according to TS 24.501 V18.5.0 S 4.1, an example of NAS is as follows:

[0216] The non-access stratum (NAS) described in this document forms the highest layer of the control plane between the UE and the AMF for both 3GPP access and non-3GPP access.

[0217] The main features of the protocols that are part of NAS are:

[0218] a) Mobility support for UEs, including generic procedures such as authentication, identification, generic UE configuration update and security mode control procedures;

[0219] b) Support for session management procedures to establish and maintain data connections between the UE and the data network; and

[0220] c) NAS transport procedures for providing transmission of SMS, LPP, SLPP, LCS, UPP-CMI containers, UE policy containers, SOR transparent containers, and UE parameter update information payloads, where the UE policy containers may include URSP information.

[0221] For example, an example of a NAS transport procedure according to TS 24.501 V18.5.0 S5.4.5.3 is as follows.

[0222] The purpose of the network-initiated NAS transfer procedure is to provide the following transfers:

[0223] a) Single 5GSM message;

[0224] b) SMS;

[0225] c) LPP message;

[0226] c1) SLPP message;

[0227] d) SOR transparent container;

[0228] e) Single uplink 5GSM message not delivered due to routing failure;

[0229] f) Single uplink 5GSM message not delivered due to congestion control;

[0230] g) UE policy container;

[0231] h) A single uplink 5GSM message is not delivered because the maximum number of PDU sessions of the PLMN has been reached;

[0232] h1) A single uplink 5GSM message was not delivered because the maximum number of PDU sessions with active user plane resources was reached;

[0233] h2) Single uplink 5GSM message not delivered because network slice-specific authentication and authorization procedures for the requested S-NSSAI are in progress;

[0234] h3) If a single uplink 5GSM message is not delivered, it is because the UE has requested to establish a MA PDU session to the LADN DNN;

[0235] For example, a "UE Policy Container" may be included in a Payload Container IE. The UE Policy Container in the Payload Container IE may be processed in the UE Policy Delivery Procedure specified in Annex D of 3GPP TS 24.501 V18.5.0.

[0236] A UE may include a NAS layer and a URSP layer (or URSP handling layer). These two layers may be physically separate layers and / or logically separate layers within the UE. For example, a processor in the UE may perform operations related to each of the NAS layer and the URSP layer.

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

[0238] For example, see the description related to session management aspects of TS 24.501 V18.5.0 S4.6.3.

[0239] To enable PDU transmission in a network slice, the UE may request establishment of a PDU session for the data network (DN) associated with the S-NSSAI and the data network name (DNN) if no PDU session suitable for PDU transmission in the network slice is established. The S-NSSAI included as part of the allowed NSSAI of the serving PLMN or SNPN is a valid S-NSSAI value in the serving PLMN or SNPN and, in a roaming scenario, is also included for the PDU session if a mapped S-NSSAI is available. For more details, see TS 24.501 V18.5.0 clause 6.4.1. The UE can decide whether to establish a new PDU session or use one of the existing PDU sessions based on the URSP rules including S-NSSAI, if present, or based on UE local configuration, as described in 3GPP TS 24.526 V18.5.0 section 4.2.2.

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

[0241] 5GSM entities interact with higher layers. TS 24.501 V18.5.0 Section 6.2.9.2 describes how 5GSM entities interact with higher layers in relation to URSP. TS 24.501 V18.5.0 Section 6.2.9.3 describes how 5GSM entities interact with higher layers in relation to ProSeP.

[0242] URSP requires interaction between upper layers (e.g., application layer) and 5GSM entities. 3GPP TS 24.526 V18.5.0 can be referenced. Each 5GSM entity in the UE can display the attributes of a newly established PDU session (e.g., PDU session ID, SSC mode, S-NSSAI, DNN, PDU session type, access type, PDU address) to upper layers. When a PDU session is released, the 5GSM entity handling the PDU session can notify the upper layers of the PDU session ID of the released PDU session. The upper layers can request the 5GSM entity:

[0243] a) may request the establishment of a PDU session indicating one or more PDU session attributes;

[0244] b) may request that an existing PDU session be released; or

[0245] c) It may establish a PDU session indicating one or more PDU session attributes and request that an existing PDU session be released.

[0246] Referring to TS 24.501 V18.5.0 6.4.1.2, an example of initiating a PDU session establishment procedure requested by a UE is described.

[0247] When a UE requests to establish a new non-emergency PDU session via a DN, the UE may include a PDU Session Type IE in the PDU Session Establishment Request message. Based on the URSP rules, the UE local configuration, and / or the IP version capabilities specified in TS 24.501 V18.5.0 clause 6.2.4.2, the UE may set the PDU Session Type IE to one of the following values: "IPv4", "IPv6", "IPv4v6", "Ethernet" or "Atypical".

[0248] The UE can transmit:

[0249] a) PDU Session Establishment Request message;

[0250] b) PDU Session ID of the PDU session that is being established, forwarded, transmitted, or established as an MA PDU session;

[0251] c) If the request type is set as follows, the UE can transmit the request type:

[0252] 1) If the UE decides to establish a new PDU session or MA PDU session based on a URSP rule or UE local configuration that includes one or more S-NSSAIs in the URSP, the UE may transmit an "Initial Request" or a "MA PDU Request":

[0253] i) If the UE is in the HPLMN or a subscribed SNPN, the S-NSSAI of the allowed NSSAI corresponding to one of the S-NSSAIs of the matching URSP rule (if any), or the S-NSSAI corresponding to an S-NSSAI in the UE local configuration, or the S-NSSAI of the allowed NSSAI corresponding to one of the S-NSSAIs of the default URSP rule as given in clause 4.2.2 of 3GPP TS 24.526 V18.5.0.

[0254] ii) If the UE is in a non-subscribed SNPN, the UE decides to establish a new PDU session or MA PDU session based on a URSP rule containing one or more S-NSSAIs as per the conditions presented in clause 4.2.2 of 3GPP TS 24.526 V18.5.0. The URSP rule may be part of a URSP signaled by the non-subscribed SNPN.

[0255] According to various examples of the disclosure of this specification, various examples are proposed for implementing a mechanism for processing network slice information in a requested NSSAI during a mobility registration update (MRU) procedure for network slice registration.

[0256] For reference, conventionally, the URSP layer has an interface with a 5GSM entity. However, according to one embodiment of the disclosure of the present specification, the URSP layer may have an interface with a 5GMM entity as well as an interface with a 5GSM entity.

[0257] According to the first example (e.g., the first example of terminal operation referring to FIG. 8), the URSP layer can check the on-demand NSSAI for network slice validation in the route selection descriptor (RSD).

[0258] According to the second example (e.g., the second example of the terminal operation referring to FIG. 9), even if the S-NSSAI is not included in the (partially) allowed NSSAI, the URSP layer can indicate the S-NSSAI in the RSD, and the NAS layer can decide whether to request the on-demand S-NSSAI or the network slice of the configured NSSAI.

[0259] A third solution (e.g., the third example of the operation of the terminal referring to FIG. 10) is that the URSP layer can indicate S-NSSAI in the RSD if the UE supports a specific feature.

[0260] Referring to Figure 8, a first example of terminal operation is described. For example, the URSP layer can check on-demand NSSAI. The first example of terminal operation can affect the operation of the URSP layer.

[0261] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0262] FIG. 8 is a first example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0263] For reference, the operation performed in FIG. 8 may be performed by the URSP layer (or URSP handling layer) of the UE.

[0264] In step (S801), the UE can determine a traffic descriptor.

[0265] For example, a URSP rule may contain a single Traffic descriptor and multiple Route selection descriptor (RSD) lists.

[0266] For example, in step (S801), the UE may find a traffic descriptor matching the application information within a non-default URSP rule. The UE may evaluate the URSP rules that include the traffic descriptor matching the application information.

[0267] In step (S802), the UE can check the RSD.

[0268] For example, the UE can sequentially check the RSD list of URSP rules that contain traffic descriptors matching the application information. For example, the UE can check the RSD based on the priority of the RSD list and determine the S-NSSAI within the RSD.

[0269] In step (S803), the UE may determine whether the S-NSSAI(s) in the RSD are within the (partially) allowed NSSAI.

[0270] In step (S804), the UE may determine whether the S-NSSAI(s) in the RSD are in the on-demand NSSAI.

[0271] Note that in the example of FIG. 8, steps (S803) and (S804) are depicted as separate operations, but this is merely an example. For example, the UE could determine whether the S-NSSAI(s) within the RSD are (partially) within the allowed NSSAI or on-demand NSSAI, without going through the two steps.

[0272] For reference, in step (S804), if the S-NSSAI(s) in the RSD are not in the on-demand NSSAI, the following operations may be performed. For example, to determine the S-NSSAI to be used for the PDU session, i) if the UE finds an S-NSSAI in the URSP rules that matches an S-NSSAI existing in the partially (allowed) NSSAI or the on-demand NSSAI, the UE may perform a Mobility Registration Update procedure by transmitting a Registration Request message including this S-NSSAI. ii) if the UE does not find an S-NSSAI in the URSP rules that matches an S-NSSAI existing in the partially (allowed) NSSAI or the on-demand NSSAI, the UE may perform a Mobility Registration Update procedure by transmitting a Registration Request message including an HPLMN S-NSSAI in the configured NSSAI. iii) If the UE does not find an S-NSSAI matching an S-NSSAI existing in the partially (allowed) NSSAI or on-demand NSSAI in the URSP rules or does not find an HPLMN S-NSSAI in the configured NSSAI, the UE may transmit a PDU session establishment request message that does not include S-NSSAI information without triggering the MRU procedure.

[0273] In step (S805), the UE may indicate the S-NSSAI(s) to the NAS layer. For example, the URSP layer of the UE may indicate the S-NSSAI(s) to the NAS layer. Note that in the disclosure of this specification, "indicate" may mean "indicate." Furthermore, "indicate" may also mean "provide," "transmit," and "announce."

[0274] Referring to Fig. 9, a second example of terminal operation is described.

[0275] For example, the URSP layer may indicate S-NSSAI within the RSD if an RSD exists for the traffic descriptor.

[0276] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0277] FIG. 9 is a second example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0278] In step (S901), the UE can determine a Traffic Descriptor.

[0279] In step (S902), the UE can check the RSD.

[0280] In step (S903), the UE can determine whether the S-NSSAI(s) is within the RSD.

[0281] In step (S904), the UE may indicate a failure. For example, the URSP layer of the UE may indicate a failure to a higher 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.).

[0282] In step (S905), the UE may indicate S-NSSAI(s) to the NAS layer.

[0283] When step (S905) is performed, 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 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.

[0284] In step (S905), the URSP layer can announce 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 by comparing it with the S-NSSAI indicated by the URSP layer. If not, the NAS layer can register the S-NSSAI by triggering a mobility registration update procedure that includes the S-NSSAI in the requested NSSAI.

[0285] For reference, the operations included in the example of FIG. 9 may be performed by the URSP layer of the UE.

[0286] Referring to Fig. 10, a third example of terminal operation is described.

[0287] For example, the URSP layer may indicate S-NSSAI within the RSD only if the UE supports certain capabilities, such as network slice usage control.

[0288] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0289] FIG. 10 is a third example of the operation of a terminal according to one embodiment of the disclosure of the present specification.

[0290] In step (S1001), the UE can determine a Traffic Descriptor.

[0291] In step (S1002), the UE can check the RSD.

[0292] In step (S1003), the UE may determine whether the S-NSSAI(s) in the RSD are within the (partially) allowed NSSAI.

[0293] In step (S1004), if the UE supports a specific feature (e.g., network slice usage control), the URSP layer of the UE may indicate the S-NSSAI(s) in the RSD to the NAS layer.

[0294] In step (S1005), the UE may indicate S-NSSAI(s) to the NAS layer.

[0295] For reference, the operations included in the example of FIG. 10 may be performed by the URSP layer of the UE.

[0296] According to the first example of the operation referring to Figure 8, the main impact may only be on the URSP operation. For example, the URSP layer of the UE may additionally indicate a valid on-demand S-NSSAI within the RSD to the NAS layer. The NAS layer may perform legacy operations.

[0297] According to a second example of the operation referring to FIG. 9, the URSP may no longer check the list of network slices stored in the UE, such as (partially) allowed NSSAIs. If an S-NSSAI for a specific traffic descriptor is found, the URSP may notify the NAS layer of this. Then, the NAS layer may determine which S-NSSAI to include in the requested NSSAI of the registration update request message among the configured NSSAIs, considering (partially) allowed NSSAIs or on-demand NSSAIs. If the RSD condition of the S-NSSAI is not met and the requested NSSAI includes the S-NSSAI during the MRU procedure, the URSP operation according to the example of FIG. 9 may be applied.

[0298] According to the third example of the operation referring to FIG. 10, the URSP layer may indicate the S-NSSAI from the RSD to the NAS layer only if the UE supports a specific feature, such as network slice usage control. New S-NSSAI information (e.g., if the S-NSSAI in the RSD is not included in the (partially) allowed NSSAI) may be required for UEs supporting specific features (e.g., network slice usage control).

[0299] Hereinafter, examples based on a first example of the operation of a terminal according to an embodiment of the disclosure of the present specification will be described. Note that the specific operations of the first example of the operation of a terminal according to an embodiment of the disclosure of the present specification, as described in FIG. 8, are merely exemplary. For example, the operations of FIG. 8 may not be performed in the order described in FIG. 8, some of the operations of FIG. 8 may be omitted, or operations according to the contents described below may be performed.

[0300] A first example based on the first example of terminal operation is described.

[0301] For example, for S4.2.2.2 of 3GPP TS 24.526 V18.5.0 (e.g., connection between application and PDU session, non-seamless non-3GPP offload or 5G ProSe Layer 3 UE-to-network relay offload by UE), the following may apply. The following mainly describes the contents proposed in the disclosure of this specification, and for omitted contents, S4.2.2.2 of 3GPP TS 24.526 V18.5.0 may be referenced.

[0302] In order to transmit an application's PDU or PIN, a higher layer (e.g., the application layer or a layer higher than the application layer, such as a layer between the URSP layer and the application layer) may need information about the PDU session over which the application's PDU or PIN will be transmitted (e.g., a PDU address).

[0303] When a higher layer (e.g., the application layer or a layer higher than the application layer, such as a layer between the URSP layer and the application layer) requests PDU session information to transmit the application's PDU;

[0304] - If non-seamless non-3GPP offload is requested due to UE local configuration, the URSP layer may provide information about non-3GPP access outside the PDU session to upper layers without evaluating the URSP rules; or

[0305] - When 5G ProSe Layer 3 UE-to-network relay offload is requested due to UE local configuration, the URSP layer may provide information about 5G ProSe Layer 3 UE-to-network relay to upper layers without evaluating URSP rules;

[0306] Otherwise, the UE may perform the following steps:

[0307] a) The UE shall evaluate URSP rules, excluding the default URSP rule, in the order of highest priority if there is a traffic descriptor that matches the application information or PIN information. If the traffic descriptor contains two or more traffic descriptor component types, each of which is of a different type, all types shall match. If the traffic descriptor contains two or more traffic descriptor components of the same traffic descriptor component type, at least one traffic descriptor component of the same traffic descriptor component type shall match the application information. If there is no information corresponding to the application information or PIN for a particular component of the traffic descriptor, or if the information corresponding to the application information or PIN does not match any of the values ​​of the traffic descriptor components specified in clause 6.6.2.1 of 3GPP TS 23.503 V18.4.0, it is determined that the URSP rule does not apply.

[0308] If the UE finds a traffic descriptor in a non-default URSP rule that matches the application information or PIN information, the following explanation may apply:

[0309] I) If a connection to a non-3GPP access is established, or a connection to a 5G ProSe Layer 3 UE-Network Relay UE is established, or there are one or more established PDU sessions, or a combination thereof, the UE shall evaluate the route selection descriptors of the URSP rules in the following order: The description of conditions 1), 1a), 1b), and 2) is omitted, and S4.2.2.2 of 3GPP TS 24.526 V18.5.0 is referenced.

[0310] II) Otherwise, the following explanation may apply:

[0311] 1) The UE may select the path selection descriptor with the next lowest priority value that has not yet been evaluated;

[0312] 2) If:

[0313] Description of conditions i), ia), ib), ii), iii), iv), v), va) is omitted and reference is made to S4.2.2.2 of 3GPP TS 24.526 V18.5.0;

[0314] vi) If the selected path selection descriptor does not contain a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, the URSP handling layer of the UE requests the UE NAS layer to establish a PDU session providing the following PDU session attributes based on the selected path selection descriptor:

[0315] A) SSC mode if the path selection descriptor contains SSC mode;

[0316] B) If the path selection descriptor contains an S-NSSAI, and this S-NSSAI is in the allowed NSSAIs or on-demand NSSAIs (e.g., if on-demand NSSAIs are available), then one S-NSSAI. For example, in this case, the URSP layer (e.g., the URSP processing layer) of the UE may request the UE NAS layer to establish a PDU session based on this S-NSSAI. Furthermore, if the UE supports LADNs per DNN and S-NSSAI, the request of the URSP layer is for a PDU session for a LADN, and the extended LADN information is available for that LADN and the S-NSSAI may be associated with that LADN in the service area of ​​that LADN. If the S-NSSAI(s) in the path selection descriptor are not in the allowed NSSAIs or on-demand NSSAIs (e.g., if on-demand NSSAIs are available), the UE may proceed to step II) 4);

[0317] C) One DNN if the DNN is in the path selection descriptor; and one DNN if the DNN is a LADN DNN and the UE is in the service area of ​​that LADN;

[0318] D) PDU session type of the path selection descriptor;

[0319] E) If the preferred access type or multiple access default setting is in the path selection descriptor, the preferred access type or multiple access default setting;

[0320] F) PDU session pair ID if the path selection descriptor contains a PDU session pair ID; and

[0321] G) RSN if the path selection descriptor contains an RSN.

[0322] The UE NAS layer can indicate the PDU session establishment result to the URSP layer (e.g., the URSP processing layer). If the PDU session establishment is successfully completed, the UE NAS layer can additionally indicate the properties 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 of the successfully established PDU session (e.g., PDU address) to a higher 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.).

[0323] The UE may stop selecting a path selection descriptor that matches the application information or PIN information. If the PDU session establishment fails, the UE proceeds to steps 2) and 3);

[0324] 3) If there are other values ​​available for the rejected component in the same path selection descriptor based on the rejection reason, the UE may use these values ​​of the rejected component to select another combination of values ​​of the currently selected path selection descriptor and proceed to step II) 2). Otherwise, the UE may proceed to step II) 4); and

[0325] 4) If there are still unevaluated path selection descriptors, the UE proceeds to step II) 1). If all path selection descriptors for matching non-default URSP rules have been evaluated and there are at least one non-default matching URSP rule that has 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 the failure.

[0326] b) If a matching non-default URSP rule is not found and the UE local configuration for the application or PIN is available, the UE may associate the application or PIN to a PDU session as appropriate. If a matching PDU session does not exist, the UE NAS layer attempts to establish a PDU session using the UE local configuration; and

[0327] If the PDU session establishment is successful, the UE NAS layer can provide information about the successfully established PDU session (e.g., PDU address) to the upper layer. Otherwise, the UE performs step c);

[0328] c) If no matching non-default URSP rule is found and the UE local configuration for the application is not available, or PDU session establishment based on the UE local configuration for the application may fail, the UE may associate the application to a PDU session, non-seamless non-3GPP offload, or 5G ProSe Layer-3 UE-to-network relay offload, based on the default URSP rule if the "match-all" traffic descriptor is present. If the association fails, the UE notifies the upper layer of the failure.

[0329] The HPLMN may pre-configure the UE with a URSP in the ME or USIM. A subscribed SNPN may pre-configure the UE with a URSP from a corresponding entry in the "list of subscriber data" stored in the ME. The HPLMN or a subscribed SNPN may pre-configure a URSP in the ME for an unsubscribed SNPN and associate the URSP with an entry of the subscribed SNPN in the "list of subscriber data", or associate the URSP with a corresponding PLMN subscription of the HPLMN. As described in Annex D of 3GPP TS 24.501 V18.5.0, the HPLMN, the subscribed SNPN and / or the unsubscribed SNPN may provide the URSP to the UE via signaling. For example, the PCF of the HPLMN, the subscribed SNPN and / or the unsubscribed SNPN may send a UE policy container containing the URSP to the UE.

[0330] If a UE registered to a subscribed SNPN or PLMN has both a pre-configured URSP and a signaled URSP, the UE can use only the signaled URSP.

[0331] A second example based on the first example of terminal operation is described.

[0332] For example, for S4.2.2.2 of 3GPP TS 24.526 V18.5.0 (e.g., connection between application and PDU session, non-seamless non-3GPP offload or 5G ProSe Layer 3 UE-to-network relay offload by UE), the following may apply. The following mainly describes the contents proposed in the disclosure of this specification, and for omitted contents, S4.2.2.2 of 3GPP TS 24.526 V18.5.0 may be referenced.

[0333] Conventionally, a path selection descriptor in a URSP rule is considered valid only if it satisfies all of the following conditions:

[0334] 1) If there is an S-NSSAI, in case of non-roaming, the S-NSSAI is in the allowed NSSAI or (partially) allowed NSSAI, and in case of roaming, it is in the mapping of the allowed NSSAI (or (partially) allowed NSSAI) and the HPLMN S-NSSAI.

[0335] During the validation of the path selection descriptor, none of the conditions 1) may be satisfied for all the S-NSSAIs in the RSD. In this case, the UE attempts to satisfy the conditions by requesting that the S-NSSAI in the RSD be added to the allowed NSSAIs (or (partially) allowed NSSAIs) via the mobility registration update procedure as specified in TS 23.501 V18.4.05.15.5.2.2.

[0336] The conventional condition 1) has a problem in that it does not consider on-demand NSSAI at all.

[0337] According to one embodiment of the disclosure of the present specification, only when the UE supports network slice usage control and the S-NSSAI of the RSD is in the on-demand NSSAI, the URSP processing layer indicates the S-NSSAI to the NAS layer, so that the NAS layer can perform the MRU procedure using the S-NSSAI of the RSD.

[0338] On the other hand, according to the prior art, the NAS layer may not be able to trigger the MRU procedure using the S-NSSAI of the RSD. For example, S-NSSAI#1 included in the on-demand NSSAI may also be present in the RSD. In this case, S-NSSAI#1 does not exist in the (partially) allowed NSSAI until the slice is registered with the MRU. According to the prior art, since the URSP layer does not include S-NSSAI#1 in the allowed NSSAI, it cannot notify the NAS layer of the S-NSSAI#1 in the RSD after checking the URSP rules. Then, the NAS layer transmits the HPLMN S-NSSAI included in the configured NSSAI based on the local configuration, or directly transmits a PDU session without slice information without an MRU. Then, the network may assign an S-NSSAI that is not included in the URSP rule of the terminal to the corresponding PDU session, and in some cases, PDU session re-establishment may occur after the PDU session establishment.

[0339] In order to transmit an application's PDU or PIN, a higher layer (e.g., the application layer or a layer higher than the application layer, such as a layer between the URSP layer and the application layer) may need information about the PDU session over which the application's PDU or PIN will be transmitted (e.g., a PDU address).

[0340] When a higher layer (e.g., the application layer or a layer higher than the application layer, such as a layer between the URSP layer and the application layer) requests PDU session information to transmit the application's PDU;

[0341] - If non-seamless non-3GPP offload is requested due to UE local configuration, the URSP layer may provide information about non-3GPP access outside the PDU session to upper layers without evaluating the URSP rules; or

[0342] - When 5G ProSe Layer 3 UE-to-network relay offload is requested due to UE local configuration, the URSP layer may provide information about 5G ProSe Layer 3 UE-to-network relay to upper layers without evaluating URSP rules;

[0343] Otherwise, the UE may perform the following steps:

[0344] a) The UE shall evaluate URSP rules, excluding the default URSP rule, in the order of highest priority if there is a traffic descriptor that matches the application information or PIN information. If the traffic descriptor contains two or more traffic descriptor component types, each of which is of a different type, all types shall match. If the traffic descriptor contains two or more traffic descriptor components of the same traffic descriptor component type, at least one traffic descriptor component of the same traffic descriptor component type shall match the application information. If there is no information corresponding to the application information or PIN for a particular component of the traffic descriptor, or if the information corresponding to the application information or PIN does not match any of the values ​​of the traffic descriptor components specified in clause 6.6.2.1 of 3GPP TS 23.503 V18.4.0, it is determined that the URSP rule does not apply.

[0345] If the UE finds a traffic descriptor in a non-default URSP rule that matches the application information or PIN information, the following explanations may apply:

[0346] I) If a connection to a non-3GPP access is established, or a connection to a 5G ProSe Layer 3 UE-Network Relay UE is established, or there are one or more established PDU sessions, or a combination thereof, the UE shall evaluate the route selection descriptors of the URSP rules in the following order: The description of conditions 1), 1a), 1b), and 2) is omitted, and S4.2.2.2 of 3GPP TS 24.526 V18.5.0 is referenced.

[0347] II) Otherwise, the following explanation may apply:

[0348] 1) The UE may select the path selection descriptor with the next lowest priority value that has not yet been evaluated;

[0349] 2) If:

[0350] Description of conditions i), ia), ib), ii), iii), iv), v), va) is omitted and reference is made to S4.2.2.2 of 3GPP TS 24.526 V18.5.0;

[0351] vi) If the selected path selection descriptor does not contain a non-seamless non-3GPP offload indication or a 5G ProSe Layer 3 UE-to-network relay offload indication, the URSP handling layer of the UE requests the UE NAS layer to establish a PDU session providing the following PDU session attributes based on the selected path selection descriptor:

[0352] A) SSC mode if the path selection descriptor contains SSC mode;

[0353] B) If the path selection descriptor contains an S-NSSAI, and this S-NSSAI is in the allowed NSSAIs or on-demand NSSAIs (e.g., if on-demand NSSAIs are available), then one S-NSSAI. For example, in this case, the URSP layer (e.g., the URSP processing layer) of the UE may request the UE NAS layer to establish a PDU session based on this S-NSSAI. Furthermore, if the UE supports LADNs per DNN and S-NSSAI, the request of the URSP layer is for a PDU session for a LADN, and the extended LADN information is available for that LADN and the S-NSSAI may be associated with that LADN in the service area of ​​that LADN. If the S-NSSAI(s) in the path selection descriptor are not in the allowed NSSAIs or on-demand NSSAIs (e.g., if on-demand NSSAIs are available), the UE may proceed to step II) 4);

[0354] B) If the path selection descriptor contains an S-NSSAI, and this S-NSSAI is among the allowed NSSAIs, then one S-NSSAI. For example, in this case, the URSP layer of the UE (e.g., the URSP processing layer) may request the UE NAS layer to establish a PDU session based on this S-NSSAI. In addition, if the UE supports LADN per DNN and S-NSSAI, the request of the URSP layer is for a PDU session for the LADN, and the extended LADN information is available for that LADN, and the S-NSSAI may be associated with that LADN in the service area of ​​that LADN. If none of the S-NSSAIs in the path selection descriptor is included in the allowed NSSAI, but there is an S-NSSAI included in the on-demand NSSAI among the S-NSSAIs in the path selection descriptor, the URSP processing layer may provide one on-demand S-NSSAI to the UE NAS layer before requesting the UE NAS layer to establish a PDU session. If there is no S-NSSAI in the allowed NSSAI, (partially) allowed NSSAI or on-demand NSSAI among the S-NSSAIs in the path selection descriptor, the UE proceeds to step II) 4);

[0355] NOTE: The UE NAS layer may include on-demand S-NSSAI in the requested NSSAI during the registration procedure. 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.

[0356] The description below B) and NOTE is the same as the first example based on the first example of the operation of the terminal.

[0357] A third example based on the first example of terminal operation is described.

[0358] For example, for 3GPP TS 24.501 V18.5.0, the following may apply. The following description focuses on the contents proposed in the disclosure of this specification, and 3GPP TS 24.501 V18.5.0 (e.g., S4.6.2.9, S5.5.1.3.2) may be referenced for omitted contents.

[0359] Conventionally, a path selection descriptor in a URSP rule is considered valid only if it satisfies all of the following conditions:

[0360] 1) If there is an S-NSSAI, in case of non-roaming, the S-NSSAI is in the allowed NSSAI or (partially) allowed NSSAI, and in case of roaming, it is in the mapping of the allowed NSSAI (or (partially) allowed NSSAI) and the HPLMN S-NSSAI.

[0361] During the validation of the path selection descriptor, none of the conditions 1) may be satisfied for all the S-NSSAIs in the RSD. In this case, the UE attempts to satisfy the conditions by requesting that the S-NSSAI in the RSD be added to the allowed NSSAIs (or (partially) allowed NSSAIs) via the mobility registration update procedure as specified in TS 23.501 V18.4.0 clause 5.15.5.2.2.

[0362] The UE must request the S-NSSAI in the RSD via the MRU procedure to add the S-NSSAI to the (partially) allowed NSSAI.

[0363] According to a third example based on the first example of the operation of the terminal, it is possible to clarify how the UE requests on-demand S-NSSAI during the registration procedure, so that the UE can attempt to request S-NSSAI in the RSD (e.g., if S-NSSAI in the RSD is available).

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

[0365] An example of mobility management-based network slice usage control is described according to the third example based on the first example of terminal operation. For any omitted portions in the following description, reference may be made to 3GPP TS 24.501 V18.5.0 S4.6.2.9.

[0366] If the UE and the network support network slice usage control, the AMF can monitor network slice usage by starting a slice deregistration inactivity timer based on the S-NSSAI and connection type. The AMF can also provide the UE with an on-demand NSSAI within a registration accept message or a configuration update command message. An on-demand NSSAI consists of one or more on-demand S-NSSAIs and optionally a slice deregistration inactivity timer per on-demand S-NSSAI.

[0367] The slice deregistration inactivity timer can operate based on:

[0368] a) The slice deregistration inactivity timer starts when there are no established PDU sessions, including MA PDU sessions associated with S-NSSAI for the given access type.

[0369] b) When one or more PDU sessions, including MA PDU sessions associated with an S-NSSAI for the given access type, are successfully established or the S-NSSAI is removed from the allowed NSSAIs, the slice deregistration inactivity timer is stopped and reset.

[0370] When the slice deregistration inactivity timer value is updated, the AMF may 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.

[0371] When the UE receives an updated slice deregistration inactivity timer value from the AMF in a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message, the UE updates the stored timer value.

[0372] When the slice deregistration inactivity timer expires, AMF locally removes the S-NSSAI from the allowed NSSAI for that access type. AMF may also send a configuration update command message to the UE using the newly allowed NSSAI.

[0373] The UE may include the requested on-demand S-NSSAI in the requested NSSAI during the registration procedure. When the slice deregistration inactivity timer expires, the UE locally removes the S-NSSAI from the allowed NSSAI for the access type.

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

[0375] If the UE supports network slice usage control, the AMF provides the UE with an on-demand NSSAI of the configured NSSAI in the Registration Accept message or the UE Configuration Update Command message. The on-demand NSSAI consists of one or more configured S-NSSAIs.

[0376] The on-demand S-NSSAI is deleted from the stored configured NSSAI by the UE when the configured S-NSSAI linked to the stored on-demand NSSAI is deleted by the UE.

[0377] An example of initiating mobility and periodic registration updates is described according to the third example, based on the first example of terminal operation. For omitted information, reference may be made to 3GPP TS 24.501 V18.5.0 S5.5.1.3.2.

[0378] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0379] FIG. 11 is an example of a registration procedure according to one embodiment of the disclosure of the present specification.

[0380] The example in FIG. 11 illustrates an example of a registration procedure for mobility registration update and / or periodic registration update.

[0381] For example, according to the example of FIG. 11, the UE may send a registration request message to the AMF. The UE may start a timer (e.g., T3510). The AMF may send a registration acceptance message to the UE. The UE may stop the timer (e.g., T3510).

[0382] As another example, according to the example of FIG. 11, the UE may send a registration request message to the AMF. The UE may start a timer (e.g., T3510). The AMF may send a registration acceptance message to the UE. The AMF may start a timer (e.g., T3550). The UE may stop the timer (e.g., T3510). The UE may send a registration complete message to the AMF. The AMF may stop the timer (e.g., T3550).

[0383] As another example, according to the example of FIG. 11, the UE may send a registration request message to the AMF. The UE may start a timer (e.g., T3510). The AMF may send a registration rejection message to the UE. The UE may stop the timer (e.g., T3510).

[0384] A UE in 5GMM-registered state initiates the registration procedure for mobility and periodic registration update by sending a registration request message to the AMF. The description of conditions a) to zq) of 3GPP TS 24.501 V18.5.0 S5.5.1.3.2 is omitted.

[0385] For example, the UE may send a registration request message to the AMF with a 5GS registration type IE indicating "mobility registration updating".

[0386] The UE may include in the registration request message a requested NSSAI IE containing the mapped S-NSSAI (if available) associated with the S-NSSAI corresponding to the network slice for which it wishes to register.

[0387] If the UE determines on-demand S-NSSAI for PDU session establishment, the UE may include the on-demand S-NSSAI in the requested NSSAI during the registration procedure. For example, the UE may determine on-demand S-NSSAI for PDU session establishment as specified in various examples of the disclosure herein and / or in section 4.2.2 of 3GPP TS 24.526 V18.5.0.

[0388] For reference, with respect to the second example of the terminal operation according to the example of FIG. 9, the following explanation may also be applied to TS24.526 V18.5.0 S4.2.2.3.

[0389] For conditions a), I), and B) of TS24.526 V18.5.0 S4.2.2.3, the following description applies: B) One S-NSSAI if the S-NSSAI is in the path selection descriptor; and one S-NSSAI if the S-NSSAI is in the allowed NSSAI or (partially) allowed NSSAI. In addition, if the UE supports LADN per DNN and S-NSSAI, the request is a PDU session for a LADN, extended LADN information is available for that LADN, and the S-NSSAI is associated with that LADN in the service area of ​​that LADN. If none of the S-NSSAIs in the path selection descriptor is in the allowed NSSAI or (partially) allowed NSSAI, the 5G-RG or W-AGF replacing the FN-RG proceeds to step 4);

[0390] NOTE 5: During validation of the path selection descriptor, for any S-NSSAI in the RSD, if the S-NSSAI is not in the allowed NSSAI or (partially) allowed NSSAIs in case of non-roaming, or if the S-NSSAI is not mapped to an HPLMN S-NSSAI (or (partially) allowed NSSAI), the UE may attempt to add the S-NSSAI to the allowed NSSAI (or (partially) allowed NSSAI) by requesting the S-NSSAI in the RSD via the 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 a mobility registration update for an S-NSSAI, the following conditions must be met: for non-roaming, the S-NSSAI is included in the configured NSSAI; for roaming, the S-NSSAI is included in the mapped HPLMN S-NSSAI for the VPLMN, which is included in the configured NSSAI; and other restrictions to prevent triggering a mobility registration update as defined in TS 24.501.

[0391] Note that in various examples of the disclosure herein, the term "indicates" may also mean transmitting information related to the object being indicated. For example, the expression "the URSP layer indicates A to the NAS layer" may mean that the URSP layer transmits information related to A to the NAS layer.

[0392] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0393] FIG. 12 illustrates an example of operations according to one embodiment of the disclosure of the present specification.

[0394] For reference, the procedure illustrated in FIG. 12 is merely an example, and the scope of the disclosure of this specification is not limited by the example in FIG. 12.

[0395] For example, with respect to the example of FIG. 12, the operations described in the examples of FIGS. 1 to 11 may also be applied. For example, even if operations, contents, etc. are not directly described in the example of FIG. 12, operations, contents, etc. described in various examples of the disclosure of this specification may be applied.

[0396] In the example of FIG. 12, the first network entity may be a network entity related to mobility. For example, the first network entity may be an AMF.

[0397] Before step (S1201) is performed, the UE can acquire URSP rules.

[0398] For example, a UE may receive a message containing a URSP rule. The URSP rule may contain an RSD.

[0399] For example, a first network entity may 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 contain URSP rules. The first network entity may send an NAS message containing the UE policy container to the UE.

[0400] For another example, URSP rules may be preset in the UE.

[0401] At step (S1201), the UE can receive a message from a first network entity.

[0402] For example, the message may contain information related to on-demand NSSAI. This message may be transmitted to the UE during an initial registration procedure, an MRU, a periodic registration procedure, and / or a UE configuration update procedure.

[0403] In step (S1202), the UE may transmit a registration request message.

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

[0405] For example, the registration request message including the requested NSSAI may be a request message for a mobility registration update procedure.

[0406] For example, based on the Route Selection Descriptor (RSD) included in the URSP rule including the first S-NSSAI and the first S-NSSAI being the on-demand NSSAI, the on-demand NSSAI may be included in the requested NSSAI.

[0407] For example, based on the first S-NSSAI being included in the RSD and the first S-NSSAI being the on-demand NSSAI, the first S-NSSAI may be provided to the NAS layer of the UE by the URSP layer of the UE.

[0408] For example, the first S-NSSAI may be provided to a mobility management entity of the NAS layer of the device.

[0409] For example, the UE may determine on-demand NSSAI for PDU session establishment.

[0410] For example, based on the on-demand S-NSSAI determined for PDU session establishment, the on-demand S-NSSAI may be included in the requested NSSAI.

[0411] For example, the URSP processing layer of the UE may request the UE NAS layer to establish a PDU session. For example, the URSP processing layer of the UE may provide PDU session attributes to the UE NAS layer based on the RSD.

[0412] For example, the RSRP processing layer of the UE may provide one S-NSSAI to the NAS layer of the UE. For example, if the S-NSSAI is included in the RSD and the S-NSSAI is included in the allowed NSSAI or (partially) allowed NSSAI, the RSRP processing layer of the UE may provide one S-NSSAI to the NAS layer of the UE.

[0413] For example, if there is no S-NSSAI included in the allowed NSSAI or (partially) allowed NSSAI in the RSD, but the S-NSSAI in the RSD is an on-demand NSSAI, the URSP processing layer may provide the on-demand S-NSSAI to the UE NAS layer. For example, the URSP processing layer may provide the on-demand S-NSSAI to the UE NAS layer before requesting the UE NAS layer to establish a PDU session.

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

[0415] For example, if the UE determines on-demand S-NSSAI for PDU session establishment, the UE may include the on-demand S-NSSAI in the requested NSSAI.

[0416] According to one embodiment of the disclosure of the present specification, the NAS layer of the UE can receive on-demand NSSAI. The upper layer can generate user traffic. The URSP layer can perform URSP application for server traffic. The URSP layer can indicate the S-NSSAI to the NAS layer if the S-NSSAI found in the path selection descriptor is in the on-demand NSSAI. 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 accept message including the allowed NSSAI.

[0417] According to one embodiment of the disclosure of the present specification, an upper layer may require information about a PDU session. The URSP layer may evaluate URSP rules and provide the NAS layer with the S-NSSAI in the path selection descriptor and the on-demand NSSAI. The NAS layer may perform a registration update procedure by including the S-NSSAI provided by the URSP layer in the requested NSSAI.

[0418] According to one embodiment of the disclosure of the present specification, when the URSP layer of a terminal checks the S-NSSAI in the route selection descriptor information, it can check not only the (partially) allowed NSSAI but also the S-NSSAI in the on-demand NSSAI list. If there is a matching S-NSSAI, the URSP layer of the terminal notifies the NAS layer of this, and the NAS layer can include the S-NSSAI in the requested NSSAI information and perform a registration update procedure.

[0419] For reference, according to the prior art, 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 one embodiment of the disclosure of the present specification, the URSP layer can transmit information required for performing a NAS Mobility management procedure (e.g., a Registration update for network slice registration) to the NAS layer.

[0420] This specification may have various effects.

[0421] For example, communication based on network slices can be effectively supported.

[0422] For example, based on network slice-based information, a terminal can register for an accurate network slice and / or request the use of an accurate network slice. Accordingly, policy-based traffic handling expected by the network can be implemented. In addition, by requesting a network slice that has been confirmed by the network to be available in the relevant area, a registration rejection can be prevented. In addition, by requesting a network slice that has been confirmed by the network to be available in the relevant area, additional network operations (e.g., URSP update) to find a network slice matching the traffic and establish a PDU session can be prevented.

[0423] The effects that can be achieved through the specific examples of this specification are not limited to the effects listed above. For example, a person with ordinary skill in the relevant technical field may understand or derive various technical effects from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of this specification.

[0424] For reference, the operation of the terminal (e.g., UE) described in this specification may be implemented by the devices of FIGS. 1 to 3 described above. For example, the terminal may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the terminal described in this specification may be processed by one or more processors (102 or 202). The operation of the terminal described in this specification may be stored in one or more memories (104 or 204) in the form of instructions / programs (e.g., instructions, executable codes) executable by one or more processors (102 or 202). The one or more processors (102 or 202) may 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 the disclosure of this specification.

[0425] Additionally, the commands for performing the operations of the terminal described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium. The storage medium may be included in one or more memories (104 or 204). In addition, the commands 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 the disclosure of this specification.

[0426] For reference, the operations of a network node or network entity (e.g., AMF, SMF, PCF, UDM, UAS-AF, LMF, etc.) or a base station (e.g., NG-RAN, gNB, RAN, eNB, (R)AN, etc.) described in this specification may be implemented by the devices of FIGS. 1 to 3 described below. For example, the network node or base station may be the first device (100) or the second device (200) of FIG. 2. For example, the operations of a network node or base station described in this specification may be processed by one or more processors (102 or 202). The operations of a terminal described in this specification may be stored in one or more memories (104 or 204) in the form of instructions / programs (e.g., instructions, executable codes) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (106 or 206), and execute instructions / programs stored in one or more memories (104 or 204) to perform operations of a network node or base station as described in the disclosure of this specification.

[0427] Additionally, the instructions for performing the operations of the network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium having the instructions recorded thereon. The storage medium may be included in one or more memories (104 or 204). In addition, 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 node or base station described in the disclosure of this specification.

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

[0429] In the exemplary system described above, the methods are described based on a flowchart as a series of steps or blocks. However, the order of the steps described is not limited, and some steps may occur in a different order or simultaneously with other steps described above. Furthermore, those skilled in the art will understand that the steps depicted in the flowchart are not exclusive, and other steps may be included, or one or more steps in the flowchart may be deleted without affecting the scope of the invention.

[0430] The claims set forth in this specification may be combined in various ways. For example, the technical features of the method claims of this specification may be combined to implement a device, and the technical features of the device claims of this specification may be combined to implement a method. Furthermore, the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a device, and the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a method. Other implementations are within the scope of the claims.

Claims

1. A step of receiving a message including information related to On-demand Network Slice Selection Assistance Information (NSSAI); and comprising the step of transmitting a registration request message including the requested NSSAI; A method wherein a Route Selection Descriptor (RSD) included in a User Equipment (UE) route selection policy (URSP) rule includes a first Single-NSSAI (S-NSSAI), and based on the first S-NSSAI being the on-demand NSSAI, the on-demand NSSAI is included in the requested NSSAI.

2. In paragraph 1, A method wherein the registration request message including the requested NSSAI is a request message for a mobility registration update procedure.

3. In paragraph 1 or 2, A method wherein the first S-NSSAI is provided to the NAS layer of the device by the URSP layer of the device based on the first S-NSSAI being included in the RSD and the first S-NSSAI being the on-demand NSSAI.

4. In paragraph 3, The above first S-NSSAI is provided to a mobility management entity of the NAS layer of the device, A method wherein the registration request message including the requested NSSAI is a request message for a mobility registration update procedure.

5. In any one of paragraphs 1 to 4, A method further comprising the step of determining the on-demand S-NSSAI for establishing a Protocol Data Unit (PDU) session.

6. In paragraph 5, A method wherein the on-demand S-NSSAI is included in the requested NSSAI based on the on-demand S-NSSAI being determined for establishing the PDU session.

7. In any one of paragraphs 1 to 6, A method further comprising the step of obtaining a URSP rule including the above RSD.

8. One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; The actions performed based on the above instructions being executed by the one or more processors are: A device according to any one of claims 1 to 7.

9. At least one processor; and At least one memory storing instructions and being operably electrically connected to the at least one processor, An operation performed based on the above command being executed by the at least one processor: A device according to any one of claims 1 to 7.

10. A non-transitory computer readable medium (CRM) that records commands, The above instructions, when executed by one or more processors, cause the one or more processors to perform a method according to any one of claims 1 to 7.

Images