WO2025150873A1 - Communication method on basis of user change - Google Patents

Abstract

One disclosure of the present specification provides a method. The method comprises the steps in which: an AMF receives a registration request message from a UE, wherein the registration request message includes an identifier of a specific user of the UE; on the basis of the registration request message, the AMF transmits a request message including information on the identifier to a UDM for the UE; on the basis of the request message, the AMF receives a profile of the specific user from the UDM; on the basis of the profile, the AMF determines whether the specific user is allowed to receive a service via the UE; and the AMF transmits a registration acceptance message to the UE, wherein the registration acceptance message includes information on whether the specific user is allowed to receive a service via the UE.

Description

Communication method based on user changes

This specification relates to mobile communications.

3GPP(3rd generation partnership project) LTE(long-term evolution) is a technology to enable high-speed packet communication. Many methods have been proposed to achieve the LTE goals of reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. 3GPP LTE requires cost reduction per bit, improved service availability, flexible use of frequency bands, simple structure, open interface, and appropriate power consumption of terminals as upper-level requirements.

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 technology components necessary to successfully standardize NR in a timely manner that meets both urgent market needs and the longer-term requirements presented by the ITU-R (ITU radio communication sector) IMT (international mobile telecommunications)-2020 process. NR must also be able to use any spectrum band up to at least 100 GHz that will be available for wireless communications far into the future.

NR targets 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.

If the user of the terminal changes, the method of communication through the terminal becomes problematic.

The terminal transmits the changed user identifier to the network, and the network determines whether the terminal can use the service based on this.

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

Figure 2 illustrates an example of a wireless device to which the implementation of this specification is applied.

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

Figure 4 is a structural diagram of the next-generation mobile communications network.

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

Figures 6 and 7 illustrate examples of registration procedures to which the implementation of this specification applies.

Figures 8 and 9 illustrate examples of PDU session establishment procedures to which the implementation of the present specification applies.

Figure 10 shows an example of a procedure according to the first embodiment of the present specification.

Figure 11 shows an example of a procedure according to the second embodiment of the present specification.

Figure 12 illustrates an example of a procedure for activating a user identifier according to the disclosure of this specification.

Figure 13 illustrates the AMF's procedure for disclosure of this specification.

Figure 14 illustrates the SMF procedure for the disclosure of this specification.

Figure 15 illustrates the UE's procedure for disclosure of this specification.

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, systems, single carrier frequency division multiple access (SC-FDMA) systems, and multicarrier frequency division multiple access (MC-FDMA) systems. CDMA can be implemented via wireless technologies such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA can be implemented via 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 over wireless technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or evolved UTRA (E-UTRA). UTRA is part of universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long-term evolution (LTE) is part of evolved UMTS (E-UMTS) using E-UTRA. 3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolutions of 3GPP LTE include LTE-A (advanced), LTE-A Pro, and/or 5G NR (new radio).

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

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.

As used herein, “A or B” can mean “only A”, “only B”, or “both A and B”. In other words, 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”.

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".

As used herein, “at least one of A and B” can mean “only A”, “only B” or “both A and B”. Additionally, as used herein, the expressions “at least one of A or B” or “at least one of A and/or B” can be interpreted identically to “at least one of A and B”.

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".

In addition, the parentheses used in this specification may mean "for example". Specifically, when it is 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". In addition, even when it is indicated as "control information (i.e., PDCCH)", "PDCCH" may be proposed as an example of "control information".

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

Although not limited thereto, the various descriptions, functions, procedures, suggestions, methods, and/or operational flowcharts disclosed in this specification may be applied to various fields requiring wireless communication and/or connectivity between devices (e.g., 5G).

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 numerals may refer to identical or corresponding hardware blocks, software blocks and/or functional blocks unless otherwise indicated.

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

The 5G usage scenarios shown in Fig. 1 are only examples, and the technical features of this specification can be applied to other 5G usage scenarios not shown in Fig. 1.

There are three major requirement categories for 5G: (1) enhanced mobile broadband (eMBB) category, (2) massive machine type communication (mMTC) category, and (3) ultra-reliable and low latency communications (URLLC) category.

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 describes a 5G network as an example of a network of the communication system (1), but the implementation of the present specification is not limited to a 5G system, and can be applied to future communication systems beyond the 5G system.

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.

The wireless devices (100a to 100f) represent devices that perform communications 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 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/VR/mixed reality (MR) devices, and may be implemented in the form of head-mounted devices (HMDs), head-up displays (HUDs) mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signage, 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.

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 smart phone, 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 holographic 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.

For example, a UAV may be an aircraft that does not carry a human on board and is guided by radio control signals.

For example, a VR device may include a device for implementing an object or background of a virtual environment. For example, an AR device may include a device that implements an object or background of a virtual world by connecting it to an object or background of a real world. For example, an MR device may include a device that implements an object or background of a virtual world by merging it with an object or background of the real world. For example, a hologram device may include a device for implementing a 360-degree stereoscopic image by recording and reproducing stereoscopic information using a light interference phenomenon that occurs when two laser lights called holograms meet.

For example, a public safety device may include an image relay device or imaging device that can be worn on the user's body.

For example, MTC devices and IoT devices may be devices that do not require direct human intervention or manipulation. For example, MTC devices and IoT devices may include smart meters, vending machines, thermometers, smart light bulbs, door locks, or various sensors.

For example, a medical device may be a device used for the purpose of diagnosing, treating, alleviating, curing, or preventing a disease. For example, a medical device may be a device used for the purpose of diagnosing, treating, alleviating, or correcting an injury or damage. For example, a medical device may be a device used for the purpose of examining, replacing, or modifying a structure or function. For example, a medical device may be a device used for the purpose of regulating pregnancy. For example, a medical device may include a therapeutic device, a driving device, an (in vitro) diagnostic device, a hearing aid, or a surgical device.

For example, a security device may be a device installed to prevent possible hazards and maintain safety. For example, a security device may be a camera, closed circuit television (CCTV), recorder, or black box.

For example, a fintech device may be a device that can provide financial services such as mobile payments. For example, a fintech device may include a payment device or a point-of-sale system.

For example, a weather/environment device may include a device that monitors or predicts the weather/environment.

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).

Wireless communications/connections (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 communications/connections can be established through various RATs (e.g., 5G NR), such as uplink/downlink communications (150a), sidelink communications (150b) (or, device-to-device (D2D) communications), and inter-base station communications (150c) (e.g., relay, integrated access and backhaul (IAB)). Through the wireless communications/connections (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, 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 based on various proposals of the present specification.

AI refers to a field that studies artificial intelligence or the methodologies for creating it, and machine learning refers to a field that defines various problems in the field of artificial intelligence and studies the methodologies for solving them. Machine learning is also defined as an algorithm that improves the performance of a task through constant experience with that task.

A robot can refer to a machine that automatically processes or operates a given task by its own ability. In particular, a robot that has the function of recognizing the environment, making judgments on its own, and performing actions can be called an intelligent robot. Robots can be classified into industrial, medical, household, and military types depending on their purpose or field of use. A robot can perform various physical actions, such as moving robot joints, by having a drive unit including an actuator or motor. In addition, a mobile robot can have a drive unit including wheels, brakes, and propellers, and can drive on the ground or fly in the air through the drive unit.

Autonomous driving refers to technology that drives itself, and autonomous vehicles refer to vehicles that drive without user intervention or with minimal user intervention. For example, autonomous driving can include technology that maintains the driving lane, technology that automatically adjusts speed such as adaptive cruise control, technology that automatically drives along a set path, and technology that automatically sets a path and drives when a destination is set. Vehicles include vehicles with only internal combustion engines, hybrid vehicles with both internal combustion engines and electric motors, and electric vehicles with only electric motors, and can include not only cars but also trains, motorcycles, etc. Autonomous vehicles can be viewed as robots with autonomous driving functions.

Extended reality is a general term for VR, AR, and MR. VR technology provides only CG images of objects or backgrounds in the real world, AR technology provides virtual CG images on top of images of real objects, and MR technology is a CG technology that mixes and combines virtual objects in the real world. MR technology is similar to AR technology in that it shows real and virtual objects together. However, there is a difference in that while AR technology uses virtual objects to complement real objects, MR technology uses virtual and real objects with equal characteristics.

NR supports multiple numerologies or subcarrier spacings (SCS) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands; when the SCS is 30 kHz/60 kHz, it supports dense-urban, lower latency, and wider carrier bandwidth; and when the SCS is 60 kHz or higher, it supports a bandwidth greater than 24.25 GHz to overcome phase noise.

The NR frequency band can be defined by two types of frequency ranges (FR1, FR2). The numerical values of the frequency ranges can be changed. For example, the two types of frequency ranges (FR1, 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 "sub 6GHz range", and FR2 can mean "above 6GHz range" and can be called millimeter wave (mmW).

Frequency range definition Frequency range Subcarrier spacing FR1 450MHz - 6000MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

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

Frequency range definition Frequency range Subcarrier spacing FR1 410MHz - 7125MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

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, the NB-IoT technology may be an example of a low power wide area network (LPWAN) 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, the LTE-M technology may be an example of LPWAN technology, and may be called by various names such as eMTC (enhanced MTC). For example, the 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, the ZigBee technology can create PAN (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.

Figure 2 illustrates an example of a wireless device to which the implementation of this specification is applied.

In FIG. 2, the first wireless device (100) and/or the second wireless device (200) may be implemented in various forms depending on the usage example/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.

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).

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).

The processor (102) may control the memory (104) and/or the transceiver (106), and may be configured to implement the descriptions, functions, procedures, suggestions, 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).

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 wireless interface protocol layers.

Here, the processor (102) and the 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 coupled to the processor (102) to 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) section. In this specification, the first wireless device (100) may represent a communication modem/circuit/chip.

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).

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).

