Communication related to dual steering

Abstract

One disclosure of the present specification (present disclosure) provides a method by which an AMF performs communication. The method may include the steps of: receiving a registration request message including a SUPI of a first UE from the first UE; transmitting a registration message including the SUPI of the first UE to a UDM; receiving subscriber information related to the first UE from the UDM; transmitting a registration acceptance message to the first UE; receiving a PDU session establishment request message from a second UE included in a device; and selecting an SMF for a second PDU session.

Description

Communication related to dual steering

[0001] This specification relates to mobile communications.

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

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

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

[0005] Dual steering, which uses two 3GPP access points simultaneously to provide services to terminals, is being discussed in 5GS. However, conventional technology has the problem of not being able to effectively support dual steering.

[0006] According to one embodiment of the present disclosure, a method for an AMF to perform communication is provided. The method may include: receiving a registration request message including a SUPI of a first UE from the first UE; transmitting a registration message including the SUPI of the first UE to a UDM; receiving subscriber information related to the first UE from the UDM; transmitting a registration acceptance message to the first UE; receiving a PDU session establishment request message for establishing a second PDU session from a second UE included in the device; and selecting an SMF related to the first PDU session as an SMF for the second PDU session.

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

[0008] According to one embodiment of the present disclosure, a method for performing communication by a device including at least one UE is provided. The method may include the steps of transmitting a registration request message including a SUPI of a first UE included in the device to an AMF; and transmitting a PDU session establishment request message for establishing a second PDU session of a second UE included in the device to the AMF.

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

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

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

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

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

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

[0015] Figure 7 is an example diagram showing an example of an architecture for implementing the concept of network slicing.

[0016] Figure 8 is an exemplary diagram showing another example of an architecture for implementing the concept of network slicing.

[0017] FIG. 9 illustrates an example of dual 5G satellite access according to one embodiment of the disclosure of the present specification.

[0018] FIG. 10 illustrates an example of traffic switching according to one embodiment of the disclosure of the present specification.

[0019] FIG. 11a illustrates a first example of multiple connections according to an embodiment of the disclosure of the present specification. FIG. 11b illustrates a second example of multiple connections according to an embodiment of the disclosure of the present specification. FIG. 11c illustrates a third example of multiple connections according to an embodiment of the disclosure of the present specification. FIG. 11d illustrates a fourth example of multiple connections according to an embodiment of the disclosure of the present specification.

[0020] FIG. 12 is an example of a single 3GPP access connection according to one embodiment of the disclosure of the present specification.

[0021] FIG. 13 is an example of a dual 3GPP access connection according to one embodiment of the disclosure of the present specification.

[0022] FIG. 14 illustrates a first embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0023] FIG. 15 illustrates a second embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0024] FIG. 16 illustrates a third embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0025] FIG. 17 illustrates an embodiment of Example 2-1 according to one embodiment of the second disclosure of the present specification.

[0026] FIG. 18 illustrates a first embodiment and / or a second embodiment of Example 2-2 according to one embodiment of the disclosure of the present specification.

[0027] FIG. 19 is an example of a dual-steer PDU session according to one embodiment of the disclosure of the present specification.

[0028] FIG. 20 illustrates an example of a dual-steer PDU session supporting non-3GPP access according to one embodiment of the disclosure of the present specification.

[0029] FIG. 21 illustrates a registration procedure of a dual-steering device according to one embodiment of the disclosure of the present specification.

[0030] FIG. 22 illustrates a procedure for establishing a dual-steer PDU session according to one embodiment of the disclosure of the present specification.

[0031] FIG. 23 illustrates an example of moving a leg of a dual-steer PDU session between 3GPP access and non-3GPP access according to one embodiment of the disclosure of the present specification.

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

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

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

[0035] 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.

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

[0037] 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."

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

[0039] 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”.

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

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

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

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

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

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

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

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

[0048] 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.

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

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

[0051] 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).

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

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

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

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

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

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

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

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

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

[0061] 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).

[0062] 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).

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

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

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

[0066] 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).

[0067] 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).

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

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

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

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

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

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

[0074] 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).

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

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

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

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

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

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

[0081] 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).

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

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

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

[0085] 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).

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

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

[0088] 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).

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

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

[0091] - AUSF (Authentication Server Function)

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

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

[0094] - USDF (Unstructured Data Storage Function)

[0095] - NEF (Network Exposure Function)

[0096] - I-NEF (Intermediate NEF)

[0097] - NRF (Network Repository Function)

[0098] - NSSF (Network Slice Selection Function)

[0099] - PCF (Policy Control Function)

[0100] - SMF (Session Management Function)

[0101] - UDM (Unified Data Management)

[0102] - UDR (Unified Data Repository)

[0103] - UPF (User Plane Function)

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

[0105] - AF (Application Function)

[0106] - UE (User Equipment)

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

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

[0109] - NWDAF (Network Data Analytics Function)

[0110] - CHF (CHarging Function)

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

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

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

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

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

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

[0117] 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.

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

[0119] - N1: Reference point between UE and AMF.

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

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

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

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

[0124] - N9: Reference point between two UPFs.

[0125] The following benchmarks illustrate the interactions that exist between NF services in NF.

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

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

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

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

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

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

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

[0133] - N14: Reference point between two AMFs.

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

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

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

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

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

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

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

[0141] - Initial registration for 5GS; or

[0142] - mobility registration update; or

[0143] - Periodic registration update; or

[0144] - Emergency registration

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

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

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

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

[0149] The registration request message may include AN parameters. For NG-RAN, the AN parameters include, for example, the 5G SAE temporary mobile subscriber identity (5G-S-TMSI) or globally unique AMF ID (GUAMI), the selected public land mobile network (PLMN) ID (or PLMN ID and network identifier (NID)), and the requested network slice selection assistance information (NSSAI). The AN parameters also include an establishment cause. The establishment cause provides the reason for requesting establishment of an RRC connection. Whether and how the UE includes the requested NSSAI as part of the AN parameters depends on the value of the access stratum connection establishment NSSAI inclusion mode parameter.

[0150] 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 the registration procedure is initiated because the UE moves, or the UE wants to update its capabilities or protocol parameters, or because 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 the registration procedure is initiated because the periodic registration update timer has expired), or an emergency registration (i.e., the UE is in restricted service state).

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

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

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

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

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

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

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

[0158] 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.

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

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

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

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

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

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

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

[0166] 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.

[0167] 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0196] Network Slice

[0197] Below, we explain network slicing to be introduced in next-generation mobile communications.

[0198] Next-generation mobile communications introduce the concept of network slicing to provide diverse services through a single network. Here, a network slicing refers to a combination of network nodes with the functions necessary to provide a specific service. The network nodes that make up a slice instance can be either hardware-independent or logically independent.

[0199] Each slice instance can be composed of any combination of nodes required to form the entire network. In this case, a single slice instance can provide services to a UE independently.

[0200] Alternatively, a slice instance may be composed of a combination of nodes within the network. In this case, the slice instance may not provide services to the UE independently, but may instead collaborate with other existing network nodes to provide services to the UE. Furthermore, multiple slice instances may collaborate to provide services to the UE.

[0201] Slice instances differ from dedicated core networks in that the entire network, including the core network (CN) nodes and the RAN, can be separated. Furthermore, slice instances differ from dedicated core networks in that network nodes can be logically separated.

[0202] Note that for network slices, quotas can be used.

[0203] For example, a quota associated with a network slice may include a quota for a maximum number of UEs. The quota for the maximum number of UEs may refer to the maximum number of terminals that can simultaneously use the network slice. For example, each network slice information may include quota information for a maximum number of UEs (e.g., 10, 1,000,000, etc.).

[0204] For example, a quota associated with a network slice may include a quota for the maximum number of PDU sessions. The quota for the maximum number of PDU sessions may refer to the maximum number of concurrent PDU sessions supported by the network slice. For example, the maximum number of concurrent PDU sessions supported by the network slice may refer to the maximum number of PDU sessions that can be simultaneously established within a network slice associated with a Data Network Name (DNN) defined by the S-NSSAI.

[0205] In 5G mobile communications, network slice quota event notifications may be supported within a network slice. For example, event notifications regarding quotas related to a network slice may be supported. For example, an AF may request an event notification regarding quotas related to a network slice from 5GS. Then, the AF may receive quota notifications for attributes related to the network slice from 5GS. For example, the 5GS may notify the AF whether the quota for a specific attribute has reached a specified threshold. Then, the AF may influence 5GS routing decisions.

[0206] Figure 7 is an example diagram showing an example of an architecture for implementing the concept of network slicing.

[0207] As can be seen from Figure 7, a core network (CN) can be divided into multiple slice instances. Each slice instance can include one or more CP functional nodes and UP functional nodes.

[0208] Each UE can use a network slice instance suitable for its service through the RAN.

[0209] Unlike the example shown in FIG. 7, each slice instance may share one or more of the CP function nodes and UP function nodes with other slice instances. This is described below with reference to FIG. 8.

[0210] Figure 8 is an exemplary diagram showing another example of an architecture for implementing the concept of network slicing.

[0211] Referring to FIG. 8, multiple UP function nodes are clustered, and similarly multiple CP function nodes are clustered.

[0212] And, referring to FIG. 8, slice instance #1 (or referred to as instance #1) within the core network includes a first cluster of UP functional nodes. And, the slice instance #1 shares a cluster of CP functional nodes with slice #2 (or referred to as instance #2). The slice instance #2 includes a second cluster of UP functional nodes.

[0213] The illustrated NSSF selects a slice (or instance) that can accommodate the UE's service.

[0214] The illustrated UE can use service #1 through slice instance #1 selected by the NSSF, and can also use service #2 through slice instance #2 selected by the N.

[0215] 3GPP is discussing the Study on Multi-Access (DualSteer and ATSSS_Ph4) in Rel-19. This study explores solutions for steering, switching, and splitting UE traffic across two 3GPP access links. The use cases and service requirements are described in TR 22.841 V1.1.0, "Study on Upper Layer Traffic Steer, Switch, and Split over Dual 3GPP Access."

[0216] The objectives being studied are as follows:

[0217] The name of the study related to dual steering could be DualSteer.

[0218] The overall architecture and functional enhancements of 5GS to support DualSteer Devices can be discussed (see TS 22.261 V19.3.0 for the definition of a DualSteer Device). A DualSteer Device supports traffic steering and switching of user data (for different services) across two 3GPP access networks. A DualSteer Device can be (a) a single UE for asynchronous data transmission across both networks, or (b) two separate UEs for simultaneous data transmission across both networks. A subscriber to a DualSteer Device has two subscriptions / SUPIs from the same operator, sharing a single subscription profile. For a specific service, a DualSteer Device transmits all traffic for that service using only a single 3GPP access network at any given time.

[0219] The following scenarios may be considered:

[0220] 1. There can be two NR / 5GC accesses in a single PLMN (HPLMN or VPLMN). Each access can be an NR TN or NR NTN;

[0221] 2. There can be two NR / 5GC accesses from two different PLMNs (including two VPLMNs or a VPLMN and an HPLMN). Each access can be an NR TN or an NR NTN;

[0222] 3. There may be NR / 5GC access and E-UTRA / EPC access from two different PLMNs (including two VPLMNs or a VPLMN and an HPLMN);

[0223] 4. NR / 5GC access and E-UTRA / EPC access in a single PLMN (HPLMN or VPLMN);

[0224] 5. PNI-NPN (integrated with HPLMN or VPLMN) and PLMN access (TN / NTN with TN or NTN). This scenario assumes only non-simultaneous transmission.

[0225] For each of the above scenarios, improvements to the subscriber information aspect can be discussed.

[0226] It may be discussed whether this will affect the registration process for dual-steer devices.

[0227] Session management improvements and policies can be discussed as follows:

[0228] - It may be discussed whether and how HPLMN may improve the network policies it provides within dual-steer devices and networks to support dual-steer devices.

[0229] - Whether and how to improve session management procedures for initial steering and potential subsequent switching can be discussed. Traffic policy is entirely controlled by the HPLMN. Data anchoring is assumed in the HPLMN, and can be assumed in the PNI-NPN when PNI-NPN and PLMN are used together. In this case, how to select a PSA UPF in the HPLMN can be discussed so that traffic between 3GPP accesses can be routed to the same PSA UPF during a transition for a potential switching target session.

[0230] The study related to dual steering includes a gap analysis regarding the support of use cases identified by existing service requirements and functions, including the potential applicability of existing multi-NW requirements (e.g., TS 22.261 V19.3.0 Sections 6.1, 6.3, 6.18, 6.41).

[0231] An example use case for TR 22.841 V1.1.0 is as follows:

[0232] Describes an example of a dual 5G satellite access use case in a maritime scenario.

[0233] This use case describes a scenario where an autonomous ship is remotely controlled from shore. The ship has UEs served by two satellite RANs (GEO and LEO) belonging to the same PLMN managed by a 5G satellite operator. The ship's UEs have a single PLMN subscription.

[0234] Dual 5G satellite access will be deployed to accommodate the massive data traffic for remote control operations. To improve the performance of autonomous ship operations, delay-sensitive applications (e.g., remote control operations, collision / accident prevention, emergency management, etc.) will utilize LEO satellite links, which have lower UE-to-ground propagation delays than GEO satellite links (LEO up to 30 ms vs. GEO up to 280 ms, TS 22.261 V19.3.0, Section 7.4.1). Other delay-sensitive applications (e.g., sensor data monitoring, video surveillance, etc.) can utilize GEO satellite links or aggregate traffic across both accesses.

[0235] The following prerequisites may apply for this use case:

[0236] An example of an autonomous ship is the Korean Autonomous Surface Ship (KASS). This autonomous ship can support dual 5G satellite connectivity (GEO and LEO).

[0237] UEs installed on autonomous ships have subscriptions to use GEO and LEO satellite services from 5G satellite operators.

[0238] UEs installed on autonomous ships register and connect to GEO and LEO satellite RANs.

[0239] According to the service agreement between the autonomous vessel management company and the 5G satellite operator, the 5G satellite network has the following policies for the autonomous vessel's UE:

[0240] - Data traffic for delay-sensitive applications is routed over LEO satellite links whenever available.

[0241] - Data traffic for delay-tolerant applications is aggregated over LEO and GEO satellite links.

[0242] For use cases related to autonomous ships, a service flow like the example below can be applied.

[0243] Referring to FIG. 9, a specific example of dual 5G satellite access in autonomous vessel operation is illustrated.

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

[0245] FIG. 9 illustrates an example of dual 5G satellite access according to one embodiment of the disclosure of the present specification.

[0246] 1. The autonomous vessel is at sea and can be remotely controlled by a shore control center. The autonomous vessel can have two active data sessions: one for remote control operations and one for sensor data monitoring. According to agreed-upon policies, remote control operation traffic (e.g., delay-sensitive traffic) is routed via LEO satellite links, while sensor data monitoring traffic (e.g., delay-tolerant traffic) is aggregated across LEO and GEO satellite links.

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

[0248] FIG. 10 illustrates an example of traffic switching according to one embodiment of the disclosure of the present specification.

[0249] The example in Figure 10 illustrates an example of traffic diversion due to a loss of connection with a LEO satellite access network.

[0250] 2. If LEO satellite access becomes unavailable (e.g., due to loss of line of sight between the UE and the satellite), all traffic routed via LEO satellite access will be shifted to GEO satellite access while maintaining data session continuity. Applications for ship remote control (delay-sensitive) will detect increased communication latency and adjust their operations accordingly.

[0251] 3. After a while, LEO satellite access becomes available again. Therefore, the traffic distribution between the two satellite accesses returns to the state shown in step 1 of Figure 9.

[0252] The postconditions are as follows: the remote control center controls the autonomous ship throughout the route, and the autonomous ship successfully reaches its destination.

[0253] Describes an example of an existing feature that encompasses some or all of the use case functionality.

[0254] The ATSSS feature specified in TS 23.501 V17.2.2 section 5.32 supports dual user plane connectivity between a UE and a data network using one 3GPP access network and one non-3GPP access network.

[0255] 5G systems should be able to dynamically offload portions of traffic based on operator policies, taking into account traffic load and traffic type (e.g., offloading from 3GPP RATs to non-3GPP access technologies).

[0256] Depending on operator policy, 5G systems must be able to provide simultaneous data transmission over different access technologies (e.g., NR, E-UTRA, non-3GPP) to access one or more 3GPP services.

[0257] When a UE uses two or more access technologies simultaneously, the 5G system must be able to optimally distribute user traffic by selecting one of the access technologies in use, taking into account the service, traffic characteristics, radio characteristics, and the UE's movement speed.

[0258] 5G systems must support UEs with multi-radio and single-radio capabilities.

[0259] 5G systems must be able to provide services using satellite access.