The processor (202) may control the memory (204) and/or the transceiver (206), and may be configured to implement the descriptions, functions, procedures, suggestions, 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).

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 a set of instructions, commands and/or 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 wireless interface protocol layers.

Here, the processor (202) and the 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 coupled to the processor (202) to 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 section. In this specification, the second wireless device (200) may represent a communication modem/circuit/chip.

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, 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, suggestions, 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, suggestions, methods and/or operational flowcharts disclosed herein.

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 comprised of random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, volatile memory, nonvolatile memory, hard drives, registers, cache memory, computer readable storage media, and/or combinations thereof. The one or more memories (104, 204) may be located internally and/or externally to the one or more processors (102, 202). Additionally, the one or more memories (104, 204) may be coupled to the one or more processors (102, 202) via various technologies, such as wired or wireless connections.

One or more transceivers (106, 206) can transmit user data, control information, wireless signals/channels, etc., referred to in the descriptions, functions, procedures, suggestions, 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, suggestions, 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.

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).

One or more transceivers (106, 206) may convert received user data, control information, wireless signals/channels, etc. from RF band signals to baseband signals for processing 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).

Although not shown 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 wired or wireless connections.

In an implementation of the present disclosure, a UE can operate as a transmitter in the uplink (UL) and as a receiver in the downlink (DL). In an implementation of the present disclosure, a base station can operate as a receiver in the UL and as a transmitter in the DL. For 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 an implementation of the present disclosure or to control a transceiver (106) to perform UE operations according to an implementation of the present disclosure. 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 an implementation of the present disclosure or to control a transceiver (206) to perform base station operations according to an implementation of the present disclosure.

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

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

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

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).

The processor (102) may be configured to implement the descriptions, functions, procedures, suggestions, 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, suggestions, 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 chipset, logic circuitry 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). Examples of processors (102) can be found in the SNAPDRAGON ^TM series processors made by Qualcomm®, the EXYNOS ^TM series processors made by Samsung®, the A series processors made by Apple®, the HELIO ^TM series processors made by MediaTek®, the ATOM ^TM series processors made by Intel®, or their corresponding next-generation processors.

Memory (104) is operatively coupled with processor (102) and stores various information for operating processor (102). Memory (104) may include ROM, RAM, flash memory, memory card, 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 processor (102). Memory (104) may be implemented within processor (102) or external to processor (102), in which case it may be communicatively coupled with processor (102) via various methods known in the art.

A transceiver (106) is operatively coupled to the processor (102) and transmits and/or receives wireless signals. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include baseband circuitry for processing radio frequency signals. The transceiver (106) controls one or more antennas (108) to transmit and/or receive wireless signals.

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).

The display (143) outputs the result 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).

A SIM card (145) is an integrated circuit for securely storing an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate subscribers in mobile phone devices such as mobile phones and computers. Contact information can also be stored on many SIM cards.

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).

Figure 4 is a structural diagram of the next-generation mobile communications network.

5GC (5G Core) may include various components, and in FIG. 5, some of them include AMF (Access and Mobility Management Function) (410), SMF (Session Management Function) (420), PCF (Policy Control Function) (430), UPF (User Plane Function) (440), AF (Application Function) (450), UDM (Unified Data Management) (460), and N3IWF (Non-3GPP (3rd Generation Partnership Project) Inter Working Function) (490).

The UE (100) is connected to a data network via UPF (440) through a Next Generation Radio Access Network (NG-RAN) including a gNB (20).

The UE (100) can also receive data services through untrusted non-3GPP access, for example, a Wireless Local Area Network (WLAN). To connect the non-3GPP access to the core network, an N3IWF (490) can be deployed.

The illustrated N3IWF (490) performs a function of managing interworking between non-3GPP access and a 5G system. When the UE (100) is connected to a non-3GPP access (e.g., WiFi referred to as IEEE 801.11), the UE (100) can be connected to a 5G system through the N3IWF (490). The N3IWF (490) performs control signaling with the AMF (410) and is connected to the UPF (440) through the N3 interface for data transmission.

The illustrated AMF (410) can manage access and mobility in a 5G system. The AMF (410) can perform a function of managing Non-Access Stratum (NAS) security. The AMF (410) can perform a function of handling mobility in an idle state.

The illustrated UPF (440) is a type of gateway through which user data is transmitted and received. The UPF node (440) can perform all or part of the user plane functions of the S-GW (Serving Gateway) and P-GW (Packet Data Network Gateway) of 4th generation mobile communications.

The UPF (440) acts as a boundary point between the next generation radio access network (NG-RAN) and the core network, and is an element that maintains a data path between the gNB (20) and the SMF (420). In addition, when the UE (100) moves across an area served by the gNB (20), the UPF (440) acts as a mobility anchor point. The UPF (440) can perform a function of handling PDUs. For mobility within the NG-RAN (Next Generation-Radio Access Network defined after 3GPP Release-15), the UPF can route packets. Additionally, UPF (440) may also function as an anchor point for mobility with other 3GPP networks (RANs defined before 3GPP Release-15, e.g. UTRAN, E-UTRAN (Evolved-UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network)) or GERAN (GSM (Global System for Mobile Communication)/EDGE (Enhanced Data rates for Global Evolution) Radio Access Network). UPF (440) may correspond to a termination point of a data interface toward a data network.

The illustrated PCF (430) is a node that controls the business operator's policy.

The illustrated AF (450) is a server for providing various services to the UE (100).

The illustrated UDM (460) is a type of server that manages subscriber information, such as the HSS (Home Subscriber Server) of 4th generation mobile communication. The UDM (460) stores and manages the subscriber information in a Unified Data Repository (UDR).

The illustrated SMF (420) can perform the function of allocating an IP (Internet Protocol) address of the UE. In addition, the SMF (420) can control a PDU (protocol data unit) session.

For reference, the drawing symbols for AMF (410), SMF (420), PCF (430), UPF (440), AF (450), UDM (460), N3IWF (490), gNB (20), or UE (100) may be omitted below.

The 5th generation mobile communications support multiple numerologies or subcarrier spacings (SCS) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands; when the SCS is 30 kHz/60 kHz, it supports dense-urban, lower latency, and wider carrier bandwidth; and when the SCS is 60 kHz or higher, it supports a bandwidth larger than 24.25 GHz to overcome phase noise.

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

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

- AUSF (Authentication Server Function)

-AMF (Access and Mobility Management Function)

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

- USDF (Unstructured Data Storage Function)

- NEF (Network Exposure Function)

- I-NEF (Intermediate NEF)

- NRF (Network Repository Function)

- NSSF (Network Slice Selection Function)

- PCF (Policy Control Function)

- SMF (Session Management Function)

-UDM (Unified Data Management)

-UDR (Unified Data Repository)

- UPF (User Plane Function)

- UCMF (UE radio Capability Management Function)

- AF (Application Function)

- UE (User Equipment)

- (R)AN ((Radio) Access Network)

- 5G-EIR (5G-Equipment Identity Register)

- NWDAF (Network Data Analytics Function)

- CHF (CHarging Function)

Additionally, the following network features may be considered:

- N3IWF (Non-3GPP InterWorking Function)

- TNGF (Trusted Non-3GPP Gateway Function)

- W-AGF (Wireline Access Gateway Function)

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

In Figure 5, for clarity of the point-to-point diagram, UDSF, NEF and NRF are not illustrated. However, all network functions shown can interact with UDSF, UDR, NEF and NRF as needed.

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.

The 5G system architecture includes the following benchmarks:

- N1: Reference point between UE and AMF.

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

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

- N4: Reference point between SMF and UPF.

- N6: Reference point between UPF and data network.

- N9: Reference point between two UPFs.

The following benchmarks demonstrate the interactions that exist between NF services in NF.

- N5: Reference point between PCF and AF.

- N7: Reference point between SMF and PCF.

- N8: Reference point between UDM and AMF.

- N10: Reference point between UDM and SMF.

- N11: Reference point between AMF and SMF.

- N12: Reference point between AMF and AUSF.

- N13: Reference point between UDM and AUSF.

- N14: Reference point between two AMFs.

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

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

- N22: Reference point between AMF and NSSF.

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

<Registration Procedure>

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

Figures 6 and 7 illustrate examples of registration procedures to which the implementation of this specification applies.

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

- Initial registration for 5GS; or

- mobility registration update; or

- periodic registration update; or

- Emergency registration

The general registration procedure of Figures 6 and 7 applies to all registration procedures described above, but periodic registration updates do not need to include all parameters used in other registration procedures.

The generic registration procedure of Figures 6 and 7 may also be used when registering to a 3GPP connection when the UE is already registered to a non-3GPP connection, and vice versa. To register to a 3GPP connection when the UE is already registered to a non-3GPP connection scenario, an AMF change may be required.

First, the procedure of Fig. 6 is described.

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

The registration request message may include AN parameters. For NG-RAN, the AN parameters include, for example, a 5G SAE temporary mobile subscriber identity (5G-S-TMSI) or a globally unique AMF ID (GUAMI), a selected public land mobile network (PLMN) ID (or PLMN ID and network identifier (NID)) and a 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.

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

When a UE performs initial registration, the UE indicates its UE ID in the registration request message as follows, listed in decreasing priority order:

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

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

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

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

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

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

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

For emergency registration, if the UE does not have a valid 5G-GUTI, SUCI is included, if the UE does not have a subscriber permanent identifier (SUPI) and does not have a valid 5G-GUTI, PEI (permanent equipment identifier) is included. In other cases, 5G-GUTI is included, which indicates the last serving AMF.

The registration request message may also include security parameters, PDU session status, etc. The 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 an established PDU session in the current PLMN in the UE.

(2) Step 2: (R)AN selects AMF.

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

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

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

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

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.

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.

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

(4) Step 4: If the 5G-GUTI of the UE 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 SUPI and UE context of the UE.

(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.

(6) Step 6: If SUCI is not provided by the UE or is 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.

(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).

(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.

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

(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.

(11) Step 11: If the PEI is not provided by the UE or has not been retrieved from the previous AMF, the new AMF may initiate an 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.

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

Now, the procedure of Fig. 7 following the procedure of Fig. 6 is described.

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

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

(15) Step 15: New AMF can select PCF.

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

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

(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 N3IWF/TNGF/W-AGF.

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

(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.

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

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, the 5G-GUTI is included. If the UE is already in 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 allocated for the existing registration for the new registration. If the new AMF allocates a new Registration Area, it sends the Registration Accept message to the UE with 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 3GPP and non-3GPP connections, the UE locally removes internal resources associated with PDU sessions of the current PLMN that are not marked as established in the received PDU Session State. If PDU Session State information is present in the Registration Accept message, the new AMF indicates the PDU Session State to the UE.

The Allowed NSSAI provided in the Registration Accept message is valid for the registration area and applies to all PLMNs having a tracking area included in the registration area. Mapping Of Allowed NSSAI maps HPLMN S-NSSAI to each S-NSSAI of Allowed NSSAI. Mapping Of Configured NSSAI maps HPLMN S-NSSAI to each S-NSSAI of Configured NSSAI for serving PLMN.

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

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

The UE may send a registration complete message to the new AMF to check if a new 5G-GUTI has been allocated.

(23) Step 23: For registration over 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. For registration over 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.

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

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

<PDU Session Establishment Procedure>

Describes the PDU session establishment procedure. See section 4.3.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

Figures 8 and 9 illustrate examples of PDU session establishment procedures to which the implementation of the present specification applies.

Establishing a PDU session can involve:

- UE initiated PDU session establishment procedure

- PDU session handover between 3GPP and non-3GPP initiated by UE

- PDU session handover from UE-initiated EPS to 5GS.

- Network triggered PDU session establishment procedure

A PDU session may be associated with (a) a single connection type at a given time, i.e., either a 3GPP connection or a non-3GPP connection, or (b) multiple connection types simultaneously, i.e., one 3GPP connection and one non-3GPP connection. A PDU session associated with multiple connection types is called a multi-access (MA) PDU session and may be requested by an access traffic steering, switching, splitting (ATSS) capable UE.

Figures 8 and 9 specify the procedure for establishing a PDU session associated with a single connection type at a given time.

In the procedures shown in Figures 8 and 9, it is assumed that the AMF has already retrieved the user subscription data from the UDM, unless the UE is emergency registered, since the UE is already registered with the AMF.

First, the procedure of Fig. 8 is explained.

(1) Step 1: To establish a new PDU session, the UE generates a new PDU session ID.

The UE initiates the PDU session establishment procedure requested by the UE by transmitting an NAS message containing a PDU Session Establishment Request message within an N1 SM container. The PDU Session Establishment Request message includes a PDU session ID, a Requested PDU Session Type, a requested session and service continuity (SSC) mode, 5G SM capabilities, Protocol Configuration Options (PCO), an SM PDU DN Request Container, and a UE Integrity Protection Maximum Data Rate.

If the PDU Session Establishment is a request to establish a new PDU Session, the Request Type is "Initial Request". If the Request refers to an existing PDU Session switching between a 3GPP connection and a non-3GPP connection, or a PDU Session handover from an existing packet data network (PDN) connection in the EPC, the Request Type is "Existing PDU Session". If the PDU Session Establishment is a request to establish a PDU Session for emergency services, the Request Type is "Emergency Request". If the Request refers to an existing PDU Session for emergency services switching between a 3GPP connection and a non-3GPP connection, or a PDU Session handover from an existing PDN connection for emergency services in the EPC, the Request Type is "Existing Emergency PDU Session".

The UE includes the S-NSSAI from the allowed NSSAI of the current connection type. If the Mapping Of Allowed NSSAI is provided to the UE, the UE provides both the S-NSSAI of the VPLMN (visited VPLMN) from the allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the Mapping Of Allowed NSSAI.

(2) Step 2: AMF selects an SMF. If the request type indicates "initial request" or the request is due to a handover from an EPS or other non-3GPP connection provided by an AMF, AMF stores the connection type of the PDU session as well as the association of S-NSSAI(s), data network name (DNN), PDU session ID, and SMF ID.

If the request type is "Initial Request" and the message also contains a previous PDU session ID representing an existing PDU session, AMF selects an SMF and stores the association for the new PDU session ID, S-NSAI(s), and the selected SMF ID.

If the request type indicates "Existing PDU Session", AMF selects an SMF based on the SMF-ID received from the UDM. AMF updates the stored connection type for the PDU session.

If the request type indicates "Existing PDU Session" referring to an existing PDU session moving between a 3GPP connection and a non-3GPP connection, and if the serving PLMN S-NSSAI of the PDU session is in the allowed NSSAIs of the target connection type, the PDU session establishment procedure may be performed in the following cases:

- When the SMF ID and AMF corresponding to the PDU session ID belong to the same PLMN;

- If the SMF ID corresponding to the PDU session ID belongs to HPLMN;

Otherwise, AMF rejects the PDU session establishment request with an appropriate rejection cause.

AMF rejects requests from emergency-registered UEs whose request type does not indicate "Emergency Request" or "Existing Emergency PDU Session".

(3) Step 3: If AMF is not associated with an SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Initial Request"), AMF calls the Create SM Context request procedure (e.g., Nsmf_PDUSession_CreateSMContext Request). If AMF is already associated with an SMF for the PDU session ID provided by the UE (e.g., when the request type indicates "Existing PDU Session"), AMF calls the Update SM Context request procedure (e.g., Nsmf_PDUSession_UpdateSMContext Request).

The AMF forwards the S-NSSAI of the serving PLMN to the SMF from the allowed NSSAI. For a roaming scenario of local breakout (LBO), the AMF also forwards the corresponding S-NSSAI of the HPLMN to the SMF from the mapping of the allowed NSSAI.

The AMF ID is the GUAMI of the UE, which uniquely identifies the AMF serving the UE. The AMF passes the PDU Session ID along with the N1 SM container containing the PDU Session Establishment Request message received from the UE. The generic public subscription identifier (GPSI) is included if available to the AMF.

If a UE in restricted service state is registered for emergency services without providing SUPI, the AMF provides PEI instead of SUPI. If a UE in restricted service state is registered for emergency services while providing SUPI but is not authenticated, the AMF indicates that the SUPI is not authenticated. If the SMF does not receive SUPI for the UE or if the AMF indicates that the SUPI is not authenticated, the UE is considered not authenticated.

AMF can include PCF ID in Nsmf_PDUSession_CreateSMContext. This PCFID identifies H-PCF (home PCF) in non-roaming case and V-PCF (visited PCF) in LBO roaming case.

(4) Step 4: If the session management subscription data for the S-NSSAI of the corresponding SUPI, DNN, and HPLMN is not available, the SMF can retrieve the session management subscription data from the UDM and be notified when the subscription data is modified.

(5) Step 5: SMF sends a create SM context response message (e.g., Nsmf_PDUSession_CreateSMContext Response) or an update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to AMF according to the request received in Step 3.

If SMF receives the Nsmf_PDUSession_CreateSMContext Request in step 3 and can process the PDU session establishment request, SMF creates an SM context and responds to AMF by providing the SM context ID.

If the SMF decides not to accept the PDU session establishment, the SMF rejects the UE request via NAS SM signaling including the relevant SM rejection cause by responding to the AMF with Nsmf_PDUSession_CreateSMContext Response. The SMF also indicates to the AMF that the PDU session ID is considered released and the SMF proceeds to step 20 below and the PDU session establishment procedure is aborted.

(6) Step 6: Optional secondary authentication/authorization may be performed.

(7a) Step 7a: When dynamic policy and charging control (PCC) is used for a PDU session, the SMF can perform PCF selection.

(7b) Step 7b: SMF performs the SM policy association establishment procedure to establish a SM policy association with the PCF and obtain the default PCC rules for the PDU session.

(8) Step 8: SMF selects one or more UPFs.

(9) Step 9: The SMF may perform the SM policy association modification procedure initiated by the SMF to provide information about the satisfied policy control request trigger conditions.

(10) Step 10: If the request type indicates an “Initial Request”, the SMF may initiate the N4 Session Establishment procedure with the selected UPF. Otherwise, the SMF may initiate the N4 Session Modification procedure with the selected UPF.

In step 10a, SMF can send N4 session establishment/modification request to UPF and provide packet detection, enforcement and reporting rules to be installed in UPF for PDU session. In step 10b, UPF can confirm by sending N4 session establishment/modification response.

(11) Step 11: SMF sends an N1N2 Message Transfer message (e.g. Namf_Communication_N1N2 Message Transfer) to AMF.

The N1N2 Message Forwarding message may contain N2 SM information. The N2 SM information carries the following information that the AMF is to forward to the (R)AN:

- CN Tunnel Info: Corresponds to the core network address of the N3 tunnel corresponding to the PDU session;

- QFI (QoS flow ID) corresponding to one or more QoS (quality of service) profiles;

- PDU Session ID: Indicates to the UE the association between RAN resources and a PDU session for the UE;

- S-NSSAI with value for the serving PLMN (i.e. HPLMN S-NSSAI, or VPLMN S-NSSAI in case of LBO roaming);

- User plane security enforcement information determined by SMF;

- UE integrity protection maximum data rate received in the PDU Session Establishment Request message: if integrity protection is indicated as “Preferred” or “Required” in the user plane security enforcement information.

- RSN(redundancy sequence number) parameter

The N1N2 Message Transfer message may contain an N1 SM container. The N1 SM container contains a PDU Session Establishment Accept message that the AMF will provide to the UE. The PDU Session Establishment Accept message contains an S-NSSAI from the allowed NSSAIs. For LBO roaming scenarios, the PDU Session Establishment Accept message contains an S-NSSAI from the allowed NSSAIs for the VPLMN and also contains the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAIs received by the SMF in step 3.

Multiple QoS rules, QoS flow levels, and QoS parameters, if required, for QoS flows associated with QoS rules and QoS profiles can be included in the PDU Session Establishment Accept message and N2 SM information within the N1 SM container.

If the PDU session establishment fails between steps 5 and 11, the N1N2 message transfer message contains an N1 SM container containing a PDU session establishment rejection message, and does not contain N2 SM information. The (R)AN sends an NAS message containing a PDU session establishment rejection message to the UE. In this case, steps 12-17 below are omitted.

(12) Step 12: AMF sends a NAS message containing the PDU Session ID and PDU Session Establishment Accept message destined for the UE and the N2 SM information received from SMF to (R)AN within an N2 PDU Session Request message.

(13) Step 13: (R)AN may perform AN specific signaling exchange with the UE related to the information received from the SMF. For example, in case of NG-RAN, the UE may perform RRC connection reconfiguration with the UE to set up the necessary NG-RAN resources related to the QoS rules for the PDU session request received in step 12.

(R)AN forwards the NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept message)) received in step 12 to the UE. (R)AN provides the NAS message to the UE only if the AN specific signaling exchange with the UE includes (R)AN resource addition related to the received N2 command.

If N2 SM information is not included in step 11, steps 14-16b and step 17 below are omitted.

Now, the procedure of Fig. 9 following the procedure of Fig. 8 is described.

(14) Step 14: (R)AN sends an N2 PDU Session Response message to AMF. The N2 PDU Session Response message may include PDU Session ID, cause, N2 SM information (PDU Session ID, AN tunnel information, accepted/rejected QFI list, user plane enforcement policy notification), etc.

(15) Step 15: AMF sends an update SM context request message (e.g., Nsmf_PDUSession_UpdateSMContext Request) to SMF. AMF forwards the N2 SM information received from (R)AN to SMF.

(16a) Step S16a: SMF initiates the N4 session modification procedure with UPF. SMF provides AN tunnel information and corresponding forwarding rules to UPF.

(16b) Step S16b: UPF provides an N4 session modification response to SMF.

After this step, the UPF can forward any DL packets that may have been buffered for this PDU session to the UE.

(16c) Step 16c: If the SMF is not already registered for this PDU session, the SMF may register with the UDM for the given PDU session.

(17) Step 17: SMF sends an update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to AMF.

After this step, AMF forwards the relevant events to which SMF has subscribed.

(18) Step 18: At any time during the procedure after Step 5, if the PDU session establishment is not successful, the SMF can notify the AMF by calling Nsmf_PDUSession_SMContextStatusNotify (release). The SMF can also release the created N4 session, the PDU session address (e.g. IP address) if assigned, and possibly the association with the PCF. In this case, Step 19 below is omitted.

(19) Step 19: For PDU session type IPv6 or IPv4v6, SMF may generate and send an IPv6 Router Advertisement to the UE.

(20) Step 20: SMF can perform SM policy association modification initiated by SMF.

(21) Step 21: If the PDU session establishment fails after step 4, the SMF may unsubscribe from modifications to the session management subscription data if the SMF no longer processes the UE's PDU session.

The proposed method may consist of a combination of one or more of the operations/configurations/steps described herein.

In this specification, UE (User Equipment) and terminal are used interchangeably.

The operations/compositions/steps/methods described in this specification may be performed or used in combination or complementary manner.

Multiple users can use one terminal.

For example, a subscriber of a terminal and other users may use one terminal. The subscriber of a terminal and the user using the terminal may be different.

Methods for supporting service provision, QoS provision, and authentication information exposure may vary depending on the user using the terminal. Methods for this may be proposed in this specification.

I. 1st Disclosure

User identifier specific policies can be applied by transmitting user identifiers.

For the first disclosure, it can be assumed that the user profile contains the following information and that the UDM of the user identifier stores the following information:

- User identifier and associated credentials

- List of allowed UEs (for example, SUPI, PEI, GPSI, etc. can be used as UE identification information)

- Restriction of user identifier

- Roaming allowance

The network to which the UE belongs (or the HPLMN of the UE) and the network to which the user belongs (or the HPLMN of the user) may be the same or different.

The Roaming allowance information may be one or more of the following information. This information may be configured/managed for each allowed UE or configured/managed to apply to all allowed UEs:

- Information on whether the user can receive services only on the network to which the UE belongs (or the HPLMN of the UE) or whether the user can receive services on networks to which the UE does not belong (this can be interpreted as information on whether roaming is allowed from the UE's perspective)

- Information about whether the user can receive services only on the network to which the user belongs (or on the user's HPLMN) or whether the user can receive services on networks to which the user does not belong (this can be interpreted as information about whether roaming is allowed from the user's perspective).

- Information on whether the user can receive services in networks to which the UE does not belong and in networks to which the user does not belong (this can be interpreted as information on whether roaming is permitted, considering both the UE and user perspectives)

- Maximum number of simultaneous connections per subscription

- Policies for user identifier, e.g. RFSP index, Subscribed user-AMBR, Subscribed Session-AMBR, Subscribed default QoS information

The user profile may be stored in the UE's subscription instead of being stored in the home network UDM of the user identifier, for example in the UE's home network UDM.

When a user wishes to receive a service using a UE, the UE may perform a registration procedure with 5GC using a NAI-based SUPI that includes the user identifier that the user wishes to use in the user name portion.

For example, "<user_id_example>@5gc.mnc123.mcc450.3gppnetwork.org" can be used to authenticate a user identifier.

The user identifier may be unique within the subscriber's PLMN.

The UE may already be registered with the network before the UE performs registration using a user identifier.

The home network of the user identifier may be different from the home network of the UE.

If the authentication of the user identifier is successful (authentication is completed successfully), AMF can retrieve the user profile from the UDM of the user identifier. AMF can retrieve the user profile using the user identifier as a key. Based on the retrieved user profile, AMF can determine (verify) whether the user can receive the service through the UE.

If the user is eligible for the service (e.g., if the AMF determines that the user is eligible for the service), the AMF may provide a registration acceptance to the UE.

If the user profile contains policies for the user identifier (e.g. RFSP index, subscribed user-AMBR), AMF can trigger the Npcf_AMPolicyControl_Update service to provide the user policies to PCF.

PCF can update the RFSP index, UE-AMBR of the UE based on the received user policy.

AMF can notify UDM that a given user identifier is serviced by AMF by triggering Nudm_UECM_Update to send that user identifier to UDM.

AMF can provide user identifier to UDM by triggering Nudm_UECM_Update.

If there is an existing PDU session for the UE, AMF can trigger the Nsmf_PDUSession_UpdateSMContext service to provide the user identifier to SMF.

When a UE requests a new PDU session, AMF can provide the user identifier to SMF via the Nsmf_PDUSession_CreateSMContext service.

Based on the received user identifier, SMF can retrieve the user profile in the UDM of the user identifier. SMF can retrieve the user profile using the user identifier as a key.

If the user profile contains policies for the user identifier (e.g., subscription session-AMBR, subscription default QoS information), SMF can trigger the Npcf_SMPolicyControl_Create or Npcf_SMPolicyControl_Update service to provide the user policies to PCF.

Based on the received user policy, PCF can update PCC rules and session-AMBR.

SMF can trigger Nudm_UECM_Update to provide UDM with a user identifier to notify that the user identifier is to be serviced over a PDU session.

1. First embodiment

According to a first embodiment, user profile information for a user identifier can be stored in the UDM.

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 10 shows an example of a procedure according to the first embodiment of the present specification.

1) step 1

A registration procedure may be performed. In this regard, the descriptions of FIGS. 6 and 7 may be applied.

The UE may transmit its ID to the network during the registration procedure. For example, the UE may perform registration without a user identifier.

A PDU session establishment procedure can be performed. In this regard, the descriptions of FIGS. 8 and 9 can be applied.

A PDU session may or may not be created. For example, in step 1 of the first embodiment, the PDU session establishment procedure may not be performed. If a PDU session for the UE is not created, a PDU session may be established after registration for the user is performed through steps 2 to 6.

During the registration procedure, it can be assumed that the AMF indicates support for the user identifier to the UE. If the serving AMF indicates support for the user identifier to the UE, the procedures described below can be performed.

If the UE moves to an unsupported AMF (an AMF that does not support the user identifier) after the user identifier has been successfully authenticated, the UE may inform the user that the user identifier can no longer be used.

In order to support actions for user identification, etc., even if authentication for the user identifier is not performed, when the AMF changes, the AMF can always indicate in the registration approval message whether the user identifier is allowed for service use to inform the UE. Through this, the UE can check whether the AMF supports the corresponding user identifier. If the AMF does not support the corresponding user identifier, the UE can inform the user that the corresponding user identifier can no longer be used.

2) step 2

The UE can recognize (determine or detect) that a user has changed (or that a new/specific user wants to use the UE).

The UE may send a registration request message to the AMF including a user identifier corresponding to a new/specific user.

The registration request message may include information about the ID of the UE and an identifier for the new/specific user. In addition, the registration request message may additionally include an indication that the new/specific user uses the UE.

3) step 3

AMF can trigger an authentication procedure for a user identifier corresponding to a new/specific user received.

Based on the user identifier included in the registration request message, the AMF can recognize that the user of said UE has changed to a new/specific user.

If there is no roaming agreement between the serving network of the UE (or the HPLMN of the UE) and the home network of the corresponding user identifier (or the HPLMN of the user), the AMF may send a Registration Reject message to the UE to indicate that the service is not allowed for the corresponding user identifier.

For example, AMF may use a specific cause value in a registration rejection message or a new IE to indicate to the UE that service is not allowed for that user identifier.

In this case, the UE can receive the service without using a user identifier.

Authentication of a user identifier can be performed through interaction with an AUSF/UDM of the user identifier's home network (or the user's HPLMN). For example, AMF can perform authentication of a user identifier through interaction with an AUSF/UDM of the user identifier's home network (or the user's HPLMN).