[0260] A 5G system capable of satellite access must support a variety of configurations where the radio access network is a satellite NG-RAN, a non-3GPP satellite access network, or both.

[0261] Potential new requirements needed to support use cases could include, for example: The 5G system must support mechanisms to steer, split, and switch user plane traffic across two 5G satellite access networks belonging to the same PLMN, with the user plane traffic anchored to the 5GC.

[0262] A use case for NTN-based dual 3GPP access is described.

[0263] By integrating two 3GPP access links simultaneously, one of which is a non-terrestrial network, the following 5G services can be provided. This could be particularly useful in remote areas where bandwidth is limited or access links are unreliable:

[0264] - Expanded mobile broadband

[0265] - Ultra Reliable Service Communication

[0266] Many service scenarios (e.g., residential users in remote areas, users on vehicles, high-speed trains, ships, or airplanes) may benefit from combining terrestrial and non-terrestrial access, or from combining two types of non-terrestrial access (e.g., GeoStationary Orbit (GSO) and Non-GeoStationary Orbit (NGSO) based), to meet target service performance in terms of data rate and / or reliability.

[0267] In areas where service is unavailable, the bandwidth provided by terrestrial-based access (e.g., NR or LTE) may be limited at the cell edge. Adding NTN-based NG-RAN can help achieve the desired perceived data rates.

[0268] In some scenarios, such as on high-speed trains, the service area may not be completely uniform along the track, and the targeted reliability can be provided through multiple connections including NTN-based NG-RAN.

[0269] Therefore, one UE can be connected and served simultaneously by the following examples:

[0270] - One NTN-based 3GPP access and one terrestrial-based 3GPP access

[0271] - One NTN-based 3GPP access (NGSO) and another NTN-based 3GPP access (GSO).

[0272] - One NTN-based 3GPP access (NGSO) via two different satellites of the same constellation.

[0273] Dual access bonding can occur on the uplink, downlink, or both.

[0274] The same or different gNBs can serve NR cells via terrestrial access networks and satellite access networks (e.g., transparent payloads from onboard satellites).

[0275] NTN-based NG-RAN can refer to transparent payload satellites as well as regenerative payload satellites with, for example, some gNB functionality.

[0276] With reference to the following Figures 11a to 11d, examples of a) to d) are described.

[0277] a) Multi-connectivity including transparent payload NTN-based NG-RAN and terrestrial NG-RAN;

[0278] A UE connects to the 5GCN simultaneously via two access points (e.g., a transparent NTN-based NG-RAN and a cellular NG-RAN). It is assumed that the NTN gateway is located in the PLMN coverage area of ​​the cellular access network.

[0279] Referring to the examples of FIGS. 11a and 11b, an example of multi-connectivity including a transparent payload NTN-based NG-RAN and a terrestrial NG-RAN is described.

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

[0281] FIG. 11A is a first example of multiple connections according to one embodiment of the disclosure of the present specification.

[0282] In the example of Figure 11a, different operators may manage two PLMNs for multi-connectivity (assuming there is a business agreement between the two operators).

[0283] The example in Fig. 11a is an example of multi-connectivity including different PLMNs of transparent NTN-based NG-RAN and cellular NG-RAN.

[0284] As illustrated in Figure 11a, the UE may be connected to access based on a transparent NTN-based NG-RAN (e.g., access via a satellite, NTN gateway, gNB, or 5G CN of a first operator). Additionally, the UE may be connected to access based on a terrestrial NG-RAN connected to a 5G CN of a second operator.

[0285] Alternatively, as in the example of Figure 11b, the two accesses for multi-connectivity may be managed by the same operator.

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

[0287] FIG. 11b is a second example of multiple connections according to one embodiment of the disclosure of the present specification.

[0288] In the example of Figure 11b, PLMNs may be managed by the same operator. Figure 11b illustrates multi-connectivity (same PLMN) including a transparent NTN-based NG-RAN and a cellular NG-RAN.

[0289] b) Multi-connectivity including two transparent NTN-based NG-RAN accesses.

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

[0291] FIG. 11c is a third example of multiple connections according to one embodiment of the disclosure of the present specification.

[0292] The example in Fig. 11c shows multi-connectivity between two transparent NTN-based NG-RANs.

[0293] For example, referring to Figure 11c, multi-connectivity may include a combination of two transparent NTN-based NG-RANs (e.g., GSO and NGSO-based). This may be useful for providing service to UEs in areas where services are not available. The example of Figure 11c may utilize a relatively low-latency NGSO-based NG-RAN to support delay-sensitive traffic, and a GSO-based NG-RAN that provides additional bandwidth to meet target throughput requirements.

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

[0295] FIG. 11d is a fourth example of multiple connections according to one embodiment of the disclosure of the present specification.

[0296] Figure 11d shows an example of multi-connectivity between two regenerative NTN-based NG-RANs (e.g., onboard gNBs).

[0297] An example according to Fig. 11d is an example of a case where two regenerative NTN-based NG-RANs (gNB on board) are combined with an inter-satellite link via two satellites of the same constellation.

[0298] Note that Figure 11d is for illustrative purposes only. Other architectures (e.g., a split NG-RAN architecture between satellite and terrestrial) may be considered. SRI represents the satellite radio interface in Figure 11d.

[0299] Examples of preconditions relevant to this use case include:

[0300] There may be some coverage overlap between the two NG-RAN access links involved.

[0301] If the PLMN of both access links is the same, the UE connects to the 5GC that provides both access links.

[0302] 5GC knows the characteristics of each of the two access links.

[0303] When different PLMNs are used for each access link, the UE gains access to other networks through roaming agreements. Information about each access link's characteristics can be exchanged between the two networks.

[0304] The UE is in connected mode on one or more of the access links.

[0305] Slices can be deployed and managed on both access links.

[0306] An example service flow related to this use case is as follows:

[0307] A UE may establish a VoIP, video, or data service over a single 3GPP access link, but its QoS (e.g., throughput, latency, etc.) may be inadequate. If another 3GPP access link becomes available, it will be activated and combined with the first link to support the required QoS for the service.

[0308] Depending on the target QoS of the service, the user plane traffic of the connection can be intelligently steered, split and switched bidirectionally between two 3GPP NG-RAN access links based on the specific performance of each access link, such as latency, throughput, jitter and error rate.

[0309] QoS requirements for user plane traffic can be determined through specific policies associated with different data flows or different traffic types within the same data flow.

[0310] Traffic is steered / segmented across access links based on QoS requirements (e.g., latency, throughput, jitter, error rate), traffic characteristics, wireless link conditions, and the UE's mobility speed. For example, traffic requiring low latency may be best steered / segmented to the access link with the lowest latency characteristics.

[0311] In the event of a handover, temporary radio link failure, or congestion on one access link, user plane traffic can be switched to the remaining active access link. Once the radio link is re-established, user plane traffic is split / steered again across the two access links based on QoS.

[0312] Data volume and other traffic statistics reported on each access link are used for billing purposes.

[0313] According to the postcondition, due to appropriate steering, splitting and switching of user plane traffic, dual NG-RAN access connections with minimal NTNs can support targeted QoS that a single access cannot support.

[0314] Examples of existing features that partially or fully encompass the use case functionality include:

[0315] This use case can leverage and extend some of the existing service requirements, including:

[0316] - Multiple access technology (see TS 22.261 V19.3.0 S6.3)

[0317] - Multi-network connection and service provision between operators (refer to TS 22.261 V19.3.0 S6.18)

[0318] -NW slice (see S6.1 of TS 22.261 V19.3.0)

[0319] - Efficient user plane (see S6.5 of TS 22.261 V19.3.0)

[0320] Potential new requirements needed to support use cases include, for example:

[0321] Based on the use of at least one NR satellite RAT, the 5G system should be able to support simultaneous data transmissions by UEs associated with the same data session on two 3GPP 5G access networks, subject to operator policy. Based on the connection conditions (e.g., radio characteristics, mobility, congestion) of the two access networks and the UE's movement speed, the 5G system can optimally distribute user traffic between the two access networks.

[0322] When two 5G access networks are used simultaneously for the same data session, the 5G system can collect charging information for both links simultaneously.

[0323] Note that if the two 5G access networks belong to different PLMNs, single subscription and data anchoring on the HPLMN 5G CN is assumed.

[0324] Hereinafter, with reference to FIGS. 12 and 13, the use cases of the PLMN-to-PLMN scenario or the PLMN-SNPN scenario will be described.

[0325] This example scenario illustrates a stadium scenario where an ad-hoc / in-venue 5G NR deployment (high-capacity) is provided by one SNPN or PLMN network (MNO-A) and 5G NR coverage is provided by another PLMN outside the stadium (MNO-B). There is no network sharing between the two 5G networks. In this case, the MNO is the Mobile Network Operator.

[0326] The above example can be similarly applied to other local business locations such as campuses, companies, shopping malls, and factories.

[0327] MNO-B has a business and roaming partnership with MNO-A, which includes an agreement to lease additional capacity (from MNO-A) to provide ultra-broadband experiences to certain MNO-B special customers (e.g., "golden" customers). The agreement between MNO-A and B includes the ability for MNO-B users' data traffic to utilize additional NR connection links in PLMN-A, enabling them to connect at higher data rates (including anchoring and aggregation in the CN of the HPLMN). This capability is assumed to be supported by both PLMN CNs and the UEs (of the golden MNO-B users) and is associated with a set of traffic policies and conditions negotiated by the MNO. This capability is controlled by the HPLMN and can be configured (for UEs and CN entities).

[0328] Examples of preconditions relevant to this use case include:

[0329] Alice and Bob have arrived at a stadium to watch a concert by their favorite singer. Alice is a golden subscriber to MNO-B, and Bob is a "regular" MNO-B customer. Referring to the examples in Figures 12 and 13, Bob's UE, Bob UE, and Alice's UE, Alice UE, are depicted.

[0330] Both UEs are camped and registered with the MNO-B NW and are in the Idle state. Alice's UE supports dual (NR) radios.

[0331] Alice's specific traffic policy, part of the MNO-B "Golden User" contract, includes dual access usage for high-quality video calls, depending on QoS or traffic type. Otherwise, Alice's UE must use a single access / link from the MNO-B.

[0332] The service flow of FIG. 12 and FIG. 13 is as follows:

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

[0334] FIG. 12 is an example of a single 3GPP access connection according to one embodiment of the disclosure of the present specification.

[0335] Referring to Figure 12, Bob UE and Alice UE are illustrated. In Figure 12, both Bob UE and Alice UE are connected to a data network in PLMN-B based on 3GPP Access 1.

[0336] 1) Before the concert begins, Alice and Bob make a voice call to their best friend, describing the stadium atmosphere and promising to share a video of the concert later. Both are using a single 3GPP access connection (via PLMN-B).

[0337] Figure 12 is an example of an Alice & Bob data session using a single 3GPP access connection, according to step 1.

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

[0339] FIG. 13 is an example of a dual 3GPP access connection according to one embodiment of the disclosure of the present specification.

[0340] Referring to Figure 13, Alice UE uses both a connection based on 3GPP Access 1 and a connection based on 3GPP Access 2.

[0341] 2) When the concert begins, Alice and Bob decide to initiate a video call (with their friends) to share the live experience (with high-quality video settings). Alice's UE registers with NW-A and establishes a dual-access connection across the two networks. Bob's UE continues to use single-access through PLMN-B.

[0342] Figure 13 illustrates Alice's data session scenario using dual 3GPP access connections, according to step 2.

[0343] 3) Alice and Bob hang up the video call and continue enjoying the concert.

[0344] According to the use cases referenced in Figures 12 and 13, Alice's video quality was much better than Bob's video.

[0345] Describes an example of an existing feature that partially or fully encompasses the use case feature.

[0346] A) Steps 2 and 3 include a feature called Access Traffic Steering, Switching, and Splitting (ATSS). A similar feature described in this use case is supported by TS 25.301 V17.0.0 Section 5.3.2, but is limited to 3GPP access and non-3GPP dual access.

[0347] B) Existing service requirements (e.g., TS 22.261 V19.3.0 S6.18 and S6.41) capture some common multi-NW connectivity requirements and do not fully address or satisfy specific target use cases and capabilities. For example, in the prior art, for a user subscribed to a single operator, the use of multiple service networks operated by different operators is under the control of the home operator. For example, in the prior art, if multiple operators provide the same service, the UE should receive the subscribed service preferentially on the home operator's network, unless the home operator's network instructs otherwise. In this case, if the service is unavailable on the home operator's network (e.g., due to insufficient network coverage), the UE can receive the service on the network of another operator. In the prior art, the QoS provided on the partner operator's network for the same service may vary depending on the contract between the two operators and may differ from that provided on the domestic operator's network.

[0348] Examples of potential new requirements needed to support use cases include:

[0349] The 5G system shall be able to support mechanisms to coordinate, split and switch the user plane traffic of a UE for a single data session between two 5G networks belonging to two different PLMN operators (e.g., both using NR connectivity) or between an HPLMN and a SNPN.

[0350] It is assumed that an HPLMN subscription is used to access both networks, data traffic is anchored to HPLMN, and there are appropriate business agreements in place between the two network operators, including specific traffic routing policies based on geographic location, subscription, and traffic type.

[0351] Describes example use cases for UEs using terrestrial and satellite access.

[0352] Satellite access, known for its wide coverage, can improve service availability in areas with poor terrestrial access network coverage or poor radio conditions (e.g., multipath interference). When a fast-moving UE requests real-time services, such as IMS voice / video conferencing, it can simultaneously connect to the 5G system via terrestrial and satellite access, minimizing the impact of terrestrial network outages while providing continuous, stable service.

[0353] Eric is traveling to Saudi Arabia on business. He travels from Makkah to Madinah on the Haramain high-speed train, crossing 450 kilometers of desert at 300 kilometers per hour, to visit clients. He must handle urgent business via online video conferencing while on the move and resolve any issues before his arrival.

[0354] Examples of preconditions include:

[0355] TerrA's terrestrial access network offers good coverage in urban areas, suburban areas, and railway stops, but is limited in rural areas and deserts between stops. SatA's satellite access network (e.g., LEO) provides nationwide coverage, and SatA can provide its own communications services. Note that TerrA is a terrestrial network operator, while SatA is a satellite network operator.

[0356] Based on this Agreement, TerrA may direct, divert or split User traffic onto the data path of the SatA network and consolidate it into TerrA's 5GC, taking into account SatA's service availability or coverage.

[0357] Eric's UE (e.g. mobile phone or wireless network card) is capable of dual 3GPP radio access, including satellite access, and is subscribed to a service-approved TerrA (PLMN NetA).

[0358] By default, only terrestrial access functions are activated.

[0359] An example of a service flow is as follows:

[0360] Eric activates the UE's satellite access feature while waiting to check in at the Macca train station.

[0361] UEs register with NetA based on their service preferences (e.g., instant chat when terrestrial access is preferred, HD TV when satellite access is preferred) over terrestrial access and satellite access networks.

[0362] After Eric connects, the online video conference begins via the terrestrial access network. During the hour-long conference, UE traffic is autonomously steered, switched, or split between terrestrial and satellite network traffic paths with the help of TerrA's core network, and then converged on TerrA's core network to ensure uninterrupted video conference.

[0363] When the train reaches its destination, Eric disables satellite access and the UE updates its registration with NetA.

[0364] The postconditions associated with the use case are as follows: For example, the video conference is completed smoothly and without interruption. The user is unaware of any navigation, transitions, or splits during the video conference.

[0365] Examples of existing features that partially or fully encompass the use case functionality are described below.

[0366] 5G systems must support UEs with multi-radio and single-radio capabilities.

[0367] 5G systems must support the ability to steer UEs to select specific 3GPP access networks based on operator policy.

[0368] Depending on operator policy, 5G systems must be able to provide simultaneous data transmission over different access technologies (e.g., NR, E-UTRA, non-3GPP) to access one or more 3GPP services.

[0369] A UE can use two or more access technologies simultaneously. In this case, the 5G system must be able to optimally distribute user traffic by selecting one of the access technologies in use, taking into account factors such as the service, traffic characteristics, radio characteristics, and the UE's movement speed.

[0370] 5G systems must be able to support data transmission optimized for different access technologies (e.g., 3GPP, non-3GPP) for UEs simultaneously accessing the network through different connections.

[0371] Service continuity between 5G terrestrial access networks and 5G satellite access networks owned by the same operator or by different operators under contract must be supported by the 5G system.

[0372] Examples of potential new requirements needed to support use cases include:

[0373] For example, a 5G system should support a mechanism to coordinate user traffic of a UE between different 3GPP access networks and the core network for a UE using dual 3GPP access, taking into account service preferences, traffic characteristics, radio characteristics, QoS, etc. For example, a 5G system should support seamless service continuity by switching and splitting user traffic paths between different 3GPP access networks and the core network for a UE using dual 3GPP access (e.g., NR and satellite access) based on network availability, service preferences, etc.