Alternatively, authentication of the user identifier can be performed via interaction with an AAA server of the user identifier via another NF (e.g., NSSAAF, new NF) in the serving network of the UE (or the HPLMN of the UE). For example, the AMF can perform authentication of the user identifier via interaction with an AAA of the user identifier via another NF (e.g., NSSAAF, new NF) in the serving network of the UE (or the HPLMN of the UE).

Authentication of user identifiers may be governed by TS 33.501 v18.4.0 Annex U.2.

4) step 4

After authentication is complete, AMF can retrieve user profile information from UDM. AMF can retrieve user profile information from UDM using user identifier as a key.

For example, AMF can send a message to UDM containing information about said user identifier. Based on this, AMF can receive user profile information about said user identifier from UDM.

The above UDM may be a UDM for a UE (or the user identifier).

A UDM of a user identifier may store a user profile.

If the user profile is stored in the UDM of the UE, the AMF can retrieve the user profile information from the UDM of the UE.

5) step 5

AMF may inform UDM (UDM for UE or UDM of said user identifier) that it serves said user identifier. AMF may send a message containing information about said user identifier to UDM.

The UDM may store the AMF as a serving AMF for the user identifier. The UDM may also mark the user identifier as an activated user identifier in the information it stores.

The UDM may be the home network UDM of the UE or the home network UDM of the user identifier.

If UDM is in the home network of said user identifier, Nudm_UECM_Registration can be performed. For example, AMF can perform Nudm_UECM_Registration to UDM.

AMF can inform the UE's UDM of the registered user identifier information (user identifier information included in the terminal).

Alternatively, the AMF may inform the UDM of the UE that the UE is used in an associated form with a user identifier (e.g., a user corresponding to a user identifier received by the AMF is using the UE) or that an activated user identifier exists. For example, the AMF may inform the UDM of the UE of the user identifier (user identifier information included by the UE) together with the UE ID (e.g., SUPI/GPSI) information.

When the AMF serving the terminal changes due to the mobility of the terminal, the changed AMF can perform Nudm_UECM_Registration to both the UDM of the UE and the UDM of the user identifier.

UDM can check whether roaming is allowed based on user profile information.

If the network to which the terminal belongs is different from the home network of the user identifier, UDM can determine whether to register the user identifier depending on whether roaming is supported.

If roaming (e.g., roaming between the home network of the terminal and other networks) is not allowed, the UDM may reject the registration (Nudm_UECM_Registration of AMF) and send related information (e.g., information indicating that roaming is not allowed) to the AMF. In this case, the AMF may send the registration rejection to the UE along with information indicating that roaming is not allowed (and/or information indicating that services are not available through the UE).

Additionally, UDM can check (determine) whether a service is possible through a UE based on user profile information (e.g. List of allowed UEs) for the user identifier received from AMF.

If UDM determines that the service is available for the user identifier received from AMF, UDM may send an acknowledgement for Nudm_UECM_Registration to AMF.

If UDM determines that the service is not possible for the user identifier received from AMF, UDM may send a rejection for Nudm_UECM_Registration to AMF.

If AMF receives a rejection for Nudm_UECM_Registration from UDM, AMF may send the registration rejection to UE along with information indicating that roaming is not allowed (and/or information indicating that services are not available through that UE).

Alternatively, if AMF receives a rejection for Nudm_UECM_Registration from UDM, AMF may send the registration approval to UE along with information indicating that roaming is not allowed (and/or that services are not available through that UE).

Instead of the UDM checking whether roaming is allowed and/or services are available via the UE, the AMF can receive the user profile from the UDM (or based on the user profile received in step 4) and determine/check whether roaming is allowed for the user and/or services are available via the UE.

For example, AMF can send a user identifier to UDM. AMF can receive a user profile corresponding to the user identifier from UDM. Based on the user profile, AMF can determine/check whether roaming is allowed for the user and/or whether service is available via UE.

The user profile may include a list of allowed UEs. Alternatively, the user profile may include a list of not allowed UEs.

6) Step 6

AMF may send a registration approval message to the UE.

At this time, the AMF can inform the UE that the corresponding user identifier is allowed to use the service.

The registration approval message may include (notification) that the user identifier is permitted to use the service.

If the service is not available for the user identifier transmitted by the UE, the AMF may send the UE a registration approval message (or a registration rejection message) containing information that the user identifier is not available for the service.

AMF may provide the UE with a list of allowed (or not allowed) DNNs/S-NSSAIs, which may be stored as part of the user profile, via the registration approval message.

7) step 7

AMF can send a policy update request to the UE. This step can be performed if the user profile received in step 4 contains a policy for the corresponding user identifier.

The above update request may include policy information associated with the user identifier.

The user profile received by AMF in step 4 may include a policy (e.g., RFSP Index, Subscribed user-AMBR) for the corresponding user identifier (new user). In this case, AMF can send the corresponding information (policy) to PCF (PCF for UE).

Based on the information (policy), PCF (PCF for UE) can update the approved RFSP index and approved UE-AMBR.

8) step 8

AMF can send a SM context update request to SMF for a PDU session.

If there is a PDU session for the UE (if a PDU session was established previously, the contents of FIGS. 8 and 9 may be applied to this), the AMF may send information about the corresponding user identifier to the SMF serving that PDU session. For example, the SM Context Update Request that the AMF sends to the SMF may include the corresponding user identifier.

If a user profile contains a list of disallowed DNNs/S-NSSAIs and there is a PDU session that uses a DNN/S-NSSAI included in that list of disallowed DNNs/S-NSSAIs (e.g., a pre-existing PDU session that matches one of the disallowed DNNs/S-NSSAIs included in the user profile), AMF may request SMF to release that PDU session.

In this case, AMF can send SMF information about the reason for release (e.g., information about services/PDU sessions/DNNs/S-NSSAIs that are not allowed/available to the user, etc.).

When a new PDU session establishment procedure is performed (when a new PDU session establishment procedure is performed for a UE after step 6), the AMF may send the user identifier information to the SMF along with the generated SM context request.

9) step 9

SMF can obtain user profile information from UDM.

SMF can retrieve user profile information along with the DNN/S-NSSAI of a PDU session using the user identifier as a key.

For example, SMF can send Nudm_SDM_Get containing information about said user identifier to UDM. UDM can then send user profile information corresponding to the user identifier to SMF.

10) step 10

The SMF may inform the UDM that a user identifier is being served by a PDU session. For example, the SMF may send a message to the UDM containing information about the user identifier.

In this case, UDM may mark the user identifier as an Activated User Identifier.

The UDM may be a UDM of the home network of the UE, or the UDM may be a UDM of the home network of the user identifier.

If the UDM is the UDM of the home network of the user identifier, Nudm_UECM_Registration can be performed.