[0374] Looking at the above use cases, services can be provided to the UE through two 3GPP accesses (or 3GPP access links). For example, the UE may receive services from two 3GPP accesses connected to a single CN (Core Network) (or from two 3GPP accesses belonging to the same network). Alternatively, the UE may receive services from two 3GPP accesses connected to different CNs (or from two 3GPP accesses belonging to different networks). In the above, the network may be a PLMN or an NPN.

[0375] As previously explained, a DualSteer Device may be a device with two subscriptions / SUPIs (Subscription Permanent Identifiers) that share a subscription profile from the same carrier. A DualSteer Device may be one UE or two UEs. For reference, in the disclosure of this specification, the terms DualSteer Device, Dual Steer Device, and Dual Steer Device may be used interchangeably.

[0376] For cases where devices have dual subscriptions / SUPIs associated with each other, such as dual-steer devices, it has not been previously defined how the devices register and / or establish PDU sessions.

[0377] In other words, a method needs to be defined for devices such as dual-steer devices to register each subscription / SUPI for each 3GPP access. Furthermore, a method needs to be defined for establishing PDU sessions based on each subscription / SUPI.

[0378] In various examples of the disclosure of this specification, specific methods are described to support a UE to receive dual steering service.

[0379] And, a PDU session can be established through two 3GPP accesses. For example, a PDU session established through two 3GPP accesses can be referred to as a Multi-Access (MA) PDU Session. Compared to an MA PDU session established through a 3GPP access and a non-3GPP access according to the prior art, the MA PDU session disclosed in the present specification can be a PDU session established through two 3GPP accesses. For some services, traffic can be steered, switched, and split through these MA PDU sessions. Furthermore, for some services, traffic can be transmitted through a PDU session formed through a single 3GPP access.

[0380] Regarding DualSteer, it is assumed that the UE has a single subscription. Conventionally, the UE registered with only one 5G CN for 3GPP access. However, to receive services through two 3GPP accesses, the UE may need to register with two 5G CNs. Furthermore, although a single 5G CN is used to receive services through two 3GPP accesses, the UE may register separately for each 3GPP access.

[0381] Additionally, if registered with two 5G CNs, selection and / or decision may be required as to which 5G CN to form a PDU Session for which service and to which 5G CN to transmit traffic.

[0382] I. First Disclosure of This Specification

[0383] A method for supporting Dual steering according to the first disclosure of this specification comprises a combination of one or more of the following actions / configurations / steps.

[0384] According to the first disclosure of this specification, dual steering may be supported. For example, dual steering may be applied to both a subscriber / subscription type with one subscription / SUPI for the same operator and a subscriber / subscription type with two subscriptions / SUPIs for the same operator.

[0385] In the latter case, a Dual Steer service may be provided based on a single UE, or a Dual Steer service may be provided based on two UEs. In the case of two UEs, since these UEs are included in a single Dual Steer Device (i.e., two UEs constitute a single Dual Steer Device), it is assumed that the two UEs can exchange information, perform coordination, etc. with each other.

[0386] This section describes an example of a subscriber / subscription type with two subscriptions / SUPIs for the same business. In this case, these subscriptions / SUPIs can be managed / stored in a related form (i.e., related relationship information).

[0387] For example, the network (e.g., UDM, UDR, etc.) can manage / store information about each subscription / SUPI and its associated counterpart subscription / SUPI (e.g., managed or stored as information such as Associated subscription / SUPI, Paired subscription / SUPI, Related subscription / SUPI, Connected subscription / SUPI, subscription / SUPI for DualSteer, etc.). Or, for two subscriptions / SUPIs, their association relationship based on identification information of the same value can be managed / stored (e.g., DualSteer-SUPI, Subscription Identifier for DualSteer, Subscription Pairing Identifier, subscriber identification information, etc.). Or, subscriber information for two subscriptions / SUPIs can be managed / stored within / under one subscriber information.

[0388] The above identification information can be unique within the operator network where the two subscriptions / SUPIs are registered. Additionally, for each subscription / SUPI, information related to which is primary (or main, or 1st, or prime, or master) and which is secondary (or sub, or 2nd) (e.g., correlation information between them) may also be managed / stored.

[0389] As described above, UE(s) can also manage / store correlation information for two subscriptions / SUPIs. Furthermore, UE(s) can also manage / store correlation information for two subscriptions / SUPIs as described above. A UE with a primary subscription / SUPI can be considered a primary UE, and a UE with a secondary subscription / SUPI can be considered a secondary UE.

[0390] Additionally, the UE may provide association information and / or correlation information for two subscriptions / SUPIs to the network (e.g., to AMF / PCF during registration, to SMF during PDU Session formation, etc.).

[0391] Additionally, a NF can obtain association information and / or correlation information for two subscriptions / SUPIs from another NF (e.g., AMF / SMF obtains from UDM, PCF obtains from UDR, etc.).

[0392] When a DualSteer Device consists of two UEs, the correlation and related information for the two subscriptions / SUPIs can be interpreted as information related to the correlation and related information for the two UEs. Alternatively, the correlation and related information for the two subscriptions / SUPIs can be interpreted as information related to the correlation and related information for the two UEs. Additionally, the primary subscription / SUPI can be interpreted as the primary UE, and the secondary subscription / SUPI can be interpreted as the secondary UE.

[0393] In this specification, UE (User Equipment) and terminal may be used as terms with the same meaning.

[0394] In this specification, the terms “Subscriber” and “User” may be used interchangeably.

[0395] In this specification, the terms network, Core Network (CN), 5G CN, 3GPP network, and 3GPP system may be used interchangeably.

[0396] In this specification, Home Network, Subscribed Network, and Non-roaming Network may be used as terms with the same meaning.

[0397] In this specification, the terms Visited Network, Non-subscribed Network, Roaming Network, and Non-home Network may be used interchangeably.

[0398] In this specification, the network may include a PLMN and a Non-Public Network (NPN).

[0399] In this specification, NPN may include both PNI-NPN (Public Network Integrated Non-Public Network) and SNPN (Stand-alone Non-Public Network), or may include only SNPN.

[0400] In this specification, PLMN may be interpreted to include PNI-NPN.

[0401] In this specification, the network identifier or network identification information may be a PLMN ID or a PLMN ID and NID (which is an SNPN ID).

[0402] In this specification, 3GPP access may be a 3GPP access based on the following RAT types defined in TS 29.571 V17.2.0. For example, 3GPP access may include or mean some or all of the following RAT types. RAT type may be used as a term synonymous with radio technology or access type or access link technology or RAT information or 3GPP access type / information or 3GPP RAT type / information.

[0403] Enumeration value Description"NR"New Radio"EUTRA"(WB) Evolved Universal Terrestrial Radio Access"WLAN"Untrusted Wireless LAN (IEEE 802.11) access"VIRTUAL"Virtual (NOTE 1 applied)"NBIOT"NB IoT"WIRELINE"Wireline access"WIRELINE_CABLE"Wireline Cable access"WIRELINE_BBF"Wireline BBF access"LTE-M"LTE-M (NOTE 2 applied)New Radio"EUTRA_U"(WB) Evolved Universal Terrestrial Radio Access in unlicensed bands"TRUSTED_N3GA"Trusted Non-3GPP access"TRUSTED_WLAN"Trusted Wireless LAN (IEEE 802.11) access"UTRA"UMTS Terrestrial Radio Access"GERA"GSM EDGE Radio Access Network"NR_LEO"NR (LEO) satellite access type"NR_MEO"NR (MEO) satellite access type"NR_GEO"NR (GEO) satellite access type"NR_OTHER_SAT"NR (OTHERSAT) satellite access type"NR_REDCAP"NR RedCap access type (see NOTE 3)NOTE 1: Virtual is used when the N3IWF does not know the access technology used for the untrusted non-3GPP connection.NOTE 2: This RAT type value is used only in the core network, when a Category M UE using E-UTRA has provided a Category M indication to the NG-RAN.NOTE 3: This RAT type value is only used in the core network and only when a UE using NR with reduced radio capabilities provides it to the NG-RAN.

[0404] The examples in Table 3 are examples of Enumeration: RatType. In the disclosure of this specification, 3GPP access may be based on the RAT type according to the examples in Table 3.

[0405] However, the RAT types according to the examples in Table 3 are only examples. The scope of the disclosure of this specification is not limited to the RAT types in Table 3. The RAT types according to the scope of the disclosure of this specification may be divided into various forms, more detailed forms, or multiple stages. For example, in the case of NR, the RAT types may be divided into FR (Frequency Range) 1 and FR2. As another example, in the case of NR, the RAT types may be divided into TN (Terrestrial Network) and NTN (Non-Terrestrial Network). Alternatively, in the case of NR, the RAT types may first be divided into TN and NTN, and then, if the RAT type is NTN, they may be further divided into GEO (Geosynchronous Orbit), MEO (Medium Earth Orbit), LEO (Low Earth Orbit), etc.

[0406] In this specification, 3GPP access may be used as a term with the same meaning as 3GPP RAT.

[0407] In this specification, the terms service, application and traffic may be used interchangeably.

[0408] In this specification, URSP and URSP rule(s) may be used as terms with the same meaning.

[0409] In the disclosure of this specification, for dual steer (or for a UE to receive dual steer services or transmit and receive traffic in a dual steer form), a UE needs to be connected to two 3GPP accesses. In this case, the base stations for the two 3GPP accesses may be the same or different, and the CNs for the two 3GPP accesses may be the same or different. Furthermore, when the CNs for the two 3GPP accesses are the same, the serving AMFs may be the same or different.

[0410] In this specification, Multi-Access (MA) may be used as a term with the same meaning as Dual-Access (DA), Dual Steer (DS), Dual Steering, Dual 3GPP Access, Multi 3GPP Access, etc.

[0411] In this specification, Multi-Access (MA) PDU Session may be used as a term with the same meaning as Dual-Access (DA) PDU Session, Dual Steer (DS) PDU Session, Dual Steering PDU Session, Dual 3GPP Access PDU Session, Multi 3GPP Access PDU Session, etc.

[0412] MA PDU Session can mean "A PDU Session that provides a PDU connectivity service, which can use one 3GPP access network at a time, or two 3GPP access networks simultaneously."

[0413] Alternatively, an MA PDU Session may be interpreted as two associated PDU Sessions or two paired PDU Sessions. It may be interpreted that an MA PDU Session / DualSteer is implemented / realized using two PDU Sessions. For example, Associated PDU Sessions or Related PDU Sessions or Connected PDU Sessions or Paired PDU Sessions or Dual Steered PDU Sessions may be used.

[0414] Hereinafter, descriptions of the same content as in the prior art will be omitted. The description will focus on the content proposed in the disclosure of this specification. For operations and procedures related to the 5G system, registration, PDU session, multi-access (MA) PDU session, URSP, steering of roaming, etc., reference will be made to TS 23.501 V18.0.0, TS 23.502 V18.0.0, TS 23.503 V18.0.0, and TS 23.122 V18.0.0.

[0415] The proposed dual steering support scheme in this specification focuses on the 5G CN, but this is merely an example. The disclosures in this specification can also be applied to core networks based on next-generation mobile communications, such as those using the EPC or 6G.

[0416] 1. Example 1-1

[0417] In Example 1-1, an example of network information related to Dual Steer is described.

[0418] Network information related to Dual Steer may be set or provided to a UE or Dual Steer Device. The network information related to Dual Steer may also be referred to as Dual Steer-related policy information.

[0419] A Dual Steer service may be provided based on two subscriptions / SUPIs. In this case, network information related to the Dual Steer may be configured or provided to both subscriptions / SUPIs. Alternatively, network information related to the Dual Steer may be configured / provided only to the primary subscription / SUPI. When a Dual Steer service based on two UEs is provided, network information related to the Dual Steer may be configured / provided to both UEs. Alternatively, network information related to the Dual Steer may be configured / provided only to the primary UE. Descriptions regarding network information related to the Dual Steer may be applied throughout this specification.

[0420] In this specification, Dual Steer may be used as a term synonymous with Dual Registration or Dual 3GPP access. Furthermore, Dual Steer-related (or supported or provided / enabled or service or use) may also be interpreted as Dual Registration-related (or supported or provided / enabled or service or use) or Dual 3GPP access-related (or supported or provided / enabled or service or use). This can be applied throughout this specification.

[0421] Network information related to Dual Steer may include one or more of the following information (e.g., I to V):

[0422] I) Information about the two networks where Dual Steer is provided / possible:

[0423] This information may be structured as a mapping between information about the first network and information about the second network. Alternatively, this information may be structured as a list / set of information about the second network for each piece of information about the first network. This information may also be information that considers / reflects priority / preference. Here, priority / preference can be expressed in various ways, such as by including priority / preference values ​​or by including information in order of highest priority. This can be applied throughout this specification.

[0424] In this information, information about each network (e.g., each of two networks) may include network identification information. Furthermore, information about each network (e.g., each of two networks) may optionally include 3GPP access(es) accessible / available for each network. If there are multiple 3GPP accesses, this information may also consider / reflect priority / preference.

[0425] The first and second networks may be the same network or different networks. If the first and second networks are the same network, they may contain only one network identifier.

[0426] This information may be structured to take into account / reflect that this information applies to a specific location and / or time.

[0427] For example, if the information about the two networks that the Dual Steer provides / can provide is in the form of a mapping, this information may consist of the following mappings (mapping list):