For example, if UDM is the UDM of the home network of the user identifier, SMF can send Nudm_UECM_Registration request to UDM. Based on this, UDM can store that the user identifier is serviced through PDU session of SMF.

11) step 11

In step 9, if the user profile received by the SMF from the UDM includes a policy for the user identifier (e.g., Subscribed Session-AMBR, Subscribed default QoS information), the SMF can send the corresponding information (policy) to the PCF (PCF for PDU session).

Based on that information (policy), PCF can update PCC rules and/or authorized Session-AMBR (aggregate maximum bit rate)) for authorized sessions.

2. Second embodiment

According to the second embodiment, AMF can obtain the user profile during the authentication process.

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 11 shows an example of a procedure according to the second embodiment of the present specification.

1) step 1

A registration procedure may be performed. In this regard, the descriptions of FIGS. 6 and 7 may be applied.

The UE may transmit its ID to the network during the registration procedure. For example, the UE may perform registration without a user identifier.

A PDU session establishment procedure can be performed. In this regard, the descriptions of FIGS. 8 and 9 can be applied.

A PDU session may or may not be created. For example, in step 1 of the first embodiment, the PDU session establishment procedure may not be performed. If a PDU session for the UE is not created, a PDU session may be established after registration for the user is performed through steps 2 to 6.

During the registration procedure, it can be assumed that the AMF indicates support for the user identifier to the UE. If the serving AMF indicates support for the user identifier to the UE, the procedures described below can be performed.

If the UE moves to an unsupported AMF (an AMF that does not support the user identifier) after the user identifier has been successfully authenticated, the UE may inform the user that the user identifier can no longer be used.

To support actions such as user identification, when the AMF changes, even if authentication of the user identifier is not performed, the AMF can always indicate in the registration approval message whether the user identifier is allowed for service use to the UE.

2) step 2

The UE can recognize (determine or detect) that a user has changed (or that a new/specific user wants to use the UE).

The UE may send a registration request message to the AMF including a user identifier corresponding to a new/specific user.

The registration request message may include information about the ID of the UE and an identifier for the new/specific user. Additionally, the registration request message may include an indication that the new user uses the UE.

3) step 3

AMF can trigger an authentication procedure for a user identifier corresponding to a new/specific user received.

Based on the user identifier included in the registration request message, the AMF can recognize that the user of said UE has changed to a new/specific user.

If there is no roaming agreement between the UE's serving network (or the UE's HPLMN) and the user identifier's home network (or the user's HPLMN), the AMF may send a Registration Reject message to the UE to indicate that the service is not allowed for that user identifier.

For example, AMF may use a specific cause value in a registration rejection message or a new IE to indicate to the UE that service is not allowed for that user identifier.

In this case, the UE can receive the service without using a user identifier.

Authentication of a user identifier can be performed through interaction with an AUSF/UDM of the user identifier's home network (or the user's HPLMN). For example, AMF can perform authentication of a user identifier through interaction with an AUSF/UDM of the user identifier's home network (or the user's HPLMN).

Alternatively, authentication of the user identifier can be performed via interaction with an AAA server of the user identifier via another NF (e.g., NSSAAF, new NF) in the serving network of the UE (or the HPLMN of the UE). For example, the AMF can perform authentication of the user identifier via interaction with an AAA of the user identifier via another NF (e.g., NSSAAF, new NF) in the serving network of the UE (or the HPLMN of the UE).

Authentication of user identifiers may be governed by TS 33.501 v18.4.0 Annex U.2.

4) step 4

After authentication is complete, in EAP-success, the DN-AAA server can send a Success message for authentication (authentication response message) to the AMF via AUSF/NSSAAF.

The success message (authentication response message) for the above authentication may include user profile information for the user identifier authenticated through step 3.

5) step 5

The AMF may inform the UDM (either the UDM for the UE or the UDM of the user identifier) that it serves the user identifier. For example, the AMF may send a message containing information about the user identifier to the UDM.

The UDM may store the AMF as a serving AMF for the user identifier. The UDM may also mark the user identifier as an activated user identifier in the information it stores.

The UDM can be the home network UDM of the UE or the home network UDM of the user identifier.

If the UDM is in the home network of the user identifier, Nudm_UECM_Registration can be performed. For example, AMF can perform Nudm_UECM_Registration to the UDM.

AMF can inform the UE's UDM of the registered user identifier information (user identifier information included in the terminal).

Alternatively, the AMF may inform the UDM of the UE that the UE is used in an associated form with a user identifier (e.g., a user corresponding to a user identifier received by the AMF is using the UE) or that an activated user identifier exists. For example, the AMF may inform the UDM of the UE of the user identifier (user identifier information included by the UE) together with the UE ID (e.g., SUPI/GPSI) information.

When the AMF serving the terminal changes due to the mobility of the terminal, the changed AMF can perform Nudm_UECM_Registration to both the UDM of the UE and the UDM of the user identifier.

UDM can check whether roaming is allowed based on user profile information.

If the network to which the terminal belongs is different from the home network of the user identifier, UDM can determine whether to register the user identifier depending on whether roaming is supported.

If roaming is not permitted (e.g., roaming between the terminal's home network and another network), the UDM may reject the registration (Nudm_UECM_Registration in AMF) and send information about this (e.g., information indicating that roaming is not permitted) to the AMF.

Additionally, UDM can check (determine) whether a service is possible through a UE based on user profile information (e.g. List of allowed UEs) for the user identifier received from AMF.

If UDM determines that the service is available for the user identifier received from AMF, UDM may send an acknowledgement for Nudm_UECM_Registration to AMF.

If UDM determines that the service is not possible for the user identifier received from AMF, UDM may send a rejection for Nudm_UECM_Registration to AMF.

If AMF receives a rejection for Nudm_UECM_Registration from UDM, AMF may send the registration rejection to UE along with information indicating that roaming is not allowed (and/or information indicating that services are not available through that UE).

Alternatively, if AMF receives a rejection for Nudm_UECM_Registration from UDM, AMF may send the registration approval to UE along with information indicating that roaming is not allowed (and/or that services are not available through that UE).

Instead of the UDM checking whether roaming is allowed and/or services are available via the UE, the AMF can receive the user profile from the UDM (or based on the user profile received in step 4) and determine/check whether roaming is allowed for the user and/or services are available via the UE.

For example, AMF can send a user identifier to UDM. AMF can receive a user profile corresponding to the user identifier from UDM. Based on the user profile, AMF can determine/check whether roaming is allowed for the user and/or whether service is available via UE.

The user profile may include a list of allowed UEs. Alternatively, the user profile may include a list of not allowed UEs.

6) Step 6

AMF may send a registration approval message to the UE.

At this time, the AMF can inform the UE that the corresponding user identifier is allowed to use the service.

The registration approval message may include (notification) that the user identifier is permitted to use the service.

If the service is not available for the user identifier transmitted by the UE, the AMF may send the UE a registration approval message (or a registration rejection message) containing information that the user identifier is not available for the service.

AMF may provide the UE with a list of allowed (or not allowed) DNNs/S-NSSAIs, which may be stored as part of the user profile, via the registration approval message.

7) step 7

AMF can send a policy update request to the UE.

This step can be performed if the user profile received in step 4 contains a policy for that user identifier.

The above update request may include policy information associated with the user identifier.

The user profile received by AMF in step 4 may include a policy (e.g., RFSP Index, Subscribed user-AMBR) for the corresponding user identifier (new user). In this case, AMF can send the corresponding information (policy) to PCF (PCF for UE).

Based on the information (policy), PCF (PCF for UE) can update the approved RFSP index and approved UE-AMBR.

8) step 8

AMF may send a SM context update request to SMF for a PDU session. For example, AMF may send an update request to SMF that includes information about the user identifier.

If there is a PDU session for the UE, the AMF may send the corresponding user identifier to the SMF serving that PDU session. For example, the SM Context Update Request that the AMF sends to the SMF may include the corresponding user identifier.

If a user profile contains a list of disallowed DNNs/S-NSSAIs and there is a PDU session that uses a DNN/S-NSSAI included in that list of disallowed DNNs/S-NSSAIs (e.g., a pre-existing PDU session that matches one of the disallowed DNNs/S-NSSAIs included in the user profile), AMF may request SMF to release that PDU session.

In this case, AMF can send SMF information about the reason for release (e.g., information about services/PDU sessions/DNNs/S-NSSAIs that are not allowed/available to the user, etc.).

If AMF obtains user profile information during the authentication process, AMF can send the user profile information to SMF along with the SM context request.

When a new PDU session establishment procedure is performed (when a new PDU session establishment procedure is performed for a UE after step 6), the AMF may send the user identifier information to the SMF along with the generated SM context request.

9) step 9

The SMF may transmit to the UDM that the user identifier is being served by the PDU session. For example, the SMF may transmit to the UDM a message containing information about the user identifier.

Then, UDM can store the user identifier that uses the PDU session.

In this case, the UDM may mark the user identifier as an Activated User Identifier.

The UDM may be a UDM of the home network of the UE, or the UDM may be a UDM of the home network of the user identifier.

If the UDM is the UDM of the home network of the user identifier, Nudm_UECM_Registration can be performed.

For example, if UDM is the UDM of the home network of the user identifier, SMF can send Nudm_UECM_Registration request to UDM. Based on this, UDM can store that the user identifier is serviced through PDU session of SMF.