[0428] - Mapping between (PLMN#1, NR) and (SNPN#a, NR),

[0429] - Mapping between (PLMN#1, NR) and (PLMN#2, LEO),

[0430] - Mapping between (SNPN#b, NR) and (SNPN#c, GEO),

[0431] - Mapping between (PLMN#3, NR) and (PLMN#3, EUTRA), .. etc.

[0432] For example, if the information about the two networks that the above Dual Steer provides / can provide is in the form of a list / set, this information may be structured as the following list / set:

[0433] - List for (PLMN#1, NR): (SNPN#a, NR), (PLMN#2, LEO),

[0434] - List for (SNPN#a, NR): (PLMN#1, NR),

[0435] - List for (PLMN#2, LEO): (PLMN#1, NR),

[0436] - List for (SNPN#b, NR): (SNPN#c, GEO),

[0437] - List for (SNPN#c, GEO): (SNPN#b, NR),

[0438] - List for (PLMN#3, NR): (PLMN#3, EUTRA),

[0439] - List for (PLMN#3, EUTRA): (PLMN#3, NR), .. etc.

[0440] The information regarding the two networks for which the above Dual Steer is provided / possible may be divided into information indicating that at least one of the two networks is a Home Network and information indicating that both networks are Visited Networks. The distinction between the Home Network and the Visited Network may be explicit or implicit, and may be applied throughout this specification.

[0441] The information about the two networks for which the above Dual Steer is provided / possible may explicitly or implicitly include the following information. For example, the information about each network (i.e., the first network, the second network) may include whether it is valid, allowed, or preferred only for the primary subscription / SUPI, whether it is valid, allowed, or preferred only for the secondary subscription / SUPI, or whether it is valid, allowed, or preferred for both subscriptions / SUPIs.

[0442] II) Information about the network to which the UE is registered (e.g., the UE's primary (serving) network) and the secondary network where Dual Steer is provided / possible / available:

[0443] The above information may be determined based on the UE's primary (serving) network (network identification information and / or the 3GPP access accessed by the UE). Furthermore, the UE's location, mobility, movement pattern, movement direction, and capabilities (e.g., the types of 3GPP access available to the UE) may also be considered for this information.

[0444] The above information may be information about a second network. Alternatively, this information may be structured as a mapping between information about the first network and information about the second network. Alternatively, this information may be structured as a list of information about the first network and information about the second network. Alternatively, the information may be information that considers / reflects priorities / preferences.

[0445] Information about each of the above networks may include network identification information and, optionally, information about the 3GPP access(es) available / accessible for each network. If there are multiple 3GPP accesses, this information may also consider / reflect priority / preference.

[0446] The first and second networks may be the same network or different networks. If the first and second networks are the same network, only one network identifier may be included. Alternatively, the second network identifier may not be included.

[0447] The above information may be structured to take into account / reflect application to a specific location and / or time.

[0448] For example, if a UE registers with PLMN#1 via NR, information about a second network where dual steer is provided / possible may be configured as (SNPN#a, NR), (PLMN#2, LEO) and provided to the UE.

[0449] Information about the network registered by the UE (e.g., the first (serving) network of the UE) and the second network for which Dual Steer is provided / possible / available may be divided into two pieces of information as follows. For example, information may be divided into information that at least one of the two networks is a Home Network (or information in the case where at least one of the two networks corresponds to a Home Network) and information that both of the two networks are Visited Networks (or information in the case where both of the two networks correspond to Visited Networks).

[0450] When a Dual Steer service is provided via two subscriptions / SUPIs, information about the second network may be configured based on the subscription / SUPI registered by the UE. For example, information about the second network may be configured based on a subscription / SUPI that has not yet been registered.

[0451] Dual steer services can be provided via two UEs. In this case, while the first UE performs the registration procedure, capability information for the second UE (e.g., available 3GPP access types) can be provided to the network. Capability information for the second UE may also be utilized when configuring information for the second network.

[0452] The UE may first / prioritically attempt / perform registration via primary subscription / SUPI. Registration may be attempted / performed based on the device / UE's configuration, implementation, or network instructions / configurations.

[0453] III) Information on networks where Dual Steer is available / available:

[0454] The above information may be information that takes into account / reflects priorities / preferences.

[0455] The information about the above network may include network identification information. The information about the above network may also optionally include 3GPP access(es) accessible / available for each network. If there are multiple 3GPP accesses, the information about the above network may be information that considers / reflects priority / preference.

[0456] The above information may be structured to take into account / reflect application to a specific location and / or time.

[0457] For example, information about the networks where the Dual Steer is provided / available may be organized into a list such as the following:

[0458] - (PLMN#1, NR),

[0459] - (SNPN#a, NR),

[0460] - (PLMN#2, LEO),

[0461] - (SNPN#b, NR),

[0462] - (SNPN#c, GEO),

[0463] - (PLMN#3, NR),

[0464] - (PLMN#3, EUTRA), .. etc.

[0465] Information about the networks where the above Dual Steer is provided / available may be divided into information about the Home Network and information about the Visited Network.

[0466] Dual steer service may be provided via two subscriptions / SUPIs. In this case, information regarding the networks on which Dual Steer is provided / available may be configured / configured / provided for each subscription / SUPI. In addition, the information regarding the networks on which Dual Steer is provided / available may explicitly or implicitly include the following information. For example, each information may include whether it is valid, permitted, or preferred only for the primary subscription / SUPI, whether it is valid, permitted, or preferred only for the secondary subscription / SUPI, or whether it is valid, permitted, or preferred for both subscriptions / SUPIs.

[0467] IV) Information indicating that use of Dual Steer is authorized / allowed / available.

[0468] V) DNN and / or S-NSSAI / slice information for which Dual Steer can be provided

[0469] Network information related to Dual Steer, as described above based on various examples (e.g., Information I to V), may be set / provided along with valid time information and / or region / location information. For example, region / location information may take various forms, such as cell information, TA (Tracking Area) information, base station information, geo-area information, and address information. This can be applied throughout this specification.

[0470] In the network information related to the above Dual Steer, whether the network supports Dual Steer or Dual Registration may also be set / provided for each network. The support may be expressed as supported / not supported, or as supported only for supported networks, or as not supported only for unsupported networks. For example, the fact that the network supports Dual Steer or Dual Registration may be interpreted as the network's AMF supporting the Dual Steer or Dual Registration function / feature.

[0471] The methods / procedures for configuring or providing network information related to Dual Steer to a UE may vary. For example, one or more of the following methods / procedures 1) to 5) may be used. When receiving Dual Steer services via two subscriptions / SUPIs, the primary subscription / SUPI and / or secondary subscription / SUPI information may be considered / reflected, or may be based on such correlation information, for the configuration / provisioning according to 1) to 5) below:

[0472] 1) Network information related to Dual Steer can be set (e.g., pre-configured) in the UE.

[0473] 2) Based on the SoR (Steering of Roaming) procedure, network information related to Dual Steer can be provided to the UE:

[0474] For example, the UDM can provide the above information to the UE. For the SoR procedure, refer to Annex C (normative): Control plane solution for steering of roaming in 5GS of TS 23.122 V18.0.0. A similar procedure can be defined and used instead of the SoR procedure itself.

[0475] When using the SoR procedure, the UDM may provide the SoR AF with various information that the SoR AF requires to create / configure / update network information related to the Dual Steer. For example, the various information may include information about the network / access registered by the UE or DualSteer Device, information about the relationship between two subscriptions / SUPIs of the DualSteer Device, information about the correlation between two subscriptions / SUPIs of the DualSteer Device, information about whether the UE or DualSteer Device uses / allows DualSteer, location information of the UE or DualSteer Device, etc.

[0476] Alternatively, the SoR AF may directly request information about the UE from the UDM. The information directly requested by the SoR AF may include, for example, information about the network / access registered by the UE or DualSteer Device, information about the correlation between two subscriptions / SUPIs of the DualSteer Device, information about the correlation between two subscriptions / SUPIs of the DualSteer Device, information about whether the UE or DualSteer Device uses / allows DualSteer, and location information of the UE or DualSteer Device. The SoR AF may request this information from the UDM and receive information from the UDM. This means that when the SoR AF requests a subscription for the UE from the UDM, the UDM may also provide information related to DualSteer to the SoR AF, or the SoR AF may directly request information related to DualSteer from the UDM.

[0477] 3) Based on the UE policy delivery procedure, network information related to Dual Steer can be provided to the UE:

[0478] For example, the PCF (specifically, the UE policy PCF or UE PCF) can provide the above information to the UE. For the UE policy delivery procedure, refer to 4.2.4.3 UE Configuration Update procedure for transparent UE Policy delivery in TS 23.502 V18.0.0. The operation of providing network information related to Dual Steer through the UE policy delivery procedure can be performed after the UE performs the registration procedure. Alternatively, the operation of providing network information related to Dual Steer through the UE policy delivery procedure can be performed based on the UE requesting the above information.

[0479] 4) Based on the registration procedure, network information related to Dual Steer can be provided to the UE:

[0480] For example, the AMF may provide the above information to the UE. For the registration procedure, reference may be made to the registration procedure based on FIGS. 5 and 6.

[0481] 5) Network information related to Dual Steer can be provided to the UE based on the UCU (UE Configuration Update) procedure:

[0482] For example, the AMF may provide the above information to the UE based on the UCU procedure. For the UCU procedure, refer to 4.2.4.2 UE Configuration Update procedure for access and mobility management related parameters in TS 23.502 V18.0.0.

[0483] As described above, one or more of procedures 1) to 5) may be performed.

[0484] The times / points when network information related to Dual Steer is set or provided to a UE or DualSteer Device may vary. Network information related to Dual Steer may be set or provided to a UE or DualSteer Device based on one or more of the following times / points. However, the following times and / or cases are merely examples, and the scope of the disclosure herein is not limited thereto. For example, if the network determines that it is necessary to update / provide network information related to Dual Steer to a UE or DualSteer Device, the network may provide the information to the UE:

[0485] a) If the UE or DualSteer Device has performed the registration procedure:

[0486] The above registration procedure may include all or some of the forms / types of registration procedures listed in 4.2.2.2.1 General of TS 23.502 V18.0.0, such as Initial Registration, Mobility Registration Update, Periodic Registration Update, etc., and registration procedures based on FIGS. 5 and 6.

[0487] b) When a serving network is created or added to the UE or DualSteer Device.

[0488] c) When the serving network for the UE or DualSteer Device changes.

[0489] d) If the serving network is deregistered or removed from the UE or DualSteer Device.

[0490] e) If 3GPP access is created or added to the UE or DualSteer Device.

[0491] f) If the 3GPP access of the UE or DualSteer Device is changed.

[0492] g) If 3GPP access of the UE or DualSteer Device is removed.

[0493] h) When handover of UE or DualSteer Device is performed

[0494] i) When performing a Service Request from a UE or DualSteer Device

[0495] j) If the location information of the UE or DualSteer Device has changed;

[0496] Below, examples of various information / reasons why the network provides network information related to Dual Steer to the UE or DualSteer Device are described.

[0497] For example, a network may provide network information related to Dual Steer to a UE or Dual Steer Device based on various information / reasons. For example, the information and / or reasons listed below may apply, but are merely examples. The scope of the disclosure herein is not limited by the following information and / or reasons:

[0498] i) The UE informs the network that it supports Dual Steer:

[0499] A UE can signal to the network that it supports Dual Steer in various ways and at various times. For example, the UE may signal to the AMF and / or the PCF and / or the UDM that it supports Dual Steer during or after registration. If the UE only notifies the AMF, the AMF may forward the information to the PCF. Additionally, the AMF may provide the UDM with information received from the UE. A UE Policy container may be used to notify the PCF that the UE supports Dual Steer. A SoR container may be used to notify the UDM that the UE supports Dual Steer. This can be applied throughout this specification. The UE may also signal to the network that it supports Dual Steer based on network information related to the Dual Steer. The network may also signal to the UE that it supports Dual Steer.

[0500] ii) The UE requests that network information related to Dual Steer be provided.

[0501] A UE can request information from the network at various times and in various forms. For example, the UE may notify the AMF and / or PCF during or after registration. Based on the network information related to Dual Steer, the UE may also request network information related to Dual Steer. The network may notify the UE that it can provide network information related to Dual Steer.

[0502] iii) The UE notifies the network that it wants to perform Dual Registration or requests dual registration.

[0503] At various times and in various forms, a UE may notify the network of its intention to perform Dual Registration or request Dual Registration. For example, a UE may notify the AMF and / or PCF during or after registration. A UE may also notify or request Dual Registration from the network based on network information related to Dual Steer. The network may notify the UE that it is capable of performing Dual Registration.

[0504] iv) Subscriber Information:

[0505] Subscriber information may be subscriber information related to Dual Steer. For example, the subscriber information may include one or more of the following examples: information indicating that the subscriber can receive Dual Steer service, information indicating that the Dual Steer service is authorized / allowed, DNN and / or S-NSSAI / slice information that can receive Dual Steer, information indicating that the subscriber is a Gold / premium subscriber, information regarding the correlation between two subscriptions / SUPIs when receiving Dual Steer service through two subscriptions / SUPIs, and information regarding the correlation between two subscriptions / SUPIs when receiving Dual Steer service through two subscriptions / SUPIs. However, the scope of the disclosure of the present specification is not limited thereto. The subscriber information may be stored in an NF such as a UDM or UDR.

[0506] v) Local policy, operator policy, local configuration, etc. set in the network or NF (Network Function).

[0507] vi) SLA (Service Level Agreement) with other networks that can provide Dual Steer

[0508] vii) Location information of UE or DualSteer Device

[0509] viii) Time information

[0510] Based on the various examples i) to viii) above, the network can provide network information related to Dual Steer to the UE or DualSteer Device.

[0511] The information in i) to iii) above may be interpreted as Dual Steer-related capability information of the UE. Alternatively, the information in i) to iii) may be provided because the UE has Dual Steer-related capability.

[0512] Network information related to Dual Steer can be transmitted to the terminal based on its capabilities. After receiving separate information indicating that the network allows / authorizes dual registration, the terminal can perform dual registration based on the network information related to Dual Steer.

[0513] For example, after the network transmits network information related to Dual Steer to the terminal, when certain conditions (e.g., when the terminal moves to a certain area) are satisfied, the network can transmit information allowing / authorizing the terminal to perform dual registration by taking subscriber information, etc. into consideration.

[0514] After a UE registers with a first network, it can register with a second network based on network information related to Dual Steer. When a Dual Steer service is provided using two UEs, after the first UE registers with the first network, the second UE can register with the second network based on network information related to Dual Steer.

[0515] The operation / procedure for registering a UE (or a second UE) with a second network may include an operation / procedure for determining / selecting a second network based on network information related to Dual Steer. In addition, the operation / procedure for registering with a second network may include an operation for determining / selecting 3GPP access of the second network based on network information related to Dual Steer, an operation / procedure for selecting access, or an operation / procedure for cell selection.

[0516] In the above, the first network and the second network may be the same network or different networks. In the former case, registering with the second network may mean registering with the first network, i.e., the same network. In this case, the serving AMF for the two registrations may be the same or different. Registering with the second network may mean performing a registration procedure or performing a procedure (newly defined procedure and / or NAS message) to add a second (serving) network / 3GPP access. Registration through two 3GPP access / networks may be referred to as dual registration. This can be applied throughout this specification.

[0517] Hereinafter, a first embodiment of the first disclosure of the present specification will be described with reference to FIG. 14.

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

[0519] FIG. 14 illustrates a first embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0520] The first embodiment according to FIG. 14 shows an example of providing network information related to Dual Steer to a UE using the SoR (Steering of Roaming) procedure. Hereinafter, the contents / matters proposed in this specification will be described, focusing on the differences between the registration procedure according to FIGS. 5 and 6 and the SoR procedure (see Annex C (normative): Control plane solution for steering of roaming in 5GS of TS 23.122 V18.0.0).

[0521] For reference, in the example of Figure 14, Serving Network#1 may be either a Home Network or a Visited Network.

[0522] 1~2. The UE initiates a registration procedure with the first network via the first 3GPP access. For example, the UE transmits a Registration Request message. At this time, the UE may include one or more of the information in i) to iii) above in the Registration Request message.

[0523] 3. The AMF performs a registration with the UDM. At this time, the AMF may provide the RAT type for the first 3GPP access to the UDM as part of the 3GPP access information. The UDM may also store the RAT type. The AMF may also provide the UDM with one or more of the information i) to iii) provided by the UE.

[0524] 4. UDM responds to AMF's register.

[0525] 5~6. AMF can obtain subscriber information from UDM.

[0526] 7. AMF may subscribe to the UDM service to provide / be notified of changes in subscriber information.

[0527] 8. AMF sends a Registration Accept message to the UE.

[0528] 9. The UDM may decide to provide network information related to Dual Steer to the UE. To this end, the UDM may transmit network information related to Dual Steer to the AMF. This network information related to Dual Steer may be part of the SoR information or may be separate information.

[0529] 10. AMF can transmit network information related to Dual Steer received from UDM to UE.

[0530] 11. If UDM requests an acknowledgment, the UE may transmit an acknowledgment.

[0531] 12. AMF can forward acknowledgement from UE to UDM.

[0532] The UE may determine that it can register with the second network based on the network information related to the Dual Steer. When the Dual Steer service is provided using two UEs, the second UE may determine that it can register with the second network based on the network information related to the Dual Steer acquired by the first UE.

[0533] The above-described Figure 14 can also be applied to a method for providing network information related to Dual Steer to a UE using the Registration procedure. In this case, steps 9 through 12 do not need to be performed. Furthermore, if network information related to Dual Steer is provided to the UE through step 8, the UE may need to send a Registration Complete message to the AMF for a response / ACK.

[0534] Hereinafter, a second embodiment of the first disclosure of the present specification will be described with reference to FIG. 15.

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

[0536] FIG. 15 illustrates a second embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0537] According to a second embodiment according to the example of FIG. 15, network information related to Dual Steer can be provided to the UE using the UE policy delivery procedure. Hereinafter, the contents / matters proposed in this specification will be described, focusing on the differences between the registration procedure according to FIGS. 5 and 6 and the UE policy delivery procedure (see 4.2.4.3 UE Configuration Update procedure for transparent UE Policy delivery of TS 23.502).

[0538] In the example of Figure 15, Serving Network #1 can be either a Home Network or a Visited Network. If it is a Home Network, V-PCF is not involved.

[0539] 1~2. The UE initiates a registration procedure with the first network via the first 3GPP access. For example, the UE transmits a Registration Request message. At this time, the UE may include one or more of the information in i) to iii) above in the Registration Request message. In particular, to provide the information to the PCF, the UE may include the information in the UE Policy Container included in the Registration Request message.

[0540] 3. AMF sends a Registration Accept message to the UE.

[0541] 4~5. AMF performs UE Policy Association with PCF. At this time, the RAT type for the first 3GPP access may be provided to PCF and stored as part of the 3GPP access information.

[0542] 6~8. UE Policy Association between AMF and PCF is completed.

[0543] (H-)PCF may also decide to provide network information related to Dual Steer to the UE. To this end, (H-)PCF may transmit a message including the information to the AMF. For example, if Serving Network #1 is a Visited Network, the information may be transmitted to the AMF through steps 6 and 8, and if Serving Network #1 is a Home Network, the information may be transmitted to the AMF through step 8. The network information related to Dual Steer may be referred to as Dual Steer Policy, Dual Steer UE Policy, etc.

[0544] 9. AMF can transmit network information related to Dual Steer (i.e. Dual Steer UE Policy) received from PCF to UE.

[0545] 10. The UE can update / store the above UE policy provided by the PCF and send the result or response to the AMF.

[0546] 11~13. AMF can send results / responses from UE to PCF.

[0547] The UE may determine that it can register with the second network based on the network information related to the Dual Steer. When receiving the Dual Steer service using two UEs, the second UE may determine that it can register with the second network based on the network information related to the Dual Steer obtained by the first UE.

[0548] Hereinafter, a third embodiment of the first disclosure of the present specification will be described with reference to FIG. 16.

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

[0550] FIG. 16 illustrates a third embodiment of the first disclosure of the present specification according to one embodiment of the disclosure of the present specification.

[0551] The third embodiment illustrates an example in which a UE registers with a second network based on network information related to Dual Steer. When a Dual Steer service is provided using two UEs, the third embodiment can be interpreted as the second UE registering with the second network based on network information related to Dual Steer acquired by the first UE.

[0552] Hereinafter, the contents / matters proposed in this specification will be explained, focusing on the differences between the registration procedure according to FIGS. 5 and 6 and the registration procedure according to FIGS. 5 and 6 (see 4.2.2.2.2 General Registration of TS 23.502), the SoR procedure (see Annex C (normative): Control plane solution for steering of roaming in 5GS of TS 23.122), the UCU procedure (see 4.2.4.2 UE Configuration Update procedure for access and mobility management related parameters of TS 23.502), and the UE policy delivery procedure (see 4.2.4.3 UE Configuration Update procedure for transparent UE Policy delivery of TS 23.502).

[0553] In the example of Figure 16, Serving Network #1 and Serving Network #2 may both be Home Networks or Visited Networks. Alternatively, one serving network may be Home Network and the other may be Visited Network. The two serving networks may be the same (i.e., one) network or different networks.

[0554] In the example of Fig. 16, NG-RAN#a and NG-RAN#b may be the same NG-RAN or different NG-RANs. Additionally, AMF#a and AMF#b may be the same AMF or different AMFs.

[0555] 0A. The UE performs a registration procedure through the first 3GPP access and the first network.

[0556] The UE may also be provided with network information related to Dual Steer through the registration procedure.

[0557] 0B. The UE may be provided with network information related to Dual Steer based on the SoR procedure.

[0558] 0C. UE may also be provided with network information related to Dual Steer through the UCU procedure.

[0559] 0D. UE may also be provided with network information related to Dual Steer through the UE policy delivery procedure.

[0560] 1~2. The UE initiates a registration procedure with the second network through the second 3GPP access based on network information related to Dual Steer.

[0561] When receiving a Dual Steer service using two UEs, the second UE may initiate a registration procedure with the second network through the second 3GPP access based on the network information related to Dual Steer acquired by the first UE through step 0.

[0562] 3. AMF performs a registration with UDM. At this time, the RAT type for the second 3GPP access may be provided to UDM and stored as part of the 3GPP access information.

[0563] 4. UDM responds to AMF's register.

[0564] 5~6. AMF can obtain subscriber information from UDM.

[0565] 7. AMF may subscribe to the UDM service to provide / be notified of changes in subscriber information.

[0566] 8. AMF sends a Registration Accept message to the UE.

[0567] 2. Example 1-2

[0568] Example 1-2 illustrates an example of URSP information for a UE or DualSteer Device that can be served through two 3GPP accesses.

[0569] Describes URSP information (e.g., URSP information related to Dual Steer) for a UE or DualSteer Device that can receive services via two 3GPP accesses (or Dual 3GPP accesses). URSP information related to Dual Steer may indicate / indicate which 3GPP access / network a UE or DualSteer Device uses to receive a service (or for a Traffic Descriptor, or for a matching application, or for the traffic of a matching application) when registering with two 3GPP accesses / networks. URSP information related to Dual Steer may include one or more of the following information:

[0570] - Information about whether an MA PDU Session can be formed (or whether a service can be received via an MA PDU Session, or whether traffic can be transmitted using two 3GPP accesses / networks, or whether a service can be received using two 3GPP accesses / networks).

[0571] - Information on whether a PDU Session can be formed through the first network (or whether a service can be received through a PDU Session of the first network, or whether traffic can be transmitted through the first network, or whether a service can be received using the first network).

[0572] - Information on whether a PDU Session can be formed through a second network (or whether a service can be received through a PDU Session of a second network, or whether traffic can be transmitted through a second network, or whether a service can be received using a second network).

[0573] - Information on whether a PDU Session can be formed via the first 3GPP access (or whether a service can be received via the PDU Session of the first 3GPP access, or whether traffic can be transmitted via the first 3GPP access, or whether a service can be received using the first 3GPP access).

[0574] - Information on whether a PDU Session can be formed via the second 3GPP access (or whether a service can be received via the PDU Session of the second 3GPP access, or whether traffic can be transmitted via the second 3GPP access, or whether a service can be received using the second 3GPP access).

[0575] - Information on whether a PDU Session can be formed via the first subscription / SUPI (or the first UE) (or whether a service can be received via a PDU Session of the first network, or whether traffic can be transmitted via the first network, or whether a service can be received using the first network).

[0576] - Information on whether a PDU Session can be formed via a second subscription / SUPI (or a second UE) (or whether a service can be received via a PDU Session of the first network, or whether traffic can be transmitted via the first network, or whether a service can be received using the first network).

[0577] - Information on whether a PDU Session can be formed via the Primary Subscription / SUPI (or primary UE) (or whether a service can be received via a PDU Session of the primary network, or whether traffic can be transmitted via the primary network, or whether a service can be received using the primary network).

[0578] - Information on whether a PDU Session can be formed via a Secondary subscription / SUPI (or secondary UE) (or whether a service can be received via a PDU Session of the primary network, or whether traffic can be transmitted via the primary network, or whether a service can be received using the primary network).

[0579] For Dual Steer related URSP, existing URSP may be used, or existing URSP may be extended / modified. Alternatively, a new UE policy may be defined for Dual Steer (e.g., DualSteer UE policy, etc.).

[0580] In this specification, these are collectively referred to as URSP. When the existing URSP is extended / modified, one or more of the following parameters / information may be added to the Route Selection Descriptor (RSD) of the existing URSP (refer to 6.6.2 UE Route Selection Policy information of TS 23.503 V18.0.0), or the RSD may be extended / modified. Instead of utilizing the RSD, new information / descriptor may be defined and used. The parameters / information below may be added, extended / modified explicitly, implicitly, combined, or in a stepwise manner. When a Dual steer service is provided through two subscriptions / SUPIs, the parameters / information below may be set by considering / reflecting the primary subscription / SUPI and / or secondary subscription / SUPI information, or based on such correlation information. In addition, different parameters / information may be configured for the primary subscription / SUPI and the secondary subscription / SUPI. In addition, different parameters / information may be configured for the primary UE and the secondary UE. One or more of the following parameters / information may be added to the Dual Steer related URSP as RSD:

[0581] 1) Network preference is added to URSP:

[0582] Network preference can indicate / indicate whether the traffic of the matching application is preferred to be transmitted through the Home Network or the Visited Network. Alternatively, the Network preference can indicate / indicate whether the UE or Dual Steer Device prefers to establish a PDU Session for the matching application through the Home Network or the Visited Network. If the UE or Dual Steer Device is not registered to the preferred Network, a non-preferred Network (e.g., a non-preferred Network) can be used. For example, if the preferred network is VPLMN1, but the UE or Dual Steer Device is registered to VPLMN2, the Network preference can indicate whether traffic can be transmitted through VPLMN2. In this example, VPLMN2 can mean a non-preferred Network.

[0583] 2) Visited Network preference is added to URSP:

[0584] The Visited Network preference may indicate whether the matching application's traffic is preferred to be transmitted over the Visited Network. Alternatively, it may indicate whether the UE or Dual Steer Device prefers to establish PDU sessions for the matching application over the Visited Network. If the UE or Dual Steer Device is registered only on the Home Network, the Home Network may be used.

[0585] 3) Home Network preference is added to URSP:

[0586] The Home Network preference can indicate whether the matching application's traffic is preferred to be transmitted over the Home Network. Alternatively, it can indicate whether the UE or Dual Steer Device prefers to establish PDU sessions for the matching application over the Home Network. If the UE or Dual Steer Device is registered only on the Visited Network, the Visited Network can be used.

[0587] 4) Dual Steering preference is added to URSP:

[0588] The Dual Steering preference may indicate whether the traffic of a matching application is preferred to be transmitted via Dual Steering. Alternatively, it may indicate whether the UE or Dual Steer Device prefers to establish a PDU Session for a matching application via a MA PDU Session using two 3GPP accesses. If the MA PDU Session / DualSteer is implemented / realized using two PDU Sessions, the Dual Steering preference may be indicated through pairing information for the two PDU Sessions. For example, the PCF may inform the UE that it prefers to create an MA PDU Session for dual steer by including pairing information in the URSP. For example, when the UE establishes a PDU Session based on a URSP, it may inform the SMF and / or the PCF that the PDU Session is related to dual steer.

[0589] The pairing information for these two PDU Sessions can be used in place of or in conjunction with the Dual Steering preference information. Regarding the pairing information for the PDU Sessions, the following methods can be used:

[0590] A. Any form of identification information (e.g., integer value) such as Identifier can be used. For example, each URSP rule for two PDU Sessions can contain the same pairing identifier. The UE (if a Dual Steer Device includes two UEs, each UE) can provide the pairing identifier for the PDU Session to the SMF when creating the PDU Session. This allows the SMF / PCF to recognize that the two PDU Sessions are paired with each other and implement / realize an MA PDU Session / DualSteer.

[0591] B. Among the route selection components of a URSP rule, Network Slice Selection (which corresponds to either a single value or a list of S-NSSAI(s)) can be utilized. For example, each URSP rule for two PDU Sessions can include an S-NSSAI with the same Slice Differentiator (SD) value. For reference, an S-NSSAI can be configured as follows (refer to TS 23.501 V18.0.0):

[0592] - A Slice / Service type (SST), which represents the expected network slice behavior in terms of functionality and services;

[0593] - A Slice Differentiator (SD), optional information that complements the slice / service type to differentiate multiple network slices of the same slice / service type.

[0594] Based on the S-NSSAI of the PDU Session generated by the UE (each UE when the Dual Steer Device is composed of two UEs), the SMF / PCF can recognize that the two PDU Sessions are paired with each other and implement / realize MA PDU Session / DualSteer.

[0595] C. Among the Route selection components of the URSP rule, the DNN Selection (which corresponds to either a single value or a list of values ​​of DNN(s)) can be utilized. For example, each URSP rule for two PDU Sessions can include the same DNN. Based on the DNN of the PDU Session generated by the UE (each UE in case of a Dual Steer Device consisting of two UEs), the SMF / PCF can recognize that the two PDU Sessions are paired with each other and implement / realize MA PDU Session / DualSteer.

[0596] There may be a case where MA PDU Session / DualSteer is implemented / realized using two PDU Sessions, and a case where pairing information for two PDU Sessions is managed using a pairing identifier. In these two cases, the UE may provide the SMF with a pairing identifier for each PDU Session when creating each PDU Session. Through this, the SMF / PCF can recognize that the two PDU Sessions are paired with each other and implement / realize MA PDU Session / DualSteer. In the case where the pairing information for two PDU Sessions is managed using S-NSSAI information (e.g., SD value), the SMF / PCF can recognize that the two PDU Sessions are paired with each other and implement / realize MA PDU Session / DualSteer based on the S-NSSAI of each PDU Session created by the UE.

[0597] 5) The existing Access Type preference is extended / modified: The existing Access Type preference relates to the description "Indicates the preferred Access Type (3GPP or non-3GPP or Multi-Access) when the UE establishes a PDU Session for the matching application." For the Access Type preference, the description in 4) above can be made to indicate / point to it.

[0598] 6) 3GPP Access preference is added to URSP: This may indicate / indicate which 3GPP access(es) the traffic of the matching application is preferred to be transmitted through. Or it may indicate / indicate which 3GPP access(es) the UE or Dual Steer Device prefers to establish the PDU Session for the matching application through. In case of multiple 3GPP accesses, the 3GPP Access preference may be information in a form that considers / reflects priority / preference. In case of multiple 3GPP accesses, one 3GPP access may be configured for each RSD and the priority / preference may be reflected in the Route Selection Descriptor Precedence.

[0599] 7) Preferred Network(s) are added to the URSP: Preferred Network(s) can be one or more network identifiers. Preferred Network(s) can indicate / indicate which network(s) the matching application's traffic is preferred to be transmitted through. Alternatively, Preferred Network(s) can indicate / indicate which network(s) the UE or Dual Steer Device prefers to establish a PDU Session for the matching application. When there are two network identifiers, Preferred Network(s) can mean establishing a MA PDU Session or transmitting the matching application's traffic through it. On the other hand, when there is only one network identifier, Preferred Network(s) can mean establishing a PDU Session or transmitting the matching application's traffic through it. If the UE or Dual Steer Device is not registered to a Preferred Network, a Network other than the Preferred Network may be used.

[0600] When a Dual Steer service is provided using two subscriptions / SUPIs, the Dual Steer-related URSP may be configured / configured / provided for each subscription / SUPI. When a Dual Steer service is provided using two UEs, the Dual Steer-related URSP may be configured / configured / provided for each UE.

[0601] When a Dual Steer service is provided using two subscriptions / SUPIs, information regarding which subscription / SUPI the Dual Steer related URSP applies to (or applies to / applies to the primary subscription / SUPI, or applies to / applies to the secondary subscription / SUPI, or applies to / applies to all subscriptions / SUPIs) may be explicitly or implicitly included / expressed in each URSP rule. This information may also be explicitly or implicitly included / expressed in the URSP itself (i.e., equally applicable to all URSP rules being provided / updated).

[0602] The PCF may configure / update / generate Dual Steer-related URSP information in one or more of the following cases / time points (e.g., A) to E)). The updated URSP may then be provided to the UE or Dual Steer Device. However, this is not limited to cases / time points where the PCF recognizes / detects a change in the location information of the UE or Dual Steer Device. If the Dual Steer Device consists of two UEs, the following may be interpreted as referring to either one of the UEs or both UEs, depending on the situation:

[0603] A) When a UE or Dual Steer Device registers with the primary network, the PCF can configure / update / generate Dual Steer related URSP information:

[0604] The UE or Dual Steer Device may provide Dual Steer-related information (which may correspond to i) to iii) in "1. Example 1-1") to the network (AMF and / or PCF). Accordingly, the PCF may update Dual Steer-related URSP information to the UE or Dual Steer Device.

[0605] B) When a UE or Dual Steer Device registers with a second network, or a second serving network is created for the UE or Dual Steer Device, or a UE or Dual Steer Device adds a second serving network, the PCF can configure / update / generate Dual Steer related URSP information:

[0606] At this time, the UE or Dual Steer Device may provide Dual Steer-related information (which may correspond to i) to iii) in "1. Example 1-1") to the network (AMF and / or PCF). Accordingly, the PCF may update Dual Steer-related URSP information to the UE or Dual Steer Device.

[0607] C) If one or more of the two serving networks of a UE or Dual Steer Device changes, the PCF may configure / update / generate Dual Steer related URSP information.

[0608] D) If one or more of the two 3GPP accesses to which a UE or Dual Steer Device is connected is changed, the PCF can configure / update / generate Dual Steer related URSP information.

[0609] E) If one of the two serving networks of a UE or Dual Steer Device is deregistered or removed, the PCF may configure / update / generate Dual Steer related URSP information.

[0610] Various information may be used to determine whether the PCF can update / provide Dual Steer-related URSP information to the UE or Dual Steer Device. For example, one or more of the following information may be used: information i) to viii) of the above "1. Example 1-1"; information indicating that the UE or Dual Steer Device supports or requests Dual Steer-related URSP provided to the PCF; and information indicating that Dual Steer-related URSP in subscriber information should be provided. However, the scope of the disclosure of the present specification is not limited thereto. Various information may be used, such as information set in the PCF, information obtained from another NF (including AF), etc.

[0611] To configure / update / generate URSP information related to Dual Steer, the PCF may consider the first (serving) network of the UE or Dual Steer Device (network identification and / or 3GPP access accessed by the UE) and / or the second (serving) network of the UE or Dual Steer Device (network identification and / or 3GPP access accessed by the UE(s)). In addition, the PCF may also consider the location, mobility, movement pattern, movement direction, etc. of the UE(s).

[0612] The configuration / update / generation and provision of URSP is performed by the PCF (i.e., H-PCF) in the Home Network. In this case, there may be no connection / interface / reference point between the UE's Visited Network and the H-PCF (for example, if the Visited Network is an SNPN). If the UE's serving network is not connected to the H-PCF, a UE Policy Association cannot be formed with the serving network, and thus situations A) to E) described above may occur in a network that is not connected to the H-PCF. In this case, a problem may arise in which the H-PCF cannot recognize this situation. To solve this, the PCF can recognize / determine whether situations A) to E) have occurred in a network that is not connected to the H-PCF by one or more of the following methods:

[0613] - If A) to E) above occur in a network that is not connected to H-PCF, the UE can notify this through a network that is connected to H-PCF. At this time, the UE can notify one or more of the network identification information, 3GPP access information, and UE location information corresponding to A) to E). In addition, for other networks / 3GPP accesses that do not correspond to A) to E), the UE can notify one or more of the network identification information, 3GPP access information, and UE location information. The above information can be notified to the AMF and / or PCF.

[0614] - When the UE's serving AMF stores / updates one or more of network identification information, 3GPP access information, and UE location information in the UDM, the UDM can notify / provide this to the H-PCF. The H-PCF can receive the notification / provision from the UDM or through the UDR. The H-PCF can also subscribe to the above notification / provision service.

[0615] - H-PCF can obtain information about the UE's serving network by subscribing to the UE reachability event notification service with UDM.

[0616] URSP updates to a UE or Dual Steer Device may be performed via a newly registered / added network / 3GPP access (which may be a primary network / 3GPP access or a secondary network / 3GPP access). However, the newly registered / added network may not be the Home Network or there may be no connection / interface / reference point between the H-PCF and the newly registered / added network. In this case, if another network registered by the UE is the Home Network or there is a connection / interface / reference point with the H-PCF, the URSP update may be performed via the other network.

[0617] Based on the URSP, the UE or Dual Steer Device can establish a PDU Session over a preferred network and / or 3GPP access. Alternatively, the UE or Dual Steer Device can decide, based on the URSP, which service to receive (or to transmit traffic of an application mapped / matched to a certain Traffic Descriptor) using the PDU Session with user plane connection. In addition to the conditions for (re-)evaluating the conventional URSP (see 6.6.2.3 UE procedure for associating applications to PDU Sessions based on URSP of TS 23.503 V18.0.0), the UE or Dual Steer Device can additionally (re-)evaluate the validity of the URSP under the following conditions:

[0618] - After registering in a secondary network, or after a secondary serving network is created, or after a secondary serving network is added, the validity of a URSP can be (re-)evaluated.

[0619] - If one or more of the two serving networks changes, the validity of the URSP may be (re-)evaluated.

[0620] - If one or more of the two 3GPP accesses changes, the validity of the URSP may be (re-)evaluated.

[0621] A UE or Dual Steer Device can form a MA PDU Session based on URSP. Also, based on URSP, the UE or Dual Steer Device can form a PDU Session via a first network / 3GPP access. Also, based on URSP, the UE or Dual Steer Device can form a PDU Session via a second network / 3GPP access. This operation can be performed when the UE or Dual Steer Device registers via one network / 3GPP access or when it registers via two networks / 3GPP accesses.

[0622] As a result of the above URSP (re-)evaluate, an already established PDU Session may exist in a non-preferred or less preferred network / 3GPP access. In this case, the UE or Dual Steer Device may move to the preferred network and / or 3GPP access, or establish a new PDU Session via the preferred network and / or 3GPP access.

[0623] The above Dual Steer related URSP may include VPLMN specific URSP Rules. It may also include non-subscribed SNPN specific URSP Rules.

[0624] When a UE or Dual Steer Device registers with two 3GPP accesses / networks, two different PCFs (i.e., UE Policy PCF or UE PCF) may be selected. In this case, the two PCFs can provide URSP to the UE or Dual Steer Device in a form that is aligned / synchronized / coordinated with each other. The alignment / synchronization / coordination can be performed through UDR or directly between PCFs. Therefore, only one PCF can provide URSP to the UE or Dual Steer Device. Here, one PCF can be determined through negotiation between the two PCFs, by local policy / configuration, or by the PCF with which UE Policy Association is performed first.

[0625] If both PCFs provide URSPs to the UE or Dual Steer Device, these URSPs are assumed to be aligned / synchronized / coordinated. Therefore, it is assumed that the UE or Dual Steer Device can always use the most recently / last provided URSP.

[0626] Alignment / synchronization / coordination between PCFs can be achieved, for example, by having a PCF provide information about its associated 3GPP accesses / networks, etc., to the other PCF to configure / update / generate a URSP. Alternatively, one PCF can configure / update / generate a URSP based on information from two 3GPP accesses / networks, etc., and provide this to the other PCF.

[0627] Even if a UE registers with two 3GPP access / networks, it may be possible to select only one PCF. This can be accomplished using one or more of the following methods:

[0628] - The AMF of the first network to which the UE is registered selects a PCF (if roaming, H-PCF is selected) and stores it in the UDM. Then, the AMF of the second network to which the UE is registered selects a PCF based on the information stored in the UDM (if roaming, H-PCF is selected).

[0629] - One of the two PCFs requests the V-PCF or AMF to change the UE Policy Association to another PCF. The other PCF ultimately becomes the PCF that maintains the UE Policy Association.

[0630] - PCF information is stored / set in subscriber information and the same PCF is selected based on this.

[0631] When a dual-steer service is provided using two UEs, a single PCF may be selected for each UE. One or more of the following methods may be used for this purpose:

[0632] - The AMF of the first network to which the first UE is registered selects a PCF (if roaming, H-PCF is selected), and the AMF stores information related to the PCF in the UDM. Then, the AMF of the second network to which the second UE is registered selects a PCF (if roaming, H-PCF is selected) based on the information stored in the UDM.

[0633] - One of the two PCFs requests the V-PCF or AMF to change the UE Policy Association to another PCF. The other PCF ultimately becomes the PCF that maintains the UE Policy Association.

[0634] - PCF information is stored / set in subscriber information and the same PCF is selected based on this.

[0635] II. Second Disclosure of this Specification

[0636] A DualSteer device is defined. A DualSteer device assumes that a single device has two subscriptions / SUPIs from the same operator. Therefore, a terminal (e.g., a DualSteer device) can perform registration through two subscriptions, each with its own 3GPP access. However, since a DualSteer device uses different subscriptions, a method for supporting MA PDU sessions using two subscriptions is required to perform traffic switching / steering in the network. The second disclosure of this specification proposes a method for supporting MA PDU sessions.

[0637] The method for creating a PDU Session in dual 3GPP access proposed in the second disclosure of this specification consists of a combination of one or more of the following operations / configurations / steps.

[0638] In this specification, Application Function (AF) and Application Server (AS) are used interchangeably.

[0639] The methods presented in this specification may be performed or used in combination or complementary manner.

[0640] In the explanation below, PLMN can be interpreted as SNPN, Equivalent PLMN, etc., and SNPN can be interpreted as PLMN.

[0641] 1. Example 2-1

[0642] Example 2-1 illustrates an example of the registration procedure performed by a DualSteer device.

[0643] A DualSteer device can include two UEs. A DualSteer device has two subscriptions. Therefore, a DualSteer device can perform registration procedures based on each subscription, with the two UEs operating independently. If necessary, a DualSteer device can also receive policy information from the network that applies to both UEs. For example, a DualSteer device can receive rules for traffic steering / switching, network selection information, and other information from the network via two 3GPP accesses.

[0644] It is assumed that the two UEs that make up the DualSteer Device can exchange information, perform coordination, etc. with each other. This can be applied throughout this specification.

[0645] The procedure according to the example in Figure 17 below shows the registration procedure of a DualSteer device. The DualSteer device has two subscriptions, indicated as UE#1 and UE#2, respectively.

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

[0647] FIG. 17 illustrates an embodiment of Example 2-1 according to one embodiment of the second disclosure of the present specification.

[0648] Figure 17 shows an example of a registration procedure performed by a Dualsteer device within the same PLMN.

[0649] The first embodiment of Example 2-1 of the second disclosure of this specification includes a registration procedure of a DualSteer device in the same PLMN.

[0650] UE#1 and UE#2 of FIG. 17 can be included in one DualSteer device.

[0651] 1. UE#1 of the DualSteer device performs a Registration procedure. Regarding the Registration procedure, the Registration procedures of FIGS. 5 and 6 may be referenced. The UE may include information indicating that it has dual steer capability in the Registration Request message. In the examples below, the UE may refer to one terminal or one UE included in the DualSteer device. Accordingly, UE#1 may include information indicating that it has dual steer capability in the Registration Request message. This capability information may be included only when the DualSteer device requires dual steer operation, regardless of the actual capability. Alternatively, the DualSteer Device may separately include information indicating that it desires dual steer operation in the Registration Request message along with the capability.

[0652] 2. AMF performs registration for the terminal with UDM. At this time, AMF can also send information to UDM notifying that the terminal operates as a dual steer. UDM that receives this information can store information notifying that the terminal operates as a dual steer in the context of UE#1. At this time, based on the subscriber information, UDM can determine that UE#1 and UE#2 are the same subscriber. Based on this, UDM can recognize that UE#1 and UE#2 are terminals used for dual steer. In other words, UDM stores and manages mapping information for SUPI#1 of UE#1 and SUPI#2 of UE#2.

[0653] 3. AMF can retrieve subscriber information for a terminal from the UDM. The subscriber information for a terminal may include information that allows the terminal to operate as a dual-steer.

[0654] 4. AMF creates an AM Policy Association. The selected PCF can be selected based on the SUPI range according to the existing PCF selection procedure.

[0655] 5. AMF can send a Registration Accept message. AMF can include information in the Registration Accept message indicating that the terminal is capable of dual-steer operation. Based on this information, the terminal can perform registration for UE#2.

[0656] 6. UE#2 performs the registration procedure. The registration procedure may be performed in the same manner as steps 1-5. However, since the DualSteer device has already received information from the network that dual steer operation is permitted, UE#2 may perform registration using only the conventional registration procedure. The AMF in the registration procedure of UE#2 may be different from the AMF of UE#1. The AMF may perform an operation to select the same PCF as the PCF selected in step 4.