10) step 10

In step 8, if the user profile received by SMF from AMF includes a policy for user identifier (e.g., Subscribed Session-AMBR, Subscribed default QoS information), SMF can send the corresponding information (policy) to PCF (PCF for PDU session).

Based on that information (policy), PCF can update PCC rules and/or authorized Session-AMBR (aggregate maximum bit rate)) for authorized sessions.

3. Third embodiment

According to a third embodiment, the number of concurrently active user identifiers per SUPI may be limited.

(1) When AMF performs registration for a user identifier using the UDM of the user identifier;

As in the first embodiment, when AMF performs registration for a user identifier with the UDM of the user identifier, the UDM can count the number of user identifiers currently registered.

For example, UDM can count how many terminals are registered with the same user identifier. For this purpose, when the user using the terminal changes or when the existing user no longer uses the terminal, the terminal can notify this information to the AMF serving the user identifier.

For example, a terminal may send a registration request to the AMF that does not include the user identifier.

For example, a terminal may transmit a registration request to the AMF that includes information indicating that the corresponding user identifier will no longer be used.

AMF may send Nudm_UECM_Update to notify the UDM of that user identifier that that user identifier is no longer in use.

Even when AMF deregisters a terminal, it may determine that the corresponding user identifier is no longer in use and notify UDM of this.

Based on this, the UDM of the corresponding user identifier can count the number of current usages for the corresponding user identifier. If the counted number exceeds the Maximum number of simultaneous connections per subscription in the user profile, the corresponding request (e.g., registration request) can be rejected.

(2) When authentication is performed through the DN-AAA server

As in the second embodiment, when authentication is performed via the DN-AAA server, the DN-AAA server can manage the maximum number of simultaneous connections per subscription.

To this end, when a terminal performs registration and notifies that the user identifier is no longer in use, the AMF notifies the DN-AAA of this information via the AUSF/NSSAAF, and the DN-AAA server can update the counting (the number currently in use for that user identifier).

According to the disclosure of this specification, a user profile corresponding to a user identifier may be stored in a UDM or DN-AAA server. AMF may obtain a user profile corresponding to a user identifier (a user identifier received from a terminal) from the UDM or DN-AAA server. AMF may store activated information in the UDM or DN-AAA server. Through this, registration for a new user identifier may be performed.

Alternatively, the user profile corresponding to the user identifier may be stored in an existing NF (e.g. UDR, PCF) or a new NF (a newly defined NF). In this case, the AMF can obtain the user profile corresponding to the user identifier (the user identifier received from the terminal) from the existing NF (e.g. UDR, PCF) or the new NF (a newly defined NF). The AMF can store the activated information in the existing NF (e.g. UDR, PCF) or the new NF (a newly defined NF). Through this, registration for the new user identifier can be performed. For this purpose, existing service operations can be extended or new service operations can be defined.

According to the disclosure of this specification, AMF can obtain a user profile corresponding to a user identifier from UDM. Here, AMF and UDM are not limited. For example, AMF (or SMF, PCF) can obtain a user profile corresponding to a user identifier from UDM (or UDR).

According to the disclosure of this specification, AMF can obtain a user profile corresponding to a user identifier from UDM. The user profile received by AMF may be information about a specific part rather than the entire stored information. For example, AMF (or SMF, PCF) may specify the requested data while requesting a user profile from UDM (or UDR). Then, UDM (or UDR) may transmit information (or all information) about the requested user profile to AMF. When AMF (or SMF, PCF) obtains a user profile from UDM, the user profile may not be stored in UDM, but may be information obtained by UDM from UDR. The process of UDM obtaining information from UDR may be similar to the process of UDM obtaining subscriber information from UDR.

4. Activation procedure for user identifier

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 12 illustrates an example of a procedure for activating a user identifier according to the disclosure of this specification.

The activation procedure of a user identifier to which embodiments of the present specification are applied is described.

1) step 1

A UE can be registered and a PDU session can be established without a user identifier.

For example, the UE may transmit its ID to the network during the registration procedure.

2) step 2

The UE may trigger a registration procedure including the new user's user identifier.

The UE may send a registration request message to the network including the user identifier (User_Id#1) of the new/specific user.

The registration request message may include information about the ID of the UE and an identifier for the new/specific user. Additionally, the registration request message may include an indication that the new user uses the UE.

3) step 3

Based on the user identifier provided by the UE, AMF can trigger authentication of the user identifier.

Based on the user identifier included in the registration request message, the AMF can recognize that the user of said UE has changed to a new/specific user.

This process can be applied to the contents of the first embodiment or the second embodiment.

Upon completion of this process, if the AMF is able to determine a SUPI associated with the user identifier, the AMF may use the SUPI together with the user identifier or select one of the two and perform the steps described below.

For example, when performing registration with UDM, AMF may transmit both the SUPI associated with said user identifier and said user identifier to UDM.

For example, when fetching a subscription, AMF can put the SUPI associated with the user identifier and request subscription information for the user identity profile corresponding to the user identifier. SMF can similarly apply this.

4) step 4

If authentication is successful, AMF can query NRF to select a UDM to store the user ID profile.

AMF may register the user identifier by notifying the UDM that the user identifier is activated and that the user identifier is provided to the UE. For example, AMF may send a message to the UDM containing information about the user identifier (User_Id#1).

AMF may query NRF for UDM when there is no linked SUPI associated with the User Identifier.

For example, if there is no linked SUPI associated with the User Identifier, the AMF may, upon successful authentication, query the NRF to select a UDM that stores the User ID profile. The AMF may notify the UDM that the User Identifier is activated and that the User Identifier is provided to the UE so that the UDM can register the User Identifier.

UDM can check whether the user identifier is in use by another UE (i.e., whether the user identifier is already activated by another UE). If the user identifier is in use by another UE, UDM can reject the registration or deregister the previous registration by sending Nudm_UECM_DeregistrationNotification according to local policy.

5) step 5

AMF can retrieve the user ID profile from UDM by triggering Nudm_SDM_Get by providing the user identifier. Based on the received information, AMF can check if the UE can be used by the user identifier.

6) step 6

If the user identifier is capable of receiving service from the UE, the AMF may send a registration acceptance to the UE with an indication that the user identifier is allowed. Otherwise, the AMF may inform the UDM that the user identifier is disabled, send a registration acceptance to the UE with an indication that the user identifier is not allowed, and abort the procedure.

If user identifiers are not allowed for registration approval, the terminal may directly/indirectly inform the user that user identifiers are not allowed using the user interface/notification, etc.

If the user identifier is not allowed, AMF can send related cause information, etc., so that the terminal can use it to notify the user.

7) step 7

AMF can notify SMF of the user identifier by triggering Nsmf_PDUSession_UpdateSMContext. For example, AMF can send SMF a message containing information about the user identifier (User_Id#1).

At this time, AMF may additionally transmit linked SUPI information associated with the User Identifier.

8) step 8

SMF can query NRF to select UDM storing user ID profile. SMF can obtain user ID profile from selected UDM by triggering Nudm_SDM_Get by providing user identifier. Based on received information, SMF can update QoS according to operator policy.

SMF may query NRF for UDM when there is no linked SUPI associated with the User Identifier.

9) step 9

SMF can notify PCF of user identifier by triggering Npcf_SMPolicyControl_Update. Based on the received user identifier, PCF can retrieve user identifier profile from UDR and apply user identifier-specific policy.

10) step 10

SMF can register a PDU session to notify UDM that a user identifier is using the PDU session. For example, SMF can send UDM a message containing information about a user identifier (User_Id#1).

According to the disclosure of this specification, different services and policies may be applied depending on the user using the terminal.

According to the disclosure of this specification, the following operations can be performed.

- When the user changes, the terminal can send the user identifier to AMF.

- Based on this, AMF can authenticate the user.

- If authentication is performed successfully, the terminal can be notified that authentication was performed successfully.

- If authentication fails, information notifying that authentication for the user has failed can be transmitted to the terminal. Based on this, the terminal can notify the user that user authentication has failed.

- Registration for a user identifier can be performed with the UDM of the user identifier or the UDM of the UE to manage information about the user identifier.

- AMF can transmit user identifier and/or user profile information to PCF, SMF, etc. Based on this, user-specific policies can be applied.

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 13 illustrates the AMF's procedure for disclosure of this specification.

1. AMF (Access Mobility Function) can receive a registration request message from UE (User Equipment).

The above registration request message may include an identifier of a specific user of the UE.

2. Based on the registration request message, the AMF can send a request message including information about the identifier to the UDM (Unified Data Management) for the UE.

3. Based on the above request message, the AMF can receive the profile of the specific user from the UDM.

4. Based on the above profile, the AMF can determine whether the specific user can receive service through the UE.

5. The AMF may send a registration approval message to the UE.

The above registration approval message may include information on whether the specific user is able to receive services through the UE.

i) the AMF determines that the specific user can receive service through the UE and ii) the profile includes a policy for the specific user, and may include a step of the AMF transmitting a policy update request including the policy to the PCF for the UE.

Based on the existence of a Packet Data Unit (PDU) session for the UE, the AMF may transmit an SM context message including information about the identifier to a Session Management Function (SMF) for the PDU session.

The above profile may contain a list of disallowed items.