[0657] In order for the same PCF to be selected, the subscriber information of the terminals (i.e., the subscriber information of UE#1 and the subscriber information of UE#2) may include information for the same PCF selection (e.g., the PCF instance address). Alternatively, in step 4, the AMF may have stored the selected AM Policy information in the UDM after creating the AM Policy Association for UE#1. Based on this information, the UDM may include the AM Policy information stored in the subscriber information for UE#1 when transmitting the subscriber information for UE#2 to the AMF.

[0658] During the registration process for UE#1 or UE#2, the AMF can transmit preferred access / network information to the UE when creating a PDU session using a specific DNN / S-NSSAI. For example, the AMF can send the following information to the UE:

[0659] DNN#1 + S-NSSAI#A: 3GPP TN preferred; and

[0660] DNN#2 + S-NSSAI#B: 3GPP NTN preferred,

[0661] or

[0662] DNN#1 + S-NSSAI#A: HPLMN preferred; and

[0663] DNN#2 + S-NSSAI#B: VPLMN preferred.

[0664] When creating a single access PDU session rather than an MA PDU session, this information can be used by the DualSteer terminal to determine which 3GPP access to create the PDU session through.

[0665] 2. Example 2-2

[0666] Example 2-2 includes an example of the MA PDU session establishment procedure of a DualSteer device.

[0667] A DualSteer device can create an MA PDU session through each 3GPP access. The procedure below illustrates how a DualSteer device creates an MA PDU session in the same PLMN.

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

[0669] FIG. 18 illustrates a first embodiment and / or a second embodiment of Example 2-2 according to one embodiment of the disclosure of the present specification.

[0670] A first embodiment of Example 2-2 according to one embodiment of the disclosure of the present specification may include a process of creating an MA PDU session of a DualSteer device in the same PLMN (two different PDU Session IDs are used).

[0671] Figure 18 includes a MA PDU session setup procedure for a dual-steer device in the same PLMN (using two different PDU session IDs).

[0672] 1. UE#1 can send a PDU Session Establishment Request message. UE#1 performs the procedure to create an MA PDU session. The basic procedure follows the MA PDU Session Establishment procedure in TS 23.502 V18.0.0 clause 4.22.2. UE#1 allocates a PDU Session ID to be used in the MA PDU session and sends a PDU Session Establishment Request message including the PDU Session ID. At this time, UE#1 can request UE#2 to allocate a PDU Session ID to be used for the MA PDU Session, and UE#1 can include the PDU Session ID in the PDU Session Establishment Request and send it.

[0673] 2. The AMF selects an SMF according to the prior art and transmits the PDU Session Establishment Request message transmitted by the terminal to the SMF. During this process, the AMF may transmit information to the SMF notifying that the terminal operates in dual steer mode. For example, as in Example 2-1 of the disclosure of this specification, the AMF may transmit information notifying that the terminal operates in dual steer mode based on information transmitted by the terminal during the registration process. Alternatively, the AMF may transmit information notifying that the terminal operates in dual steer mode based on a new Request Type indicating that the terminal wishes to create an MA PDU session for Dual Steer. For example, in step 1, the terminal may notify the SMF that the session is for Dual Steer based on the fact that the Request Type in the UL NAS Transport message transmitting the PDU Session Establishment is set to DualSteer PDU request instead of MA PDU request.

[0674] 3-4. The SMF initiates the process of creating a PDU session. To indicate that a PDU session has been established, the SMF transmits a PDU Session Establishment Accept message to the terminal via the AMF. At this time, the SMF can transmit the ATSSS rule for use in the MA PDU session to the terminal.

[0675] Since the conventional ATSSS rule is used in 3GPP / non-3GPP access, it contains information indicating whether traffic should be sent to 3GPP access or non-3GPP access.

[0676] However, since all traffic in a MA PDU session for Dualsteer must be transmitted over a 3GPP access, the existing ATSSS rule cannot be used as is. To solve this problem, the SMF can include the PDU Session ID assigned to each 3GPP access, instead of 3GPP / non-3GPP, in the ATSSS rule. Based on the PDU Session ID, the SMF can indicate which 3GPP access to send the traffic to.

[0677] For example, in case of active-standby steering mode, the SMF can include information that active access is PDU Session ID#1 and standby access is PDU Session ID#2 in the ATSSS rule and transmit the ATSSS rule. To enable the use of this ATSSS rule, UE#1 can perform the following actions. For example, UE#1 can pre-allocate PDU Session ID#2 to be used for the MA PDU session based on UE#2, and transmit PDU Session ID#2 in advance when UE#1 transmits PDU Session Establishment Request. UE#1 can include PDU Session ID#2 in the PDU Session Establishment message so that AMF can process it transparently, or transmit PDU Session ID#2 to SMF in the form of PCO.

[0678] 5. The SMF performs registration for the PDU Session with the UDM. At this time, the SMF can transmit information to the UDM indicating that the PDU Session is used for dualsteer. At this time, according to the prior art, the SUPI#1 of UE#1 and the PDU Session ID, DNN, and S-NSSAI information allocated by UE#1 are transmitted to the UDM. The SMF can additionally transmit the PDU Session ID information to be used by UE#2 to the UDM.

[0679] The UE may have stored the mapping information of SUPI#1 and SUPI#2 in the UDM during the registration process according to Example 2-1. Based on the mapping information, the UDM may store the PDU Session ID information to be used by UE#2 in the PDU Session information of SUPI#2 (i.e., "UE context in SMF data"). The PDU Session ID information to be used by UE#2 may be transmitted to the serving AMF of UE#2. Based on the PDU Session ID information to be used by UE#2, the serving AMF of UE#2 may also select the SMF of the MA PDU session.

[0680] 6. UE#2 transmits a PDU Session Establishment message to add a leg of the MA PDU session. UE#2 can use the PDU Session ID that UE#2 will use as described in steps 3, 4, and 5. That is, UE#2 can transmit a PDU Session Establishment Request message including PDU Session ID#2. Based on PDU Session ID#2, AMF can select an SMF using the "UE context in SMF data" subscription information received from UDM. As a result, the same SMF as the SMF selected in step 2 is selected in step 6, and the UE transmits a PDU Session Establishment message to the same SMF via AMF.

[0681] 7-9. The SMF processes the terminal's request and sends a PDU Session Establishment Accept message to the terminal to notify it that a leg of the MA PDU session has been added. The SMF may retransmit the same ATSSS rule information provided to the terminal in steps 3 and 4, or may transmit updated ATSSS rule information.

[0682] Below, a second embodiment of Example 2-2 is described. With respect to the second embodiment of Example 2-2, reference may again be made to FIG. 18. As previously described, FIG. 18 illustrates the first and / or second embodiments of Example 2-2 according to one embodiment of the disclosure of the present specification.

[0683] The second embodiment of Example 2-2 illustrates a process in which a DualSteer device creates an MA PDU session (using a single PDU Session ID) in the same PLMN.

[0684] Figure 18 illustrates the MA PDU session setup procedure (using a single PDU session ID) for a dual-steer device in the same PLMN.

[0685] 1. UE#1 performs the procedure to create an MA PDU session. The basic procedure follows TS 23.502 V18.0.0 clause 4.22.2 MA PDU Session Establishment procedure. UE#1 allocates a PDU Session ID to be used in the MA PDU session. UE#1 transmits a PDU Session Establishment Request message containing the PDU Session ID to be used in the MA PDU session. At this time, UE#1 can allocate a PDU Session ID within a preset specific range. In addition, UE#1 can pass the allocated PDU Session ID information to UE#2 so that UE#2 can use the allocated PDU Session ID.

[0686] 2. The AMF selects an SMF according to the prior art and transmits the PDU Session Establishment Request message transmitted by the terminal to the SMF. During this process, the AMF can transmit information to the SMF indicating that the terminal operates as a dual steer. For example, in Example 2-1, based on the information transmitted by the terminal during the registration process, the AMF can transmit information to the SMF indicating that the terminal operates as a dual steer. Alternatively, it can be based on a new Request Type indicating that the terminal wishes to create an MA PDU session for Dual Steer. For example, based on the fact that the Request Type in the UL NAS Transport message transmitting the PDU Session Establishment in step 1 was set to DualSteer PDU request instead of MA PDU request, the terminal can notify the SMF that the session is for Dual Steer.

[0687] 3-4. The SMF initiates the process of creating a PDU session. The SMF sends a PDU Session Establishment Accept message to the terminal to notify it that a PDU session has been established. At this time, the SMF can transmit the ATSSS rule for use in the MA PDU session to the terminal.

[0688] The conventional ATSSS rule is used for 3GPP / non-3GPP access, so it includes information indicating whether traffic should be sent to the 3GPP access or non-3GPP access. However, in the MA PDU session for Dualsteer, all traffic must be sent to the 3GPP access, so the conventional ATSSS rule cannot be used. To solve this problem, the SMF can allocate a path ID to be used in the corresponding path and notify the terminal of the allocated path ID when transmitting the PDU Session Establishment Accept to the terminal. Instead of the 3GPP / non-3GPP included in the conventional ATSSS rule, the SMF can use the path ID assigned to each 3GPP access to indicate which 3GPP access to send the traffic to. For example, in the case of active-standby steering mode, the SMF can set the active access included in the ATSSS rule to path #1 and the standby access to path #2.

[0689] Another way is that when the terminal transmits the PDU Session Establishment Request, UE#1 and UE#2 can each assign a path ID, and UE#1 and UE#2 can notify the SMF of the path ID. In this case, UE#1 can send PDU Session ID information to UE#2 and request path ID allocation from UE#2. Then, UE#2 can notify UE#1 of the path ID it has assigned. Alternatively, UE#1 can directly assign a path ID, notify the SMF, and then UE#1 can notify UE#2 of the assigned path ID information.

[0690] 5. The SMF performs registration for the PDU Session with the UDM. At this time, the SMF can inform the UDM that the PDU Session is used for dualsteer. At this time, according to the prior art, the SUPI#1 of UE#1 and the PDU Session ID, DNN, and S-NSSAI information allocated by UE#1 are transmitted to the UDM.

[0691] The UE may have stored the mapping information of SUPI#1 and SUPI#2 in the UDM during the registration process according to Example 2-1. Based on the mapping information, the UDM can store the PDU Session ID information to be used in the MA PDU session in the PDU Session information of SUPI#2 (i.e., "UE context in SMF data"). The PDU Session ID information to be used in the MA PDU session is transmitted to the serving AMF of UE#2. The serving AMF of UE#2 can select the SMF of the MA PDU session based on the PDU Session ID information to be used in the MA PDU session.

[0692] 6. UE#2 sends a PDU Session Establishment request message to add a leg of the MA PDU session. At this time, the PDU Session ID allocated by UE#1 and notified to UE#2 in step 1 is used as the PDU Session ID. Based on the PDU Session ID, AMF selects an SMF based on the "UE context in SMF data" subscription information received from the UDM. As a result, the same SMF as the SMF selected in step 2 is selected, and UE#2 sends a PDU Session Establishment message to the SMF via AMF.

[0693] 7-9. The SMF processes the terminal's request and sends a PDU Session Establishment Accept to the terminal to notify the terminal that a leg of the MA PDU session has been added. Additionally, the SMF may include the path ID information assigned to UE#2's PDU session in the PDU Session Establishment Accept. The SMF may retransmit the same ATSSS rule information provided to the terminal in steps 3 and 4, or may transmit updated ATSSS rule information.

[0694] 3. Example 2-3

[0695] An example of dual-steer device management using Primary / Secondary SUPI and dual-steer PDU session support using separate PDU sessions is described.

[0696] For a dual-steer device, the following description may apply. A dual-steer device includes two SUPIs (i.e., two USIMs) and corresponding PEIs. The subscriber information for each SUPI indicates whether the UE can operate as a dual-steer device and the associated SUPI of the dual-steer device (i.e., the other SUPI of the dual-steer device). The subscriber information also indicates whether the SUPI of the dual-steer device is the primary SUPI or the secondary SUPI. The primary SUPI is no different from the general SUPI, but the use of the secondary SUPI may be restricted depending on the operator's policy (e.g., the secondary SUPI can only be used for DualSteer).

[0697] Additionally, the subscriber information includes PCF selection information (e.g., PCF address, FQDN), which is used to select the same PCF for each UE in the dual-steer device. It is assumed that the subscriber information for two associated SUPIs is stored in the same UDM. That is, when the AMF selects a UDM for each SUPI, the selected UDM is the same UDM. This can be achieved by assigning the same routing indicator, etc., depending on the operator's settings.

[0698] The following description applies to registration and mobility management of dual-steer devices.

[0699] When a UE intends to operate as part of a dual-steer device, the UE indicates its capability in the registration request message. If the subscriber information allows the UE to operate as a dual-steer device, the AMF indicates this in the registration accept message. The AMF indicates whether the SUPI used for registration is primary or secondary, based on the subscriber information. The UE stores whether the SUPI is primary or secondary. If the UE registers with the network using secondary SUPI first, the AMF may indicate that primary SUPI registration is required and reject the UE's request.

[0700] Instead of providing Primary / Secondary SUPI information to the UE, it is possible to preset whether the UE of a dual-steer device will be connected to Primary SUPI or Secondary SUPI.

[0701] An example of AM and UE policy management for a dual-steer device is as follows:

[0702] During the registration procedure (using Primary SUPI), the AMF selects a PCF for the UE based on the PCF selection information in the subscriber information. When the AMF establishes an AM Policy Association, the AMF provides the SUPI associated with the SUPI of the registered UE (i.e., Secondary SUPI). The AMF also provides mobility restriction information (e.g., RFSP index, RAT restriction, core network type restriction) to the PCF. If a dual-steer device registers using a different SUPI (i.e., Secondary SUPI), the serving AMF selects the same PCF based on the PCF selection information and provides the SUPI associated with the SUPI of the registered UE (Primary SUPI). The PCF may update the mobility restriction information (e.g., RFSP index, RAT restriction, core network type restriction) to prevent the dual-steer device from being served on the same cell / frequency in each 3GPP connection.

[0703] The URSP rules are enhanced to indicate whether dual-steer PDU sessions are preferred by the network. This can be achieved by adding a new value of "DualSteer" or "Dual 3GPP Access" to the Access Type preference in the Route Selection Descriptor, or by adding new route selection components. In the policy container, the UE indicates whether it supports dual-steer policy so that the PCF can provide enhanced URSP rules to the UE. The PCF considers subscriber information about the UE of the dual-steer device (i.e., whether dual-steer operation is allowed) when generating URSP rules for dual-steer PDU sessions.

[0704] When a terminal with a Primary SUPI performs registration on a network, the AMF can provide the terminal with network selection information for the Secondary SUPI. Additionally, the AMF can transmit information to the terminal regarding when to perform registration using the Secondary SUPI. Information regarding when to perform registration may include, for example, whether to perform registration immediately, whether to perform registration when a specific condition (e.g., when the terminal enters a specific area) is met, or whether to perform the registration procedure after a DualSteer PDU Session is created. Based on this information, a terminal with a Secondary SUPI can select a network and perform registration.

[0705] Alternatively, instead of providing network selection information in the Registration Accept, the AMF can perform the following actions: If the UE creates a DualSteer PDU Session, the AMF can provide network selection information to the UE through the UE Configuration Update procedure at that time. Alternatively, the AMF can decide to transmit network selection information based on the UE's location, etc., regardless of whether a DualSteer PDU Session has been created.

[0706] The network selection information that AMF provides to the terminal may be generated directly by AMF or transmitted to the terminal in the form of a policy by PCF through interaction with PCF.

[0707] An example of a dual-steer PDU session with separate PDU sessions is as follows:

[0708] Referring to FIG. 19, a dual steer PDU session including separate PDU sessions is described.

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

[0710] FIG. 19 is an example of a dual-steer PDU session according to one embodiment of the disclosure of the present specification.

[0711] A dual-steer PDU session can be established by bundling two separate PDU sessions established through different accesses. Figure 19 illustrates a schematic example of a dual-steer PDU session.

[0712] Each PDU session of a dual-steer PDU session according to the example of FIG. 19 shares a common DNN, S-NSSAI, SSC mode, and IP address. When a UE establishes a PDU session used for a dual-steer PDU session, the UE may set the request type to "dual-steer PDU request." Based on the dual-steer PDU request, the network may recognize that the requested PDU session is used for a dual-steer PDU session.

[0713] For example, the first PDU session used in a dual-steer PDU session may be named 'Primary PDU Session', and the second PDU session may be named 'Secondary PDU Session'.

[0714] Below, the dual-steer rules are described. For example, the dual-steer rules may refer to the steering and switching rules of a dual-steer PDU session.

[0715] The steering and turning rules for a Dual-Steer PDU session (Dual-Steer Rules) follow the same structure as the ATSSS rules, with the following differences:

[0716] - Active-Standby mode is supported among steering modes.

[0717] - In Active-Standby mode, Primary Access and Secondary Access are used to indicate access instead of 3GPP / N3GPP access.

[0718] DualSteer PDU sessions may also support non-3GPP access.

[0719] For example, a dual-steer device with a dual-steer PDU session with user plane resources activated over dual 3GPP connections can register over a non-3GPP access. In this case, only one of the 3GPP accesses can be activated, and the dual-steer device determines which 3GPP access remains activated. If the dual-steer device wishes to maintain the primary PDU session, it uses a secondary SUPI to register over the non-3GPP connection and triggers a handover procedure for the secondary PDU session established over the 3GPP connection. Existing dual-steer rules are then used to determine traffic steering and switching.

[0720] Referring to FIG. 20, an example of a dual-steer PDU session supporting non-3GPP access is described.

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

[0722] FIG. 20 illustrates an example of a dual-steer PDU session supporting non-3GPP access according to one embodiment of the disclosure of the present specification.

[0723] Referring to the example of FIG. 20, a dual-steer PDU session can support non-3GPP access by using handover between 3GPP access and non-3GPP access. For example, PDU session #2 among the dual-steer PDU sessions established according to the example of FIG. 19 can be handed over to a non-3GPP access.

[0724] Below, the registration procedure of the dual-steering device is described with reference to FIG. 21.

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

[0726] FIG. 21 illustrates a registration procedure of a dual-steering device according to one embodiment of the disclosure of the present specification.

[0727] According to the example of FIG. 21, the dual-steer device may include UE#1 and UE#2.

[0728] Note that the serving AMF of UE#1 may be the same as or different from the serving AMF of UE#2. That is, although one AMF is depicted in the example of FIG. 21, this is merely an example. The AMF in steps 5 through 8 may be different from the AMF in steps 1 through 4.

[0729] 1. UE#1 transmits a registration request message. If UE#1 wishes to operate as a dual-steer device, UE#1 may transmit a registration request message that includes dual-steer capabilities. UE#1 indicates its dual-steer capability in the registration request message.

[0730] 2a. Based on the SUPI of UE#1, AMF selects UDM and registers with UDM with an indication that UE#1 performs DualSteer operation. Based on the subscriber information of UE#1, UDM checks whether UE#1 can operate as a dual-steer device. If allowed, UDM accepts the UE registration and stores that UE#1 is operating as a dual-steer device.

[0731] 2b. AMF retrieves the subscription data of UE#1. Since UE#1 operates as a dual-steer device, the UDM includes the dual-steer subscription information when providing the subscription information to AMF. If the AMF already contains the subscription information, the UDM triggers Nudm_SDM_Notification to provide the updated subscription information.

[0732] 3. AMF selects PCF and establishes AM Policy Association based on PCF selection information in subscriber information data of UE#1. During the setup process, AMF indicates to PCF that UE is operating as a dual-steer device, and may also include SUPI of UE#2 obtained from subscriber information data of UE#1.

[0733] 4. Based on the subscriber information, the AMF sends a registration acceptance message containing information regarding whether the network supports dual-steer and whether the UE is permitted to operate as a dual-steer device. The AMF also indicates that the SUPI of UE#1 is the Primary SUPI.

[0734] 5. If UE is allowed to operate as a dual-steer device in step 4, UE#2 may perform the registration procedure while UE#1 is registered. UE#2 may send a registration request message containing its capabilities for dual-steer.

[0735] Note that even if UE#1 has not received information indicating that it can operate as a dual-steer device, UE#2 can still perform the registration process without dual-steer capability. In this case, the network can independently manage each registration, or the UDM can reject the secondary registration based on the carrier's policy.

[0736] 6a. The AMF (which may be different from the AMF provided by UE#1) selects a UDM based on the SUPI of UE#2. The selected UDM is the same as the UDM selected in step 2a. The AMF registers the UE with the UDM with an indication that the UE is performing dual-steer operation. The UDM checks whether UE#2 can operate as a dual-steer device based on the UE's subscription. If allowed, the UDM accepts the UE registration and stores that the UE is operating as a dual-steer device.

[0737] 6b. AMF retrieves subscriber information for UE#2. Since UE#2 operates as a dual-steer device, the UDM includes dual-steer-related subscriber information when providing subscriber information to AMF. If AMF already has subscriber information, UDM triggers Nudm_SDM_Notification to provide updated subscriber information.

[0738] 7. AMF selects PCF and establishes AM Policy Association based on PCF selection information in subscriber information data of UE#2. During the configuration process, AMF indicates that UE is operating as a dual-steer device and also includes SUPI of UE#1 obtained from subscriber information data of UE#2. Based on this information, PCF can adjust AM policies of UE#1 and UE#2. For example, PCF can select RAT / Frequency Selection Priority (RFSP) index to allow UE#1 and UE#2 to move to different RAT or adjust RAT restrictions.

[0739] 8. AMF sends a Registration Accept message containing information regarding whether the network supports dual-steer and whether the UE is allowed to operate as a dual-steer device. AMF indicates that the SUPI of UE#2 is the Secondary SUPI.

[0740] While UE#1 and / or UE#2 are registered, a subscription change may occur, rendering them incapable of operating as dual-steer devices. In this case, the UDM removes the stored information indicating that the UE is operating as a dual-steer device and notifies the AMF of the updated subscription information. Depending on operator policy, the UDM may trigger deregistration for the UE with the Secondary SUPI.

[0741] Below, the establishment procedure of a dual-steer PDU session is described with reference to FIG. 22.

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

[0743] FIG. 22 illustrates a procedure for establishing a dual-steer PDU session according to one embodiment of the disclosure of the present specification.

[0744] According to the example of FIG. 22, the dual-steer device may include UE#1 and UE#2.

[0745] Note that the serving AMF of UE#1 may be the same as or different from the serving AMF of UE#2. That is, although the AMF is shown as one in the example of FIG. 21, this is merely an example. The AMF in steps 8 through 13 may be different from the AMF in steps 1 through 7.

[0746] 1. UE#1 transmits a PDU Session Establishment Request message. For example, UE#1 transmits an UL NAS Transmit message containing the request type, PDU Session ID, DNN, S-NSSAI, and N1 SM container (containing the PDU Session Establishment Request). The request type is set to "Dual Steer PDU Request."

[0747] Note that this may also be triggered by the URSP rules of a UE with the access type preference set to DualSteer as described above.

[0748] 2. AMF selects SMF and forwards the received N1 SM container (containing PDU session establishment request) to SMF.

[0749] 3. SMF selects UPF and establishes N4 session.

[0750] 4. Based on the PCC rules received from the PCF, the SMF triggers Namf_Communication_N1N2MessageTransfer and sends a PDU Session Establishment Accept message. The SMF PDU Session Establishment Accept message includes the dual-steer rules.

[0751] 5. AMF sends a PDU Session Setup Accept message to the UE.

[0752] 6. SMF triggers Nudm_UECM_Registration and registers the PDU session with UDM (including SUPI, DNN, S-NSSAI, PDU session ID, SMF ID, and DualSteer PDU indication).

[0753] 7. Based on the PDU Session information of the PDU session registered in step 6, the UDM triggers Nudm_SDM_Notification to the AMF of UE#1. The UDM updates the subscriber information of UE#1 and sends it to the AMF of UE#2 to update the subscriber information of UE#2. This operation can be performed based on the subscription information of UE#1, which includes the dual-steer subscription and the related SUPI, i.e., SUPI#2. As a result, the serving AMF stores the DNN, PDU session ID, and SMF Identity used for the dual-steer PDU session.

[0754] 8. UE#2 transmits a PDU Session Establishment Request message. For example, UE#2 transmits an UL NAS Transport message containing the request type, PDU Session ID, linked PDU Session ID, DNN, S-NSSAI, and N1 SM container (including the PDU Session Establishment Request (including the PDU Session ID)). The request type is set to "Dual Steer PDU Request." The linked PDU Session ID is the PDU Session ID of the primary PDU session assigned in Step 1.

[0755] A dual-steer device may be registered to two PLMNs (e.g., HPLMN and VPLMN) and the serving PLMN may not support dual-steer (i.e., the UE may not receive a dual-steer support indication during the registration procedure). For example, in this case, only the HPLMN may support dual-steer, while the VPLMN may not support dual-steer. In this case, a PDU session may be created in the same format as a Home Routed PDU. That is, since the H-SMF supports and can manage dual-steer, dual-steer can be supported regardless of whether the VPLMN supports it. In this case, UE#2 transmits a UL NAS transport message (e.g., PDU Session Establishment Request) containing the request type, associated PDU Session ID, DNN, S-NSSAI, and N1 SM container (including the PDU Session Establishment Request (PDU Session ID)). The request type is set to "existing PDU session". This allows establishing a dual-steer PDU session without affecting PLMNs that do not support dual-steer. The SMF can use the PDU session ID included in the PDU session establishment request to ensure that the actual PDU session ID assigned to the secondary PDU session is different from the PDU session ID included in the Nsmf_PDUSession_CreateSMContext request.

[0756] Note that the UE in secondary SUPI does not use the PDU session ID of the primary PDU session in the serving PLMN.

[0757] 9. If the request type is set to "Dual-Steer PDU Request", the AMF selects the same SMF as selected in step 2 using the associated PDU session ID (i.e., primary PDU session ID) and subscriber information context received from the UDM in step 8.

[0758] If the request type is set to "existing PDU session", AMF selects the same SMF as selected in step 2 using the associated PDU session ID (i.e., the default PDU session ID) and subscriber information context received from the UDM in step 8.

[0759] AMF sends a PDU session setup request to SMF by calling the Nsmf_PDUSession_CreateSMContext request.

[0760] 10. Based on the received related PDU session ID, DNN, S-NSSAI, and DualSteer PDU indication, the SMF recognizes that the UE request is to add a leg to the DualSteer PDU session. The SMF updates the N4 session to establish the additional leg for the DualSteer PDU session.

[0761] If the serving PLMN does not support DualSteer, the H-SMF recognizes that the UE request is for adding a leg of a DualSteer session based on the request type set to "existing PDU session" and the PDU session ID received from the V-SMF (i.e., the associated PDU session ID).

[0762] 11. Based on the PCC rules received from the PCF, the SMF triggers Namf_Communication_N1N2MessageTransfer to send a PDU Session Establishment Acceptance message. The SMF may include dual-steer rules in the PDU Session Establishment Acceptance message.

[0763] 12. AMF sends a PDU session establishment acceptance message to UE#2.

[0764] 13. SMF registers the PDU session with UDM as described in step 6.

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

[0766] FIG. 23 illustrates an example of moving a leg of a dual-steer PDU session between 3GPP access and non-3GPP access according to one embodiment of the disclosure of the present specification.

[0767] The example in Figure 23 illustrates moving a leg of a dual-steer PDU session between 3GPP access and non-3GPP access.

[0768] 1. The dual-steer device establishes a dual-steer PDU session as described in FIG. 22.

[0769] 2. The dual-steer device attempts to move a secondary PDU session over a non-3GPP access. UE#2 triggers registration over the non-3GPP access using the Secondary SUPI, i.e., SUPI#2. During registration, UE#2 can transmit the 5G-GUTI associated with SUPI#2.

[0770] 3. The UE of SUPI#2 transmits a PDU session establishment request message including the request type = "existing PDU session" and the PDU session ID of the secondary PDU session in the UL NAS transmission message.

[0771] 4. AMF selects SMF based on the existing PDU session context.

[0772] 5. The SMF modifies the N4 Session to configure user plane resources over a non-3GPP connection. At this time, all downlink traffic transmitted over the 3GPP connection of the Secondary PDU session is transmitted over the non-3GPP connection.

[0773] 6. SMF sends a PDU Session Establishment Accept message to the UE and provides N2 information to non-3GPP connections.

[0774] 7. UE#2 receives a PDU Session Establishment Accept message. From this point on, all uplink traffic transmitted over the 3GPP connection of the auxiliary PDU session is transmitted over the non-3GPP connection.

[0775] 8. SMF triggers the release of user plane resources through the 3GPP connection of the secondary PDU session.

[0776] According to the second disclosure of this specification, the following operations may be supported.

[0777] For example, a UE indicates its dual-steer capability in a registration request message. For example, during a dual-steer PDU session setup request procedure, the UE includes a new request type = Dual-steer PDU Request and the associated PDU session ID. For example, the UE performs traffic steering and switching according to the dual-steer rules.

[0778] For example, the AMF indicates in Nudm_UECM_Registration that the UE is performing dual-steer operation. For example, during the Npcf_AMPolicyControl creation service, the AMF includes an indication that the UE is performing dual-steer operation and the relevant SUPI of the dual-steer device. For example, the AMF performs SMF selection based on the relevant PDU session ID and subscriber information context received from the UDM.

[0779] For example, SMF manages a dual-steer PDU session using two different PDU session IDs.

[0780] For example, UPF supports multi-access rules over two 3GPP connections.

[0781] For example, the UDM manages subscriber information (UE Subscription) that includes PCF selection information such as whether dual-steer operation is allowed. For example, the UDM authorizes and stores the UE to operate as a dual-steer device. For example, the UDM notifies the serving AMF of UE#2 of the PDU session ID, DNN, and SMF Identity when the SMF registers a PDU session with the UDM.

[0782] For example, the PCF adjusts the AM policy based on the indication that the UE is performing a dual-steer operation and the associated SUPI of the dual-steer device. For example, the PCF can set RFSP Index, RAT restriction, etc. differently for each UE.

[0783] Although the process of SMF directly generating ATSSS rule has been described as an example, this is only an example. The scope of the disclosure of this specification is not limited to the case where SMF directly generates ATSSS rule. For example, when using PCF, SMF can inform PCF of necessary information (e.g., information indicating that it is MA PDU session for Dualsteer, PDU Session ID information assigned by UE#1, PDU Session ID information assigned by UE#2, etc.). Based on this, PCF can generate PCC rule and transmit PCC rule to SMF. SMF can generate ATSSS rule based on PCC rule. Also, instead of SMF assigning path ID, PCF can assign path ID. Alternatively, PCC rule for dualsteer PDU session can be generated using Primary access / Secondary access without assigning path ID.

[0784] III. Application Examples of the Disclosure of This Specification

[0785] Hereinafter, examples to which the disclosure of the present specification applies will be described with reference to FIG. 24. The various examples of the first disclosure and the various examples of the second disclosure of the present specification described above may be combined.

[0786] Hereinafter, with reference to FIG. 24, an example of operations according to an embodiment of the disclosure of the present specification is described. The example of FIG. 24 may include operations based on the first and / or second examples of the disclosure of the present specification.

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

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

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

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

[0791] The operations illustrated in FIG. 24 are merely examples, and the scope of the disclosure of this specification is not limited to the operations illustrated in FIG. 24.

[0792] The device of FIG. 24 may include at least one UE. For example, the device may be a dual-steer device as described in various examples of the disclosure herein. The device may include a first UE and a second UE. The device may be associated with two SUPIs.

[0793] In step (S2401), the device transmits a registration request message.

[0794] For example, the registration request message may include the subscriber permanent identifier (SUPI) of the first UE. The registration request message may include capability information indicating that dual steering via two 3GPP accesses is supported.

[0795] In step (S2402), AMF can receive subscriber information from UDM.

[0796] For example, the AMF may send a registration message containing the SUPI of the first UE to the UDM.

[0797] For example, the AMF may receive subscriber information related to the first UE from the UDM. For example, the subscriber information related to the first UE may include a primary SUPI and a secondary SUPI related to the steering.

[0798] In step (S2403), the AMF transmits a registration acceptance message to the device. For example, the AMF may transmit a registration acceptance message to the first UE.

[0799] For example, the registration acceptance message may include information that the SUPI of the first UE is the primary SUPI.

[0800] For example, the registration acceptance message may include information related to the network for the second UE to perform registration.

[0801] Although not illustrated in the example of FIG. 24, for UE 1, a PDU session establishment procedure may be performed with the SMF. Additionally, a registration procedure may be performed for UE 2. Based on various examples disclosed in the present specification, a device may perform the PDU session establishment procedure and the registration procedure.

[0802] For example, based on the UDM receiving a registration message related to the first PDU session of the first UE from the SMF, the AMF may receive subscriber information including an SMF ID for the PDU session related to the dual steering from the UDM.

[0803] For example, a device may receive rules related to dual steering from the SMF. For example, the rules related to dual steering may include information related to primary access and secondary access, which are related to primary SUPI and secondary SUPI. For example, a device may receive URSP rules related to dual steering from the PCF.

[0804] In step (S2404), the device transmits a PDU session establishment request message to the AMF.

[0805] For example, based on the primary SUPI, after the first PDU session of the first UE is established, the AMF may receive a PDU session establishment request message for establishing a second PDU session from the second UE included in the device.

[0806] For example, the request type of the PDU session establishment request message may be a PDU request related to the dual steering. The ID of the first PDU session and the ID of the second PDU session may be the same.

[0807] At step (S2405), AMF selects SMF.

[0808] For example, based on the subscriber information and the secondary SUPI included in the PDU session establishment request message, the AMF may select the SMF associated with the first PDU session as the SMF for the second PDU session.

[0809] For example, AMF can forward a PDU session establishment request message to a selected SMF.

[0810] For example, based on subscriber information, the AMF can select a PCF. For example, the AMF can transmit a primary SUPI and a secondary SUPI to the PCF. For example, the primary SUPI and secondary SUPI can be used by the PCF to generate different RFSP Indexes, RAT restrictions, etc. for UEs using the primary SUPI and UEs using the secondary SUPI.

[0811] For example, the AMF can receive an Access and Mobility (AM) policy based on the primary SUPI and the secondary SUPI from the PCF.

[0812] According to one embodiment of the disclosure of the present specification, a UE or DualSteer Device can perform registration with a first network via a first 3GPP access. The network can provide network information related to Dual Steer to the UE or DualSteer Device. The UE or DualSteer Device can determine that it can perform Dual Steer based on the network information related to Dual Steer. Furthermore, the UE or DualSteer Device can determine which 3GPP access / network it can perform dual registration with. The UE or DualSteer Device can perform registration with a second network via a second 3GPP access. The PCF can configure / update / create a URSP that can be used in a dual registration situation for the UE or DualSteer Device. And the PCF can provide the URSP to the UE or DualSteer Device. A UE or DualSteer Device can establish a MA PDU Session to receive services through two 3GPP accesses / networks based on the above URSP (if the service / application / traffic allows / prefers two 3GPP accesses / networks). In addition, a UE or DualSteer Device can select / decide a 3GPP access and / or network to receive services through one 3GPP access / network, and establish a PDU Session through this.

[0813] This specification may have various effects.

[0814] For example, the network can configure / provide network information related to Dual Steer to the UE or DualSteer Device. Based on the network information related to Dual Steer, the network can determine whether the UE or DualSteer Device can receive services through Dual Steer. In addition, the network can provide URSP to the UE or DualSteer Device by considering the two 3GPP access / network situations registered by the UE or DualSteer Device.

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

[0816] For reference, the operation of the terminal (e.g., UE, dual-steering device) described in this specification can be implemented by the devices of FIGS. 1 to 3 described above. For example, the terminal can be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the terminal described in this specification can be processed by one or more processors (102 or 202). The operation of the terminal described in this specification can be stored in one or more memories (104 or 204) in the form of instructions / programs (e.g., instructions, executable code) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (105 or 206), and execute instructions / programs stored in one or more memories (104 or 204) to perform operations of a terminal (e.g., UE) described in the disclosure of this specification.

[0817] Additionally, the commands for performing the operations of the terminal described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium. The storage medium may be included in one or more memories (104 or 204). In addition, the commands recorded in the storage medium may be executed by one or more processors (102 or 202) to perform the operations of the terminal described in the disclosure of this specification.

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

[0819] Additionally, the instructions for performing the operations of the network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium having the instructions recorded thereon. The storage medium may be included in one or more memories (104 or 204). In addition, the instructions recorded in the storage medium may be executed by one or more processors (102 or 202) to perform the operations of the network node or base station described in the disclosure of this specification.

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

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

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

Claims

1. In the method of Access and Mobility Management Function (AMF) performing communication, A step of receiving a registration request message including a subscriber permanent identifier (SUPI) of a first User Equipment (UE) from the first UE; The first UE is included in a device including one or more UEs, and The above registration request message includes capability information supporting dual steering via two 3GPP accesses; A step of transmitting a registration message including the SUPI of the first UE to the UDM; A step of receiving subscriber information related to the first UE from the UDM; Subscriber information related to the first UE includes primary SUPI and secondary SUPI related to the dual steering; A step of transmitting a registration acceptance message to the first UE; Based on the primary SUPI, after the first PDU session of the first UE is established, a step of receiving a PDU session establishment request message for establishing a second PDU session from the second UE included in the device; The request type of the above PDU session establishment request message is a PDU request related to the dual steering; and A method comprising the step of selecting an SMF related to the first PDU session as an SMF for the second PDU session based on the subscriber information and the secondary SUPI included in the PDU session establishment request message.

2. In paragraph 1, A method characterized in that the registration acceptance message includes information related to the network for performing registration by the second UE.

3. In paragraph 1 or 2, A step of selecting a PCF based on the above subscriber information; and A method further comprising the step of transmitting the primary SUPI and the secondary SUPI to the PCF.

4. In paragraph 3, A method characterized in that the primary SUPI and the secondary SUPI are used by the PCF to generate an RFSP Index and / or a RAT restriction.

5. In any one of paragraphs 1 to 4, A method further comprising the step of receiving an Access and Mobility (AM) policy based on the primary SUPI and the secondary SUPI from the PCF.

6. In any one of paragraphs 1 to 5, A method further comprising the step of receiving subscriber information including an SMF ID for a PDU session related to the dual steering from the UDM based on the UDM receiving a registration message related to the first PDU session from the SMF.

7. In any one of paragraphs 1 to 6, A method characterized in that the above registration acceptance message includes information that the SUPI of the first UE is the primary SUPI.

8. In the Access and Mobility Management Function (AMF) that performs communication, the AMF: One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; An operation performed based on the above command being executed by the one or more processors is an AMF method according to any one of claims 1 to 7.

9. A method for performing communication by a device including at least one User Equipment (UE), A step of transmitting a registration request message including a subscriber permanent identifier (SUPI) of a first UE included in the above device to an Access and Mobility Management Function (AMF); The above registration request message includes capability information supporting dual steering via two 3GPP accesses; and After the first PDU session of the first UE is established based on the primary SUPI, a step of transmitting a PDU session establishment request message for establishing a second PDU session of the second UE included in the device to the AMF is included. The request type of the above PDU session establishment request message is a PDU request related to the double steering, and the ID of the first PDU session and the ID of the second PDU session are the same, A method characterized in that the PDU session ID included in the PDU session establishment request message is used by the AMF to select the SMF associated with the first PDU session as the SMF for the second PDU session.

10. In paragraph 9, A method characterized in that the registration acceptance message includes information that the SUPI of the first UE is the primary SUPI.

11. In paragraph 9 or 10, A method characterized in that it further comprises a step of receiving a rule related to the dual steering from the SMF.

12. In any one of paragraphs 9 to 11, A method characterized in that the rules related to the above double steering include information related to primary access and secondary access related to primary SUPI and secondary SUPI.

13. In any one of paragraphs 9 to 12, Further comprising the step of receiving a URSP rule related to dual steering from the PCF, A method characterized in that the above PDU session establishment request message is transmitted based on a URSP rule related to the dual steering.

14. In a device including at least one User Equipment (UE), the device: One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; The actions performed based on the above instructions being executed by the one or more processors are: A device according to any one of claims 9 to 13.

15. In an apparatus of a communication system, the apparatus: One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; A device wherein the operation performed based on the command being executed by the one or more processors is a method according to any one of claims 9 to 13.

16. A non-transitory computer readable medium (CRM) storing instructions, wherein an operation performed based on the instructions being executed by one or more processors is a method according to any one of claims 9 to 13.

Images