The above list may include at least one Data Network Name (DNN) or at least one Single Network Slice Selection Assistance Information (S-NSSAI).

i) Based on the existence of a PDU session for said UE and ii) Based on the DNN or S-NSSAI in said list corresponding to said PDU session, said AMF may send a release request for said PDU session to the SMF for said PDU session.

The above registration request message may include an identifier of the UE.

The above request message may include information about the identifier of the UE.

The above registration request message may include information that the specific user uses the UE.

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 14 illustrates the SMF procedure for the disclosure of this specification.

1. The SMF (Session Management Function) can receive a request to create an SM context for a PDU (Packet Data Unit) session for a UE (User Equipment) from the AMF (Access Mobility Function).

2. Based on the above SM context creation request, the SMF can send an approval message for establishment of the PDU session to the AMF.

3. The SMF can receive an SM context update request for the PDU session from the AMF.

The above SM context update request may include information about an identifier of a specific user of the UE.

4. The SMF may send a first request message including the identifier to the UDM (Unified Data Management) for the UE.

5. Based on the first request message, the AMF can receive the profile of the specific user from the UDM.

6. The SMF may send a second request message including the identifier to a Policy Control Function (PCF) that manages the PDU session.

7. Based on the second request message, the SMF can receive policy information for the profile of the specific user from the PCF.

The drawings below are created to illustrate specific examples of the present specification. The names of specific devices or names of specific signals/messages/fields depicted in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the drawings below.

Figure 15 illustrates the UE's procedure for disclosure of this specification.

1. The UE (User Equipment) can determine that the user of the UE has changed to a specific user.

2. Based on the above decision, the UE can send a registration request message to the AMF.

The above registration request message may include an identifier of the specific user.

3. Based on the above registration request message, the UE can receive a second registration approval message from the AMF.

The above registration approval message may include information on whether the specific user is able to receive services through the UE.

The above registration request message may include an identifier of the UE.

The above registration request message may include information that the specific user uses the UE.

Below, a device for performing communication according to some embodiments of the present specification is described.

For example, a device may include a processor, a transceiver, and memory.

For example, a processor may be configured to be operatively coupled with a memory and a processor.

The operations performed by the processor include: AMF receiving a registration request message from a UE; The registration request message includes an identifier of a specific user of the UE, and based on the registration request message, the AMF transmits a request message including information about the identifier to a UDM for the UE; Based on the request message, the AMF receives a profile of the specific user from the UDM; Based on the profile, the AMF determines whether it is possible for the specific user to receive a service through the UE; and AMF transmitting a registration approval message to the UE, wherein the registration approval message may include information about whether it is possible for the specific user to receive a service through the UE.

Below, a processor of a device for providing communication according to some embodiments of the present specification is described.

The operations performed by the processor include: AMF receiving a registration request message from a UE; The registration request message includes an identifier of a specific user of the UE, and based on the registration request message, the AMF transmitting a request message including information about the identifier to a UDM for the UE; Based on the request message, the AMF receiving a profile of the specific user from the UDM; Based on the profile, the AMF determining whether it is possible for the specific user to receive a service through the UE; and AMF transmitting a registration approval message to the UE, wherein the registration approval message may include information about whether it is possible for the specific user to receive a service through the UE.

Below, a non-volatile computer-readable medium storing one or more commands for providing mobile communication according to some embodiments of the present specification is described.

According to some embodiments of the present disclosure, the technical features of the present disclosure may be implemented directly in hardware, software executed by a processor, or a combination of the two. For example, a method performed by a wireless device in wireless communication may be implemented in hardware, software, firmware, or any combination thereof. For example, the software may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or other storage media.

Some examples of storage media are coupled to the processor such that the processor can read information from the storage media. Alternatively, the storage media may be integral to the processor. The processor and the storage media may reside in an ASIC. In other examples, the processor and the storage media may reside as separate components.

Computer-readable media may include tangible and nonvolatile computer-readable storage media.

For example, nonvolatile computer-readable media can include random access memory (RAM), such as synchronization dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), read-only memory (EEPROM), flash memory, magnetic or optical data storage media, or any other media that can be used to store instructions or data structures. Nonvolatile computer-readable media can also include combinations of the above.

Additionally, the methods described herein can be realized at least in part by a computer-readable communication medium that carries or transmits code in the form of instructions or data structures and that can be accessed, read, and/or executed by a computer.

According to some embodiments of the present disclosure, a non-transitory computer-readable medium has one or more instructions stored thereon. The one or more instructions stored thereon can be executed by a processor of a base station.

The stored one or more commands include: AMF receiving a registration request message from a UE; the registration request message including an identifier of a specific user of the UE, and based on the registration request message, AMF transmitting a request message including information about the identifier to a UDM for the UE; based on the request message, AMF receiving a profile of the specific user from the UDM; based on the profile, AMF determining whether it is possible for the specific user to receive a service through the UE; AMF transmitting a registration approval message to the UE, wherein the registration approval message may include information about whether it is possible for the specific user to receive a service through the UE.

Below, a non-volatile computer-readable medium storing one or more commands for providing mobile communication according to some embodiments of the present specification is described.

This specification may have various effects.

For example, through the procedure disclosed in this specification, a new user of a terminal can receive services through the terminal.

The effects that can be obtained through specific examples of this specification are not limited to the effects listed above. For example, there may be various technical effects that a person having ordinary skill in the related art can understand or derive from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described in this specification, and may include various effects that can be understood or derived from the technical features of this specification.

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 and implemented as a device, and the technical features of the device claims of this specification may be combined and implemented as a method. In addition, the technical features of the method claims of this specification and the technical features of the device claims of this specification may be combined and implemented as a device, and the technical features of the method claims of this specification and the technical features of the device claims of this specification may be combined and implemented as a method. Other implementations are within the scope of the claims as follows.

Claims (14)

As a method, A step in which AMF (Access Mobility Function) receives a registration request message from UE (User Equipment); The above registration request message includes an identifier of a specific user of the UE, Based on the registration request message, the AMF transmits a request message including information about the identifier to the UDM (Unified Data Management) for the UE; A step of the AMF receiving a profile of the specific user from the UDM based on the request message; Based on the above profile, the AMF determines whether it is possible for the specific user to receive the service through the UE; comprising a step of the AMF transmitting a registration approval message to the UE; A method wherein the above registration approval message includes information on whether the specific user is able to receive service through the UE. In the first paragraph, A method further comprising the step of: i) the AMF determining that the specific user is able to receive service through the UE; and ii) the profile including a policy for the specific user, wherein the AMF transmits a policy update request including the policy to the PCF for the UE. In either of paragraphs 1 or 2, A method further comprising the step of: based on the existence of a Packet Data Unit (PDU) session for the UE, the AMF transmitting an SM context message including information about the identifier to a Session Management Function (SMF) for the PDU session. In either of paragraphs 1 or 2, The above profile contains a list of disallowed, The above list is a method including at least one Data Network Name (DNN) or at least one Single Network Slice Selection Assistance Information (S-NSSAI). In paragraph 4, A method further comprising the step of the AMF transmitting a release request for the PDU session to the SMF for the PDU session based on i) existence of a PDU session for the UE and ii) a DNN or S-NSSAI in the list corresponding to the PDU session. In any one of claims 1 to 5, The above registration request message includes the identifier of the UE, A method wherein the request message includes information about the identifier of the UE. In any one of claims 1 to 6, A method wherein the above registration request message includes information that the specific user uses the UE. As a method, A step in which the SMF (Session Management Function) receives a request for creating an SM context for a PDU (Packet Data Unit) session for a UE (User Equipment) from the AMF (Access Mobility Function); A step in which the SMF transmits an approval message for establishment of the PDU session to the AMF based on the SM context creation request; A step in which the SMF receives an SM context update request for the PDU session from the AMF; The above SM context update request includes information about the identifier of a specific user of the UE, The step of the SMF transmitting a first request message including information about the identifier to the UDM (Unified Data Management) for the UE; A step in which the SMF receives a profile of the specific user from the UDM based on the first request message; A step in which the SMF transmits a second request message including information about the identifier to a Policy Control Function (PCF) managing the PDU session; A method comprising the step of the SMF receiving policy information for the profile of the specific user from the PCF based on the second request message. As a method, A step in which a UE (User Equipment) determines that a user of the UE has changed to a specific user; Based on the above decision, the UE transmits a registration request message to an Access Mobility Function (AMF); The above registration request message includes an identifier of the specific user, Based on the registration request message, the UE comprises a step of receiving a registration approval message from the AMF, A method wherein the above registration approval message includes information on whether the specific user is able to receive service through the UE. In Article 9, A method wherein the above registration request message includes an identifier of the UE. In clause 9 or 10, A method wherein the above registration request message includes information that the specific user uses the UE. As an AMF (Access Mobility Function) that performs communication, At least one transmitter and receiver; comprising at least one processor, The operation performed by said at least one processor is an AMF method according to any one of claims 1 to 7. As a Session Management Function (SMF) that performs communication, At least one transmitter and receiver; comprising at least one processor, The operation performed by at least one processor is a SMF method according to claim 8. As a UE (User Equipment) performing communication, At least one transmitter and receiver; comprising at least one processor, A UE wherein the operation performed by at least one processor is a method according to any one of claims 9 to 11.