JP7637068B2 - UE - Google Patents

Description

This application relates to a UE. This application claims the benefit of priority to Japanese Patent Application No. 2019-232442, filed on December 24, 2019, the entire contents of which are incorporated herein by reference.

3GPP (3rd Generation Partnership Project) is studying the system architecture of 5GS (5G System), a fifth generation (5G) mobile communication system, and is discussing how to support new procedures and new functions. In 5GS, a new core network, 5GC (5G Core Network), is being considered to provide a wide variety of services. In Release 16, discussions have begun on supporting the ATSSS (Access Traffic Steering, Switching and Splitting) function (ATSSS feature) (also called the ATSSS function of Release 16), which communicates using a special PDU session called a multi-access PDU session (also called a MA PDU session) rather than the PDU (Protocol Data Unit) session (also called a single access PDU session, SA PDU session) specified in Release 15 (see Non-Patent Documents 1 to 4). Furthermore, in Release 17, improved technology for the ATSSS function is scheduled to be considered (see Non-Patent Document 5).

3GPP TS 23.501 V16.3.0 (2019-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16) 3GPP TS 23.502 V16.3.0 (2019-12); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Release 16) 3GPP TS 24.501 V16.3.0 (2019-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3 (Release 16) 3GPP TS 24.193 V1.0.1 (2019-12); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Access Traffic Steering, Switching and Splitting; Stage 3 (Release 16) SP-190558; 3GPP TSG SA Meeting#84 Newport Beach California, USA Jun 5-7, 2019; Study on Access Traffic Steering, Switch and Splitting support in the 5G system architecture Phase 2

In Release 17, which adds new functions based on the contents of Release 16, UE (User Equipment) supports the ATSSS function that communicates using MA PDU sessions, but there may be UEs that do not support the eATSSS (enhanced ATSSS or evolved ATSSS) feature (also called the second ATSSS feature or the ATSSS feature of Release 17), which is an improved version of the ATSSS feature that communicates using a method that does not use MA PDU sessions. There may also be UEs that do not support the ATSSS feature but do support the eATSSS feature, and UEs that support both the ATSSS and eATSSS features.

Similarly, there may be 5GCs that support the ATSSS function but do not support the eATSSS function, 5GCs that do not support the ATSSS function but do support the eATSSS function, and 5GCs that support both the ATSSS function and the eATSSS function.

In such a situation, for example, even if the UE requests the establishment of a PDU session for communication using the ATSSS function or the eATSSS function, or regardless of whether the UE requests the establishment of a PDU session for communication using the ATSSS function or the eATSSS function, 5GC may allow the establishment of a PDU session for communication using the ATSSS function or the eATSSS function based on the UE's capabilities (also referred to as UE capability), and/or the 5GC's capabilities (also referred to as Network capability), and/or the UE's preferences, etc.

However, no solution to these problems has been disclosed.

One aspect of the present invention has been made in consideration of the above circumstances, and its purpose is to realize a communication method using ATSSS function or eATSSS function, taking into consideration the capabilities of the UE, and/or the capabilities of 5GC, and/or the wishes of the UE, etc.

One embodiment of the UE is a UE (User Equipment) having a control unit and a transceiver unit, wherein the transceiver unit transmits a PDU session establishment request message to a core network, the PDU session establishment request message including information indicating a request for permission to communicate using an eATSSS function that communicates using two SA PDU sessions consisting of a first SA PDU session via 3GPP access and a second SA PDU session via non-3GPP access, and when a PDU session establishment acceptance message including an ATSSS container IE including an ATSSS rule including a steering function indicating the eATSSS function is received from the core network, the control unit recognizes that an SA PDU session for the eATSSS function has been established.

According to one aspect of the present invention, a communication method using ATSSS function or eATSSS function can be realized, taking into account the capabilities of the UE, and/or the capabilities of 5GC, and/or the wishes of the UE, etc.

FIG. 1 is a diagram illustrating an outline of a mobile communication system 1. FIG. 1 is a diagram illustrating a detailed configuration of a mobile communication system 1. A diagram explaining the device configuration of a UE. FIG. 2 is a diagram mainly explaining the configuration of an access network device. FIG. 2 is a diagram mainly explaining the configuration of a core network device. FIG. 1 is a diagram illustrating a registration procedure. A diagram illustrating a PDU session establishment procedure via 3GPP access. A diagram explaining the PDU session establishment procedure via non-3GPP access.

Below, we will explain the mobile communication system, the configuration of each device, the highly specialized terminology and identification information used in each embodiment, etc., which have many common parts in each embodiment, and then explain each embodiment for implementing the present invention.

[1. Overview of mobile communication systems]
Here, a mobile communication system will be described.

First, Figure 1 is a diagram for explaining an overview of a mobile communication system 1, and Figure 2 is a diagram for explaining a detailed configuration of the mobile communication system 1.

In Figure 1, it is shown that the mobile communication system 1 is composed of UE (User Equipment)_10, access network_100, access network_102, core network_200, and DN (Data Network)_300. Note that symbols for these devices and networks may be omitted and referred to as UE, access network, core network, DN, etc.

Figure 2 also shows device and network functions such as UE_10, base station device_110, base station device_120, AMF (Access and Mobility Management Function)_210, SMF (Session Management Function)_220, UPF (User Plane Function)_230, N3IWF (Non-3GPP InterWorking Function)_240, PCF (Policy Control Function)_250, and DN_300, as well as interfaces that connect these device and network functions to each other.

The 5G system, 5GS (5G System), is composed of a UE, an access network, and a core network, but may also include a DN.

The UE is a device that can connect to a network service via 3GPP access (also referred to as a 3GPP access network, 3GPP AN) and/or non-3GPP access (also referred to as a non-3GPP access network, non-3GPP AN). The UE may be a terminal device capable of wireless communication such as a mobile phone or smartphone, and may be a terminal device that can connect to both the 4G system EPS (Evolved Packet System) and 5GS. The UE may be equipped with a UICC (Universal Integrated Circuit Card) or eUICC (Embedded UICC). The UE may be referred to as a user device or a terminal device. The UE may be capable of using the ATSSS function and/or the eATSSS function.

The access network may also be referred to as a 5G access network (5G AN). A 5G AN is composed of an NG-RAN (NG Radio Access Network) and/or a non-3GPP access network (non-3GPP AN).

One or more base station devices are deployed in the NG-RAN. The base station device may be a gNB. The gNB is a node that provides the NR (New Radio) user plane and control plane to the UE, and is a node that connects to 5GC via an NG interface (including an N2 interface or an N3 interface). In other words, the gNB is a base station device newly designed for 5GS, and has functions different from those of the base station device (eNB) used in EPS. In addition, when there are multiple gNBs, each gNB is connected to each other, for example, via an Xn interface. Note that the base station device_110 corresponds to a gNB.

In the following, NG-RAN may be referred to as 3GPP access. In addition, non-3GPP AN may be referred to as non-3GPP access. In addition, nodes deployed in the access network may be collectively referred to as NG-RAN nodes.

In addition, in the following, the devices included in the access network and/or the devices included in the access network may be referred to as access network devices.

Note that access network_100 supports 3GPP access, and access network_102 supports non-3GPP access.

In addition, base station device _110 is arranged in access network _100, and base station device _120 and/or TNAP (Trusted Non-3GPP Access Point) are arranged in access network _102. Furthermore, base station device _110 and/or base station device _120 and/or TNAP may be able to use ATSSS function and/or eATSSS function.

In addition, access network _102 may also be referred to as Untrusted Non-3GPP access or Trusted Non-3GPP access. Base station device _120 and N3IWF in FIG. 2 are described for the case of Untrusted Non-3GPP access. In other words, when access network _102 is Untrusted Non-3GPP access, base station device _120 and N3IWF are used. In addition, when access network _102 is Trusted Non-3GPP access (also referred to as TNAN), TNAP and TNGF (Trusted Non-3GPP Gateway Function) are used instead of base station device _120 and N3IWF.

The core network also supports 5GC (5G Core Network). For example, AMF, UPF, SMF, PCF, etc. are arranged in 5GC. Here, 5GC may be expressed as 5GCN. In addition, AMF and/or UPF and/or SMF and/or PCF may be able to use ATSSS function and/or eATSSS function.

Furthermore, the N3IWF and TNGF may be located in the access network_102 or the core network_200. The N3IWF and/or the TNGF may be capable of utilizing ATSSS functionality and/or eATSSS functionality.

In addition, in the following, the core network and/or the devices included in the core network may be referred to as core network devices.

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

Furthermore, the DN may be a DN that provides a communication service to the UE. The DN may be configured as a packet data service network, or may be configured for each service. Furthermore, the DN may include a connected communication terminal. Therefore, connecting to the DN may be connecting to a communication terminal or a server device arranged in the DN. Furthermore, transmitting and receiving user data between the DN may be transmitting and receiving user data to and from a communication terminal or a server device arranged in the DN.

In addition, hereinafter, the access network, the core network, at least a portion of the DN, and/or one or more devices included therein may be referred to as a network or a network device. In other words, a network and/or a network device sending and receiving messages and/or executing procedures may mean that the access network, the core network, at least a portion of the DN, and/or one or more devices included therein send and receive messages and/or execute procedures.

The UE can also connect to an access network. The UE can also connect to a core network via the access network. The UE can also connect to a DN via the access network and the core network. That is, the UE can send and receive (communicate) user data with the DN. When the UE sends and receives user data, it may use not only IP (Internet Protocol) communication but also non-IP communication.

Here, IP communication refers to data communication using IP, and data is sent and received using IP packets. IP packets consist of an IP header and a payload section. The payload section may include data sent and received by devices and functions included in EPS and devices and functions included in 5GS.

Non-IP communication is data communication that does not use IP, and data is sent and received in a format different from the IP packet structure. For example, non-IP communication may be data communication realized by sending and receiving application data without an IP header, or user data sent and received by the UE with a different header such as a MAC header or an Ethernet (registered trademark) frame header.

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

Each memory unit (memory unit_330, memory unit_440, memory unit_540) in each device/function described below is composed of, for example, a semiconductor memory, a solid state drive (SSD), a hard disk drive (HDD), etc. Each memory unit can store not only information that was originally set at the time of shipment, but also various information transmitted and received between the device/function other than the device/function itself (for example, UE, and/or access network device, and/or core network device, and/or PDN, and/or DN). Each memory unit can store identification information, control information, flags, parameters, etc. contained in control messages transmitted and received within various communication procedures described below. Each memory unit may also store this information for each UE.

[2.1. UE_10 device configuration]
First, an example of the device configuration of the UE used in each embodiment will be described with reference to Fig. 3. The UE is composed of a control unit_300, an antenna_310, a transceiver unit_320, and a memory unit_330. The control unit_300, the transceiver unit_320, and the memory unit_330 are connected via a bus. The transceiver unit_320 is connected to the antenna_310.

The control unit_300 is a functional unit that controls the operation and functions of the entire UE. The control unit_300 may process all functions that are not possessed by other functional units in the UE (the transceiver unit_320, the memory unit_330). The control unit_300 realizes various processes in the UE by reading and executing various programs stored in the memory unit_330 as necessary.

In addition, the control unit _300 may have a function of determining whether to request communication via the ATSSS function and/or the eATSSS function according to control information received from the core network side or control information stored in the memory unit _330. For example, the control unit _300 may determine whether to request communication via the ATSSS function and/or the eATSSS function based on one or more URSP rules received from the PCF.

In addition, when communication is performed using the ATSSS function or the eATSSS function, the control unit _300 may have a function to determine to which access the uplink traffic should be routed in accordance with one or more ATSSS rules received from the SMF.

In addition, the control unit_300 controls the transceiver unit 320 in accordance with these decisions so as to enable appropriate communication.

The transceiver unit _320 is a functional unit for wirelessly communicating with base station devices in the access network via the antenna _310. That is, the UE can use the transceiver unit _320 to transmit and receive user data and/or control information between the access network device, and/or the core network device, and/or the DN.

Specifically, the UE can communicate with base station device_110, base station device_120, and the TNAP by using the transceiver unit_320. That is, when the UE communicates via 3GPP access, it communicates with base station device_110. Also, when the UE communicates via non-3GPP access, it communicates with base station device_120 or the TNAP. More specifically, when the UE communicates via untrusted non-3GPP access, it communicates with base station device_120, and when the UE communicates via trusted non-3GPP access, it communicates with the TNAP. In this way, there are three possible communication paths between the UE and the access network device.

In addition, the UE can communicate with core network devices (AMF, SMF, UPF, etc.) by using the transceiver unit_320.

The UE can also send and receive NAS (Non-Access-Stratum) messages with the AMF via the N1 interface (interface between the UE and the AMF). However, since the N1 interface is a logical interface, in reality, communication between the UE and the AMF is performed via the base station device _110, the base station device _120, and the TNAP. Specifically, when the UE communicates via 3GPP access, it can communicate with the AMF via the base station device _110. When the UE communicates via non-3GPP access (untrusted non-3GPP access), it can communicate with the AMF via the base station device _120 and the N3IWF. When the UE communicates via non-3GPP access (trusted non-3GPP access), it can communicate with the AMF via the TNAP and the TNGF. In this way, there can be three communication paths between the UE and the AMF. Note that the information exchanged between the UE and the AMF may mainly be control information.

The UE can also communicate with the SMF using the N1 interface and the N11 interface (interface between the AMF and the SMF). Specifically, the UE can communicate with the SMF via the AMF. More specifically, when communicating via 3GPP access, the UE can communicate with the SMF via the base station device_110 and the AMF. When communicating via non-3GPP access (untrusted non-3GPP access), the UE can also communicate with the SMF via the base station device_120, the N3IWF, and the AMF. When communicating via non-3GPP access (trusted non-3GPP access), the UE can also communicate with the SMF via the TNAP, the TNGF, and the AMF. In this way, there can be three communication paths between the UE and the SMF. The information exchanged between the UE and the SMF may mainly be control information.

The UE can also communicate with the UPF using the N3 interface (interface between the access network and the UPF). Specifically, when communicating via 3GPP access, the UE can communicate with the UPF via base station device_110. When communicating via non-3GPP access (untrusted non-3GPP access), the UE can also communicate with the UPF via base station device_120 and the N3IWF. When communicating via non-3GPP access (trusted non-3GPP access), the UE can also communicate with the UPF via the TNAP and the TNGF. In this way, there can be three communication paths between the UE and the UPF. The information exchanged between the UE and the UPF may mainly be user data.

The UE can also communicate with the PCF using the N1 interface, the N11 interface, and the N7 interface (interface between the SMF and the PCF). Specifically, the UE can communicate with the PCF via the AMF and the SMF. More specifically, when communicating via 3GPP access, the UE can communicate with the PCF via the base station device_110, the AMF, and the SMF. When communicating via non-3GPP access (untrusted non-3GPP access), the UE can communicate with the PCF via the base station device_120, the N3IWF, the AMF, and the SMF. When communicating via non-3GPP access (trusted non-3GPP access), the UE can communicate with the PCF via the TNAP, the TNGF, the AMF, and the SMF. In this way, there can be three communication paths between the UE and the PCF. The information exchanged between the UE and the PCF may mainly be control information.

The UE can also communicate with the DN using the N3 interface and the N6 interface (the interface between the UPF and the DN). Specifically, when communicating via 3GPP access, the UE can communicate with the DN via the base station device_110 and the UPF. When communicating via non-3GPP access (untrusted non-3GPP access), the UE can communicate with the DN via the base station device_120, the N3IWF, and the UPF. When communicating via non-3GPP access (trusted non-3GPP access), the UE can communicate with the DN via the TNAP, the TNGF, and the UPF. In this way, there can be three communication paths between the UE and the DN. The information exchanged between the UE and the DN may mainly be user data.

Note that the above only describes communication between the UE and representative devices/functions in this specification, and the UE may be able to communicate with devices/functions other than those listed above, i.e., access network devices and/or core network devices other than those listed above, etc.

Moreover, the memory unit _330 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UE. Moreover, it is desirable that the control information received from the core network side is stored in the memory unit _330. For example, the memory unit _330 may store the ATSSS rule, and/or the first ATSSS rule, and/or the second ATSSS rule, etc.

The UE may also be a UE that supports ATSSS functionality and/or eATSSS functionality.

[2.2. Configuration of base station device 110]
Next, an example of the device configuration of the base station device_110 used in each embodiment will be described with reference to FIG.

The base station device_110 is a base station device deployed in a 3GPP access. The base station device_110 is composed of a control unit_400, an antenna_410, a network connection unit_420, a transmission/reception unit_430, and a memory unit_440. The control unit_400, the network connection unit_420, the transmission/reception unit_430, and the memory unit_440 are connected via a bus. The transmission/reception unit_430 is connected to the antenna_410.

The control unit_400 is a functional unit that controls the operation and functions of the entire base station device_110. The control unit_400 may process all functions that are not possessed by other functional units in the base station device_110 (network connection unit_420, transceiver unit_430, memory unit_440). The control unit_400 realizes various processes in the base station device_110 by reading and executing various programs stored in the memory unit_440 as necessary.

The network connection unit _420 is a functional unit that enables the base station device _110 to communicate with other access network devices and/or AMF and/or UPF. In other words, the base station device _110 can use the network connection unit _420 to transmit and receive control information and/or user data between other access network devices and/or AMF and/or UPF, etc.

Specifically, by using network connection unit _420, base station device _110 can communicate with other access network devices via the Xn interface (interface between access network devices). By using network connection unit _420, base station device _110 can communicate with AMF via the N2 interface (interface between access network and AMF). In addition, by using network connection unit _420, base station device _110 can communicate with UPF via the N3 interface.

The transceiver unit _430 is a functional unit for wirelessly communicating with the UE via the antenna _410. That is, the base station device _110 can transmit and receive user data and/or control information between the UE and the transceiver unit _430 and the antenna _410.

In addition, when base station device _110 receives user data and/or control information addressed to a core network device from a UE, it has a function of transmitting the user data and/or control information to the core network device. In addition, base station device _110 has a function of transmitting user data and/or control information to the UE when it receives user data and/or control information addressed to a UE from a core network device.

Note that the above only describes the communication between base station device _110 and representative devices/functions, and base station device _110 may be able to communicate with devices/functions other than those listed above, i.e., access network devices and/or core network devices other than those listed above, etc.

The memory unit _440 is a functional unit for storing programs, user data, control information, etc. required for each operation of the base station device _110.

Furthermore, base station device_110 may be a base station device that supports ATSSS function and/or eATSSS function.

[2.3. Configuration of base station device 120]
Next, an example of the device configuration of the base station device_120 used in each embodiment will be described with reference to FIG.

The base station device_120 is a base station device deployed in non-3GPP access (untrusted non-3GPP access). The base station device_120 is composed of a control unit_400, an antenna_410, a network connection unit_420, a transmission/reception unit_430, and a memory unit_440. The control unit_400, the network connection unit_420, the transmission/reception unit_430, and the memory unit_440 are connected via a bus. The transmission/reception unit_430 is connected to the antenna_410.

The control unit_400 is a functional unit that controls the operation and functions of the entire base station device_120. The control unit_400 may process all functions that are not possessed by other functional units in the base station device_120 (network connection unit_420, transceiver unit_430, memory unit_440). The control unit_400 realizes various processes in the base station device_120 by reading and executing various programs stored in the memory unit_440 as necessary.

The network connection unit _420 is a functional unit for the base station device _120 to communicate with the N3IWF, and is a functional unit for communicating with the AMF and/or UPF via the N3IWF. That is, the base station device _120 can send and receive control information and/or user data with the N3IWF using the network connection unit _420. In addition, the base station device _120 can send and receive control information and/or user data with the AMF and/or UPF, etc., via the N3IWF using the network connection unit _420.

In other words, by using the network connection unit _420, the base station device _120 can communicate with the N3IWF via the Y2 interface (the interface between the access network and the N3IWF). The base station device _120 can also communicate with the AMF via the N2 interface (the interface between the N3IWF and the AMF) via the N3IWF. The base station device _120 can also communicate with the UPF via the N3 interface (the interface between the N3IWF and the UPF) via the N3IWF.

The transceiver unit _430 is a functional unit for wirelessly communicating with the UE via the antenna _410. That is, the base station device _120 can transmit and receive user data and/or control information to and from the UE via the Y1 interface (the interface between the access network and the UE) using the transceiver unit _430 and the antenna _410.

In addition, when base station device_120 receives user data and/or control information addressed to a core network device from a UE, it has a function of transmitting the user data and/or control information to the core network device. In addition, base station device_120 has a function of transmitting user data and/or control information to the UE when it receives user data and/or control information addressed to a UE from a core network device.

Note that the above only describes the communication between base station device _120 and representative devices/functions, and base station device _120 may be able to communicate with devices/functions other than those listed above, i.e., access network devices and/or core network devices other than those listed above, etc.

The memory unit _440 is a functional unit for storing programs, user data, control information, etc. required for each operation of the base station device _120.

Furthermore, base station device_120 may be a base station device that supports ATSSS function and/or eATSSS function.

[2.4. TNAP device configuration]
Next, an example of the device configuration of the TNAP used in each embodiment will be described with reference to Fig. 4. The TNAP is a base station device (also called an access point) arranged in non-3GPP access (Trusted non-3GPP access). The TNAP is composed of a control unit_400, an antenna_410, a network connection unit_420, a transmission/reception unit_430, and a memory unit_440. The control unit_400, the network connection unit_420, the transmission/reception unit_430, and the memory unit_440 are connected via a bus. The transmission/reception unit_430 is connected to the antenna_410.

The control unit _400 is a functional unit that controls the operation and functions of the entire TNAP. The control unit _400 may process all functions that are not possessed by other functional units in the TNAP (network connection unit _420, transmission/reception unit _430, memory unit _440). The control unit _400 realizes various processes in the TNAP by reading and executing various programs stored in the memory unit _440 as necessary.

The network connection unit _420 is a functional unit for the TNAP to communicate with the TNGF, and is a functional unit for communicating with the AMF and/or UPF via the TNGF. In other words, the TNAP can send and receive control information and/or user data with the TNGF using the network connection unit _420. In addition, the TNAP can send and receive control information and/or user data with the AMF and/or UPF, etc., via the TNGF using the network connection unit _420.

In other words, by using the network connection unit_420, the TNAP can communicate with the TNGF via the Ta interface (the interface between the TNAP and the TNGF). The TNAP can also communicate with the AMF via the TNGF via the N2 interface (the interface between the TNGF and the AMF). The TNAP can also communicate with the UPF via the TNGF via the N3 interface (the interface between the TNGF and the UPF).

The transceiver unit _430 is a functional unit for wireless communication with the UE via the antenna _410. That is, the TNAP can transmit and receive user data and/or control information to and from the UE via the Yt interface (the interface between the TNAP and the UE) using the transceiver unit _430 and the antenna _410.

In addition, when the TNAP receives user data and/or control information addressed to a core network device from a UE, it has a function of transmitting the user data and/or control information to the core network device. In addition, when the TNAP receives user data and/or control information addressed to a UE from a core network device, it has a function of transmitting the user data and/or control information to the UE.

Note that the above only describes communication between the TNAP and representative devices/functions, and the TNAP may be able to communicate with devices/functions other than those listed above, i.e., access network devices and/or core network devices other than those listed above, etc.

The memory unit_440 is a functional unit for storing programs, user data, control information, etc. required for each operation of the TNAP.

The TNAP may also be a TNAP that supports ATSSS and/or eATSSS functions.

[2.5. N3IWF_240 device configuration]
Next, an example of the device/functional configuration of the N3IWF used in each embodiment will be described with reference to Fig. 5. The N3IWF is a device and/or function arranged between the non-3GPP access and the 5GC when the UE connects to the 5GS via the non-3GPP access (untrusted non-3GPP access), and is specifically arranged in the non-3GPP access (untrusted non-3GPP access) or the core network. The N3IWF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus.

The control unit_500 is a functional unit that controls the operation and functions of the entire N3IWF. The control unit_500 may process all functions that are not possessed by other functional units in the N3IWF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the N3IWF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit _520 is a functional unit that enables the N3IWF to communicate with the base station device _120 and/or the AMF and/or the UPF. That is, the N3IWF can send and receive control information and/or user data between the base station device _120 using the network connection unit _520. The N3IWF can also send and receive control information and/or user data between the AMF and/or the UPF, etc. using the network connection unit _520.

In other words, the N3IWF can communicate with the base station device _120 via the Y2 interface by using the network connection unit _520. The N3IWF can also communicate with the AMF via the N2 interface. The N3IWF can also communicate with the UPF via the N3 interface.

Note that the above only describes the communication between the N3IWF and representative devices/functions, and the N3IWF may be able to communicate with devices/functions other than those listed above, i.e., access network devices and/or core network devices other than those listed above, etc.

The memory unit_540 is a functional unit for storing programs, user data, control information, etc. required for each operation of the N3IWF.

The N3IWF has the functions of establishing an IPsec tunnel with the UE, terminating the N2 interface for the control plane, terminating the N3 interface for the user plane, relaying NAS signaling between the UE and the AMF, processing N2 signaling from the SMF for PDU sessions and QoS, establishing an IPsec SA (Security Association) to support PDU session traffic, relaying user plane packets between the UE and the UPF (including the function of encapsulating/decapsulating packets for IPsec and the N3 tunnel), functioning as a local mobility anchor in an untrusted non-3GPP access network, and selecting an AMF. All of these functions may be controlled by the control unit_500.

The N3IWF may also be an N3IWF that supports ATSSS functionality and/or eATSSS functionality.

[2.6. TNGF device configuration]
Next, an example of the device/functional configuration of the TNGF used in each embodiment will be described with reference to FIG. 5. The TNGF is a device and/or function arranged between the non-3GPP access and the 5GC when the UE connects to the 5GS via the non-3GPP access (Trusted non-3GPP access), and is specifically arranged in the non-3GPP access (Trusted non-3GPP access) or the core network. The TNGF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus.

The control unit_500 is a functional unit that controls the operation and functions of the entire TNGF. In addition, the control unit_500 may process all functions that are not possessed by other functional units in the TNGF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the TNGF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit _520 is a functional unit that enables the TNGF to communicate with the TNAP and/or AMF and/or UPF. That is, the TNGF can send and receive control information and/or user data with the TNAP using the network connection unit _520. The TNGF can also send and receive control information and/or user data with the AMF and/or UPF, etc. using the network connection unit _520.

In other words, by using the network connection unit_520, the TNGF can communicate with the TNAP via the Y2 interface. Also, the TNGF can communicate with the AMF via the N2 interface. Also, the TNGF can communicate with the UPF via the N3 interface.

Note that the above only describes communication between TNGF and representative devices/functions, and TNGF may be able to communicate with devices/functions other than those listed above, i.e. access network devices and/or core network devices other than those listed above, etc.

The memory unit_540 is a functional unit for storing programs, user data, control information, etc. required for each operation of the TNGF.

The TNGF has functions such as terminating the N2 and N3 interfaces, acting as an authorizer when the UE registers to 5GC via the TNAN, selecting an AMF, transparently (without processing) relaying NAS messages between the UE and the AMF, processing SMF and N2 signaling to support PDU sessions and QoS, transparently (without processing) relaying PDUs between the UE and the UPF, and acting as a local mobility anchor within the TNAN. All of these functions may be controlled by the control unit_500.

The TNGF may also be a TNGF that supports ATSSS function and/or eATSSS function.

[2.7. AMF_210 device configuration]
Next, an example of the device configuration of the AMF used in each embodiment will be described with reference to Fig. 5. The AMF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus. The AMF may be a node that handles the control plane.

The control unit_500 is a functional unit that controls the operation and functions of the entire AMF. The control unit_500 may process all functions that are not possessed by other functional units in the AMF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the AMF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit_520 is a functional unit for the AMF to connect to base station devices in the 5G AN, and/or other AMFs, and/or SMFs, and/or PCFs, and/or NSSFs (Network Slice Selection Functions), and/or UDMs (Unified Data Management), and/or SCEFs (Service Capability Exposure Functions). In other words, the AMF can use the network connection unit_520 to transmit and receive user data and/or control information between base station devices in the 5G AN, and/or other AMFs, and/or SMFs, and/or PCFs, and/or NSSFs, and/or UDMs, and/or SCEFs.

Explaining in detail with reference to FIG. 2, the AMF in 5GC can communicate with a base station device via the N2 interface by using the network connection unit _520, can communicate with other AMFs via the N14 interface (interface between AMFs), can communicate with an SMF via the N11 interface, can communicate with a PCF via the N15 interface (interface between AMF and PCF), can communicate with an NSSF via the N22 interface (interface between AMF and NSSF), and can communicate with a UDM via the N8 interface (interface between AMF and UDM). In addition, the AMF can send and receive NAS messages with the UE via the N1 interface by using the network connection unit _520. However, since the N1 interface is logical, in reality, communication between the UE and the AMF is performed via the 5G AN.

The memory unit_540 is a functional unit for storing programs, user data, control information, etc. required for each operation of the AMF.

The AMF has a function of exchanging control messages with the RAN using the N2 interface, a function of exchanging NAS messages with the UE using the N1 interface, a function of encrypting and protecting the integrity of NAS messages, a registration management (RM) function, a connection management (CM) function, a reachability management function, a mobility management function for UEs, etc., a function of transferring SM (Session Management) messages between the UE and the SMF, an access authentication (Access Authorization) function, a security anchor functionality (SEA; Security Anchor Functionality), a security context management (SCM; Security Context Management) function, a function of supporting the N2 interface for the N3IWF (Non-3GPP Interworking Function), a function of supporting the transmission and reception of NAS signals with the UE via the N3IWF, a function of authenticating the UE connected via the N3IWF, and the like. All of these functions may be controlled by the control unit_500.

In addition, in registration management, the RM state of each UE is managed. The RM state may be synchronized between the UE and the AMF. There are two RM states: the unregistered state (RM-DEREGISTERED state) and the registered state (RM-REGISTERED state). In the RM-DEREGISTERED state, the UE is not registered in the network, so the UE context in the AMF does not have valid location information or routing information for the UE, and the AMF cannot reach the UE. In the RM-REGISTERED state, the UE is registered in the network, so the UE can receive services that require registration with the network. The RM state may be expressed as the 5GMM state. In this case, the RM-DEREGISTERED state may be expressed as the 5GMM-DEREGISTERED state, and the RM-REGISTERED state may be expressed as the 5GMM-REGISTERED state.

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

Furthermore, the 5GMM-DEREGISTERED state may be a state in which each device has not established a 5GMM context, a state in which the location information of UE_10 is not known to the network, or a state in which UE_10 is unreachable by the network. When each device is in the 5GMM-DEREGISTERED state, UE_10 may initiate a registration procedure or establish a 5GMM context by performing the registration procedure.

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

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

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

In addition, one or more AMFs may be deployed within a core network. In addition, an AMF may be an NF that manages one or more NSIs (Network Slice Instances). In addition, an AMF may be a shared CP function (CCNF; Common CPNF (Control Plane Network Function)) shared between multiple NSIs.

The AMF may also be an AMF that supports ATSSS functions and/or eATSSS functions.

[2.8. SMF_220 device configuration]
Next, an example of the device configuration of the SMF used in each embodiment will be described with reference to Fig. 5. The SMF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus. The SMF may be a node that handles the control plane.

The control unit_500 is a functional unit that controls the operation and functions of the entire SMF. The control unit_500 may process all functions that are not possessed by other functional units in the SMF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the SMF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit_520 is a functional unit for connecting the SMF to the AMF, and/or the UPF, and/or the PCF, and/or the UDM. In other words, the SMF can use the network connection unit_520 to send and receive user data and/or control information between the AMF, and/or the UPF, and/or the PCF, and/or the UDM.

Explaining in detail with reference to Figure 2, the SMF in the 5GC can communicate with the AMF via the N11 interface, can communicate with the UPF via the N4 interface (interface between the SMF and the UPF), can communicate with the PCF via the N7 interface, and can communicate with the UDM via the N10 interface (interface between the SMF and the UDM) by using the network connection unit _520.

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

The SMF also has a session management function such as establishing, modifying, and releasing PDU sessions, IP address allocation for UEs and its management function, UPF selection and control function, UPF setting function for routing traffic to the appropriate destination (destination), function for sending and receiving the SM portion of NAS messages, function for notifying that downlink data has arrived (Downlink Data Notification), function for providing AN-specific (for each AN) SM information which is sent to the AN via the N2 interface via the AMF, function for determining the SSC mode (Session and Service Continuity mode) for the session, roaming function, etc.

The SMF may also have a function of generating a first ATSSS rule and a first N4 rule from the first PCC rule received from the PCF. The SMF may also manage (i.e., map) the first PCC rule, the first ATSSS rule, and the first N4 rule in association with each other. The SMF may also have a function of generating a second ATSSS rule and a second N4 rule from the second PCC rule received from the PCF. The SMF may also manage (i.e., map) the second PCC rule, the second ATSSS rule, and the second N4 rule in association with each other.

These functions may be controlled by the control unit_500. Furthermore, the mapped information may be stored in the memory unit_540.

The SMF may also be an SMF that supports ATSSS and/or eATSSS functions.

[2.9. UPF_230 device configuration]
Next, an example of the device configuration of the UPF used in each embodiment will be described with reference to Fig. 5. The UPF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus. The UPF may be a node that handles the user plane.

The control unit_500 is a functional unit that controls the operation and functions of the entire UPF. The control unit_500 may process all functions that are not possessed by other functional units in the UPF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the UPF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit_520 is a functional unit for the UPF to connect to base station devices, and/or SMFs, and/or other UPFs, and/or DNs in the 5G AN. In other words, the UPF can use the network connection unit_520 to transmit and receive user data and/or control information between base station devices, and/or SMFs, and/or other UPFs, and/or DNs in the 5G AN.

Explaining in detail with reference to Figure 2, a UPF in 5GC can, by using network connection unit _520, communicate with a base station device via the N3 interface, communicate with an SMF via the N4 interface, communicate with other UPFs via the N9 interface (interface between UPFs), and communicate with a DN via the N6 interface.

The memory unit _540 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UPF. In addition, it is desirable that the control information received from the SMF is stored in the memory unit _540. For example, the memory unit _540 may store an N4 rule and/or a first N4 rule and/or a second N4 rule.

The UPF has the following functions: an anchor point (also called an end point) for intra-RAT mobility or inter-RAT mobility; an external PDU session point for interconnecting with DNs (i.e., a gateway between DNs and core networks to forward user data); a packet routing and forwarding function; an UL CL (Uplink Classifier) function supporting the routing of multiple traffic flows for one DN; a branching point function supporting multi-homed PDU sessions; a QoS (Quality of Service) processing function for user plane; an uplink traffic verification function; a downlink packet buffering function; and a downlink data notification triggering function. The UPF may also have a function for determining which access the downlink traffic should be routed to based on the N4 rule and/or the first N4 rule and/or the second N4 rule received from the SMF. All of these functions may be controlled by the control unit_500.

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

The user plane (also referred to as U-Plane or UP) may refer to user data transmitted and received between the UE and the network. The user plane may be transmitted and received using a PDU session. Furthermore, in the case of 5GS, the user plane may be transmitted and received via the interface between the UE and the NG RAN, and/or the N3 interface, and/or the N9 interface, and/or the N6 interface.

Furthermore, the control plane (C-Plane, also referred to as CP) refers to control messages transmitted and received to control UE communications, etc. The control plane may be transmitted and received using a NAS (Non-Access-Stratum) signaling connection between the UE and the AMF. Furthermore, in the case of 5GS, the control plane may be transmitted and received using the interface between the UE and the NG RAN and the N2 interface.

Furthermore, the user plane may be a communication path for transmitting and receiving user data and may be composed of multiple bearers. Furthermore, the communication path for transmitting and receiving user data may be called user plane resources. Furthermore, the control plane may be a communication path for transmitting and receiving control messages and may be composed of multiple bearers.

The UPF may also be a UPF that supports ATSSS functionality and/or eATSSS functionality.

[2.10. PCF_250 device configuration]
Next, an example of the device configuration of the PCF used in each embodiment will be described with reference to Fig. 5. The PCF is composed of a control unit _500, a network connection unit _520, and a memory unit _540. The control unit _500, the network connection unit _520, and the memory unit _540 are connected via a bus.

The control unit_500 is a functional unit that controls the operation and functions of the entire PCF. The control unit_500 may process all functions that are not possessed by other functional units in the PCF (network connection unit_520, memory unit_540). The control unit_500 realizes various processes in the PCF by reading and executing various programs stored in the memory unit_540 as necessary.

The network connection unit_520 is a functional unit that enables the PCF to connect to the AMF, and/or the SMF, and/or the AF (Application Function). In other words, the PCF can use the network connection unit_520 to send and receive control information between the AMF, and/or the SMF, and/or the AF.

By using the network connection unit_520, the PCF can communicate with the AMF via the N15 interface, can communicate with the SMF via the N7 interface, and can communicate with the AF via the N5 interface (the interface between the PCF and the AF).

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

The PCF has functions to support a unified policy framework, provide policy rules to the control plane functions to enforce them, and access subscription information. The PCF also has functions to generate PCC rules, and/or first PCC rules, and/or second PCC rules, and URSP (UE Route Selection Policy) rules, etc. All of these functions may be controlled by the control unit_500.

The PCF may also be a PCF that supports ATSSS and/or eATSSS functions.

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

[3.1. Explanation of highly technical terms used in each embodiment]
First, highly technical terms used in each embodiment will be described.

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

In addition, an SM (Session Management) message (also referred to as a NAS (Non-Access-Stratum) SM message) may be a NAS message used in a procedure for SM, and may be a control message transmitted and received between a UE and an SMF via an AMF. Furthermore, the SM message may include a PDU session establishment request message, a PDU session establishment acceptance message, a PDU session completion message, a PDU session rejection message, a PDU session change request message, a PDU session change acceptance message, a PDU session change response message, etc. In addition, the procedure for SM may include a PDU session establishment procedure.

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

In addition, non-5GS services may be services other than 5GS services and may include EPS services and/or non-EPS services.

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

A PDU session can be defined as an association between a DN and a UE that provides a PDU connectivity service, but specifically, it may be connectivity established between a UE and an external gateway or a DN. In 5GS, a UE can transmit and receive user data between the UE and the DN by establishing a PDU session via an access network and a core network. Here, the external gateway may be a UPF, a SCEF, or the like. A UE can transmit and receive user data between an application server or other device located in a DN using a PDU session. A PDU connectivity service is a service that provides an exchange of PDUs between a UE and a DN. The PDU session may be configured by user plane resources in one access network (3GPP access network or non-3GPP access network). The PDU session may be a PDU session that is not configured by user plane resources via a 3GPP access and user plane resources via a non-3GPP access at the same time, unlike an MA PDU session. In addition, such a PDU session may be referred to as a SA (Single Access) PDU session.

In addition, an SA PDU session may refer to an SA PDU session via 3GPP access and an SA PDU session via non-3GPP access used for communication via the eATSSS function.

The eATSSS function may be a function that enables communication between the UE and the DN using at least two or more SA PDU sessions consisting of one or more SA PDU sessions via 3GPP access and one or more SA PDU sessions via non-3GPP access. In other words, the eATSSS function enables the UE to transmit and receive user data to and from the DN and/or devices/functions such as an application server located in the DN using two or more SA PDU sessions.

Furthermore, when a UE communicates using the eATSSS function, it means that the UE communicates with a DN using at least two or more SA PDU sessions consisting of one or more SA PDU sessions via 3GPP access and one or more SA PDU sessions via non-3GPP access. When a UE communicates using the eATSSS function, it may mean that the UE communicates with a DN using only two or more SA PDU sessions via 3GPP access, or it may mean that the UE communicates with a DN using only two or more SA PDU sessions via non-3GPP access.

Also, the MA PDU session may be a PDU session that provides a PDU connectivity service that can use one 3GPP access network and one non-3GPP access network simultaneously. Also, the MA PDU session may be a PDU session that provides a PDU connectivity service that can use one 3GPP access network or one non-3GPP access network at a certain time. In other words, the MA PDU session may be composed of user plane resources via 3GPP access and/or user plane resources via non-3GPP access. Also, the UE communicating through the ATSSS function may mean that the UE communicates with the DN using the MA PDU session.

The ATSSS function may be a function that enables communication between the UE and the DN using one MA PDU session consisting of user plane resources via 3GPP access and/or user plane resources via non-3GPP access. In other words, the ATSSS function allows the UE to transmit and receive user data to and from the DN and/or devices/functions such as an application server located in the DN using one MA PDU session.

In addition, when a UE communicates using the ATSSS function, it may mean that the UE communicates with the DN using one MA PDU session, or it may mean that the UE communicates with the DN using only user plane resources via 3GPP access, or it may mean that the UE communicates with the DN using only user plane resources via non-3GPP access, or it may mean that the UE communicates with the DN using user plane resources via 3GPP access and user plane resources via non-3GPP access.

In addition, each device (UE, and/or access network device, and/or core network device) may associate and manage one or more identification information, DNN, TFT, PDU session type, application identification information, NSI identification information, access network identification information, SSC mode, and other information for an SA PDU session or an MA PDU session.

In addition, in the following, MA PDU sessions and SA PDU sessions may be collectively referred to as PDU sessions.

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

A network slice (NS) is a logical network that provides specific network capabilities and network characteristics. In 5GS, a UE and/or a network can support network slices (NW slices; NS).

A network slice instance (NSI) is composed of an instance (entity) of a network function (NF) and a set of required resources, forming a network slice to be deployed. Here, an NF is a processing function in a network, adopted or defined by 3GPP. An NSI is an entity of an NS, of which one or more are configured in a core network. An NSI may also be composed of a virtual NF (Network Function) generated using an NST (Network Slice Template). Here, an NST is associated with a resource requirement for providing a required communication service or capability, and is a logical representation of one or more NFs. In other words, an NSI may be a collection in a core network composed of multiple NFs. An NSI may also be a logical network configured to separate user data delivered by a service, etc. An NS may be configured with one or more NFs. An NF configured in an NS may or may not be a device shared with other NSs. A UE and/or a device in the network may be assigned to one or more NSs based on registration information such as an NSSAI, an S-NSSAI, an UE usage type, an NSI ID, or one or more NSI IDs, and/or an APN. The UE usage type is a parameter value included in the registration information of the UE that is used to identify the NSI. The UE usage type may be stored in the HSS. The AMF may select an SMF and a UPF based on the UE usage type.

S-NSSAI (Single Network Slice Selection Assistance Information) is information for identifying an NS. S-NSSAI may be composed of only SST (Slice/Service type) or may be composed of both SST and SD (Slice Differentiator). Here, SST is information indicating the expected operation of NS in terms of functions and services. SD may be information for interpolating SST when selecting one NSI from multiple NSIs indicated by SST. S-NSSAI may be information specific to each PLMN or may be standard information common among PLMNs. The network may store one or more S-NSSAIs in the registration information of the UE as a default S-NSSAI. In addition, when S-NSSAI is the default S-NSSAI, if the UE does not send a valid S-NSSAI to the network in the registration request message, the network may provide the NS related to the UE.

Furthermore, NSSAI (Network Slice Selection Assistance Information) is a collection of S-NSSAI. Each S-NSSAI included in the NSSAI is information that assists the access network or core network in selecting an NSI. The UE may store the NSSAI authorized by the network for each PLMN. Furthermore, the NSSAI may be information used to select an AMF.

In addition, the SSC mode indicates a session and service continuity mode supported by the system and/or each device in a 5G system (5GS). More specifically, it may be a mode indicating a type of session service continuity supported by a PDU session established between a UE and a UPF. The SSC mode may be a mode indicating a type of session service continuity set for each PDU session. Furthermore, the SSC mode may be composed of three modes: SSC mode 1, SSC mode 2, and SSC mode 3. The SSC mode associated with a PDU session does not need to be changed while the PDU session exists.

In addition, SSC mode 1 is a mode in which the network maintains the connectivity service it provides to the UE. In addition, if the PDU session type associated with the PDU session is IPv4 or IPv6, the IP address may be maintained when the session service is continued.

Furthermore, SSC mode 1 may be a session service continuity mode in which the same UPF is maintained regardless of the access technology used by the UE when connecting to the network. More specifically, SSC mode 1 may be a mode that realizes session service continuity without changing the UPF used as the PDU session anchor for the established PDU session even when UE mobility occurs.

In addition, SSC mode 2 is a mode in which the network releases the connectivity service provided to the UE and the corresponding PDU session. In addition, in SSC mode 2, if the PDU session type associated with the PDU session is IPv4, IPv6, or IPv4v6, the IP address assigned to the UE may be released when changing the anchor of the PDU session.

Furthermore, SSC mode 2 may be a session service continuity mode in which the same UPF is maintained only within the serving area of the UPF. More specifically, SSC mode 2 may be a mode that realizes session service continuity without changing the UPF used by the established PDU session as long as the UE is within the serving area of the UPF. Furthermore, SSC mode 2 may be a mode that realizes session service continuity by changing the UPF used by the established PDU session when UE mobility occurs, such as moving out of the serving area of the UPF.

Here, the serving area of a UPF may be an area in which one UPF can provide a session service continuity function, or may be a subset of an access network, such as a RAT or a cell, that a UE uses when connecting to a network. Furthermore, the subset of an access network may be a network consisting of one or more RATs and/or cells.

In addition, a change in the anchor point of a PDU session in SSC mode 2 (hereinafter also referred to as a PDU session anchor or PSA) may be realized by each device executing a procedure to change the PSA of SSC mode 2. In addition, the anchor or anchor point may be expressed as an end point.

In addition, SSC mode 3 is a mode in which the change in the user plane is made apparent to the UE while the network ensures that connectivity is not lost. In addition, in the case of SSC mode 3, in order to realize better connectivity services, a PDU session passing through a new PDU session anchor point may be established before the established PDU session is disconnected. Furthermore, in SSC mode 3, if the PDU session type associated with the PDU session is IPv4, IPv6, or IPv4v6, the IP address assigned to the UE may not be maintained when changing the anchor of the PDU session.

Furthermore, SSC mode 3 may be a session service continuity mode that allows a new PDU session and/or communication path to be established via a new UPF for the same DN before disconnecting the PDU session and/or communication path established between the UE and the UPF. Furthermore, SSC mode 3 may be a session service continuity mode that allows the UE to be multi-homing. Furthermore, SSC mode 3 may be a mode in which session service continuity is permitted using multiple PDU sessions and/or UPFs associated with the PDU sessions. In other words, in the case of SSC mode 3, each device may realize session service continuity using multiple PDU sessions, or may realize session service continuity using multiple UPFs.

Here, when each device establishes a new PDU session and/or communication path, the selection of the new UPF may be performed by the network, and the new UPF may be the UPF that is optimal for the location where the UE connects to the network. Furthermore, when multiple PDU sessions and/or the UPF used by the PDU sessions are valid, the UE may immediately map the application and/or flow communication to the newly established PDU session or may map the application and/or flow communication based on the completion of the communication.

Furthermore, changing the anchor point of an SSC mode 3 PDU session may be achieved by each device executing a procedure to change the SSC mode 3 PSA.

The default SSC mode is an SSC mode used by the UE and/or the network when a specific SSC mode is not determined. Specifically, the default SSC mode may be an SSC mode used by the UE when there is no SSC mode request from an application and/or when there is no UE policy for determining an SSC mode for an application. The default SSC mode may be an SSC mode used by the network when there is no SSC mode request from the UE.

The default SSC mode may be set for each DN, for each PDN, for each UE, and/or for each subscriber based on subscriber information, and/or operator policy, and/or UE policy. Furthermore, the default SSC mode may be information indicating SSC mode 1, SSC mode 2, or SSC mode 3.

In addition, IP address preservation is a technology that allows the same IP address to be continued. If IP address preservation is supported, the UE can continue to use the same IP address for user data communication even when it moves outside the TA. In other words, if IP address preservation is supported, each device may be able to continue to use the same IP address for user data communication even when the anchor point of the PDU session is changed.

The steering function may be a function in which a UE supporting the ATSSS function and/or the eATSSS function and a network supporting the ATSSS function and/or the eATSSS function steer, switch, or split traffic via 3GPP access and/or non-3GPP access. Specifically, the steering function may include an MPTCP (Multi-Path Transmission Control Protocol) function, an ATSSS (Access Traffic Steering, Switching, Splitting)-LL (Low-Layer) function, and an eATSSS function.

Here, the MPTCP function is a steering function above the IP layer and is applied to TCP traffic. Traffic to which the MPTCP function is applied may be referred to as an MPTCP flow. The MPTCP function of the UE can communicate with the MPTCP proxy function of the UPF using the user plane of 3GPP access and/or non-3GPP access. The MPTCP function may be enabled when the UE requests a PDU session and provides the MPTCP capability, and the MPTCP Proxy function may be enabled when the UPF agrees to enable the MPTCP function. The network also assigns one IP address/prefix for the PDU session and two IP addresses/prefixes (also referred to as link-specific multipath addresses). One of the link-specific multipath addresses is used to establish a subflow via the 3GPP access, and the other is used to establish a subflow via the non-3GPP access. The link-specific multicast address is used only by the MPTCP function of the UE. It cannot be routed via N6. The network may also send MPTCP proxy information (which may include the IP address, port number, and type of the MPTCP proxy) to the UE, where the type may be Type 1 (transport converter). The network may also indicate to the UE a list of applications to which the MPTCP function should be applied.

The ATSSS-LL function is a steering function below the IP layer and applies to all types of traffic (TCP traffic, UDP (User Data Protocol) traffic, Ethernet traffic, etc.). Traffic to which the ATSSS-LL function is applied may be referred to as Non-MPTCP flow. The UPF may support a steering function that is the same as or similar to the ATSSS-LL function. The ATSSS-LL function of the UE determines the steering, switch, and split of uplink traffic based on the ATSSS rules and local conditions. The ATSSS-LL function may be enabled when the UE requests an SA PDU session and provides the ATSSS-LL capability, and the ATSSS-LL function in the UPF may be enabled when the UE provides the ATSSS-LL capability.

The eATSSS function may also be a new steering function different from the MPTCP function and the ATSSS-LL function. The eATSSS function may also be a function similar to the MPTCP function or the ATSSS-LL function. The eATSSS function may also be a function including the MPTCP function and the ATSSS-LL function. In other words, the MPTCP function and the ATSSS-LL function may be part of a steering function that realizes the ATSSS function, or may be part of a steering function that realizes the eATSSS function.

Additionally, the ATSSS rules may be a list of one or more ATSSS rules. An ATSSS rule may consist of a Rule Precedence, and/or a Traffic Descriptor, and/or an Access Selection Descriptor.

Here, the rule priority in the ATSSS rules defines the order in which the ATSSS rules are evaluated by the UE. When the UE receives ATSSS rules, i.e., when it receives one or more ATSSS rules, it may refer to the rule priority in each ATSSS rule and evaluate the ATSS rules in order of highest priority.

Furthermore, the traffic descriptor in the ATSSS rule indicates when the ATSSS rule is to be applied. Here, the traffic descriptor in the ATSSS rule may be composed of application descriptors, and/or IP descriptors, and/or non-IP descriptors.

Here, the application descriptor in the traffic descriptor in the ATSSS rule may indicate information identifying the application generating the traffic.

Additionally, the IP descriptor in the traffic descriptor in the ATSSS rule may indicate information identifying the destination of the IP traffic.

In addition, a non-IP descriptor in a traffic descriptor in an ATSSS rule may indicate information identifying the destination of non-IP traffic (e.g., ethernet traffic or unstructured traffic).

Additionally, the access selection descriptor in the ATSSS rule may be configured with a steering mode and/or a steering function.

Here, the steering mode may be information indicating whether traffic of a service data flow (also called SDF) should be distributed to 3GPP access or non-3GPP access. The steering mode may include four modes: Active-Standby, Smallest Delay, Load-Balancing, and Priority-based.

Active-Standby may be a mode in which active access and standby access are set, and when the active access is available, a service data flow (SDF) is steered for that access, and when the active access becomes unavailable, the SDF is switched to standby access. Active-Standby may be a mode in which, when only active access is set and standby access is not set, a service data flow (SDF) is steered for the active access when it is available, and the SDF cannot be switched to standby access even if the active access becomes unavailable.

Smallest Delay may also be a mode that steers the service data flow (SDF) to the access with the smallest RTT (Round-Trip Time). When this mode is configured, the UE and UPF may perform measurements to determine the RTT when communicating via 3GPP access and the RTT when communicating via non-3GPP access.

Load-Balancing may also be a mode for dividing the service data flow (SDF) between both accesses. When Load-Balancing is specified, it may also include information indicating the proportion of the service data flow (SDF) to be transmitted via 3GPP access and non-3GPP access.

Priority-based may also be a mode used to steer all traffic of a service data flow (SDF) to a high priority access until it is determined that the access is congested. If it is determined that the access is congested, the traffic of the SDF may be sent not only to the high priority access but also to a low priority access. If high priority access becomes unavailable, all traffic of the SDF may be sent to a low priority access.

In addition, the steering capability in the access selection descriptor in the ATSSS rule may indicate whether the UE should use a steering capability supported by the UE, or an MPTCP capability, or an ATSSS-LL capability, or an eATSSS capability, to steer traffic of the service data flow (also referred to as SDF).

In addition, the N4 rule may have a similar structure to the ATSSS rule.

Furthermore, URSP rules (UE Route Selection Policy rules) may be composed of a list of one or more URSP rules (UE Route Selection Policy Rules). Furthermore, each URSP rule may be composed of a rule precedence, and/or a traffic descriptor, and/or a list of route selection descriptors.

Here, the rule priority of a URSP rule indicates the order in which the URSP rules are enforced in the UE. When the UE receives URSP rules, i.e., when it receives one or more URSP rules, it may refer to the rule priority of each URSP rule and apply the URSP rules in order starting with the highest priority.

In addition, the traffic descriptor in the URSP rule indicates when the URSP rule is to be applied. Here, the traffic descriptor in the URSP rule may be composed of application descriptors, and/or IP descriptors, and/or domain descriptors, and/or non-IP descriptors, and/or DNN (Data Network Name), and/or connection capabilities.

Additionally, the application descriptor in the traffic descriptor in the URSP rule may include an OS ID and an OS application ID.

In addition, the IP descriptor in the traffic descriptor in the URSP rule indicates information that identifies the destination of the IP traffic and may include, for example, an IP address, an IPv6 network prefix, a port number, a protocol number, etc.

In addition, domain descriptors in traffic descriptors in URSP rules may indicate the destination FQDN (Fully Qualified Domain Name).

Additionally, a non-IP descriptor in a traffic descriptor in a URSP rule may indicate information identifying the destination of non-IP traffic (e.g., ethernet traffic or unstructured traffic).

Additionally, the DNN in the traffic descriptor in the URSP rule may be information about the DNN provided by the application.

Additionally, the connection capabilities in the traffic descriptor in the URSP rule may indicate information provided by the UE's application when the UE requests connection to the network using a certain capability.

Additionally, a route selection descriptor list in a URSP rule may consist of one or more route selection descriptors. Each route selection descriptor may consist of a rule route selection descriptor precedence and/or route selection components.

The rule selection descriptor priority indicates the order in which route selection descriptors are applied. When a UE receives a route selection descriptor list, i.e., when it receives one or more route selection descriptors, it may refer to the rule selection descriptor priority in each route selection descriptor and apply the route selection descriptors in order of highest priority.

The route selection configuration may also comprise SSC Mode Selection, and/or Network Slice Selection, and/or DNN Selection, and/or PDU Session Type Selection, and/or Non-Seamless Offload indication, and/or Access Type preference.

Here, the SSC mode selection may indicate that the application's traffic is to be routed over a PDU session of the specified SSC mode.

The network slice selection may also indicate that the application's traffic should be routed using a PDU session that supports one or more of the indicated S-NSSAIs.

The DNN selection may also indicate that the application's traffic should be routed using a PDU session that supports one or more of the indicated DNNs.

The PDU session type selection may also indicate that the application's traffic should be routed using a PDU session that supports the indicated PDU session type.

The non-seamless offload indication may also indicate that the application's traffic is to be offloaded to a non-3GPP access.

The access type preference may also indicate an access type for establishing a PDU session when the UE needs to establish a PDU session. Here, the access type may indicate 3GPP, or non-3GPP, or multi-access, or eATSSS. Here, eATSSS may be specified when establishing a PDU session using the eATSSS function, and may indicate 3GPP access or non-3GPP access corresponding to the SA PDU session to be established.

The first PCC rule may be a rule that indicates how to distribute the uplink traffic and downlink traffic in two SA PDU sessions used for communication by the eATSSS function to 3GPP access and non-3GPP access. In other words, the first PCC rule may be a rule that indicates how to distribute the uplink traffic and downlink traffic in two SA PDU sessions used for communication by the eATSSS function between the first SA PDU session via 3GPP access and the second SA PDU session via non-3GPP access. The first PCC rule may be a rule that indicates only how to distribute the uplink traffic and downlink traffic in two SA PDU sessions used for communication by the eATSSS function to the first SA PDU session via 3GPP access. The first PCC rule may be a rule that indicates only how to distribute uplink traffic and downlink traffic in two SA PDU sessions used for communication by the eATSSS function to a second SA PDU session via a non-3GPP access. This rule may be included in the first PCC rule as eATSSS policy control information.

The second PCC rule may be a rule indicating how to distribute the uplink traffic and downlink traffic in the MA PDU session used for communication by the ATSSS function to 3GPP access and non-3GPP access. In other words, the second PCC rule may be a rule indicating how to distribute the uplink traffic and downlink traffic in the MA PDU session used for communication by the ATSSS function between user plane resources via 3GPP access and user plane resources via non-3GPP access. The second PCC rule may be a rule indicating only how to distribute the uplink traffic and downlink traffic in the MA PDU session used for communication by the ATSSS function to user plane resources via 3GPP access in the MA PDU session. The second PCC rule may be a rule indicating only how to distribute the uplink traffic and downlink traffic in the MA PDU session used for communication by the ATSSS function to user plane resources via non-3GPP access in the MA PDU session. This rule may be included in the first PCC rule as ATSSS policy control information.

The first ATSSS rule may be a rule that indicates how to distribute the uplink traffic in two SA PDU sessions used for communication by the eATSSS function to 3GPP access and non-3GPP access. In other words, the first ATSSS rule may be a rule that indicates how to distribute the uplink traffic in two SA PDU sessions used for communication by the eATSSS function between a first SA PDU session via 3GPP access and a second SA PDU session via non-3GPP access. The first ATSSS rule may be a rule that indicates only how to distribute the uplink traffic in two SA PDU sessions used for communication by the eATSSS function to the first SA PDU session via 3GPP access. The first ATSSS rule may be a rule that indicates only how to distribute the uplink traffic in two SA PDU sessions used for communication by the eATSSS function to the second SA PDU session via non-3GPP access. The first ATSSS rule may include a steering capability indicating the steering capability, or the MPTCP capability, or the ATSSS-LL capability, or the eATSSS capability, supported by the UE, as described above. The first ATSSS rule is sent from the SMF to the UE and used in the UE.

The second ATSSS rule may be a rule indicating how to distribute the uplink traffic in the MA PDU session used for communication by the ATSSS function to 3GPP access and non-3GPP access. In other words, the second ATSSS rule may be a rule indicating how to distribute the uplink traffic in the MA PDU session used for communication by the ATSSS function between user plane resources via 3GPP access and user plane resources via non-3GPP access. The second ATSSS rule may be a rule indicating only how to distribute the uplink traffic in the MA PDU session used for communication by the ATSSS function to user plane resources via 3GPP access in the MA PDU session. The second ATSSS rule may be a rule indicating only how to distribute the uplink traffic in the MA PDU session used for communication by the ATSSS function to user plane resources via non-3GPP access in the MA PDU session. The second ATSSS rule may include a steering capability indicating the steering capability supported by the UE, or the MPTCP capability, or the ATSSS-LL capability, or the eATSSS capability, as described above. The second ATSSS rule is sent from the SMF to the UE and used in the UE.

The first N4 rule may be a rule that indicates how to distribute downlink traffic in two SA PDU sessions used for communication by the eATSSS function to 3GPP access and non-3GPP access. In other words, the first N4 rule may be a rule that indicates how to distribute downlink traffic in two SA PDU sessions used for communication by the eATSSS function between a first SA PDU session via 3GPP access and a second SA PDU session via non-3GPP access. The first N4 rule may be a rule that indicates only how to distribute downlink traffic in two SA PDU sessions used for communication by the eATSSS function to a first SA PDU session via 3GPP access. The first N4 rule may be a rule that indicates only how to distribute downlink traffic in two SA PDU sessions used for communication by the eATSSS function to a second SA PDU session via non-3GPP access. In addition, the first N4 rule is transmitted from the SMF to the UPF and used in the UPF.

The second N4 rule may be a rule indicating how to distribute downlink traffic in a MA PDU session used for communication by the ATSSS function to 3GPP access and non-3GPP access. In other words, the second N4 rule may be a rule indicating how to distribute downlink traffic in a MA PDU session used for communication by the ATSSS function between user plane resources via 3GPP access and user plane resources via non-3GPP access. The second N4 rule may be a rule indicating only how to distribute downlink traffic in a MA PDU session used for communication by the ATSSS function to user plane resources via 3GPP access in the MA PDU session. The second N4 rule may be a rule indicating only how to distribute downlink traffic in a MA PDU session used for communication by the ATSSS function to user plane resources via non-3GPP access in the MA PDU session. The second N4 rule is transmitted from the SMF to the UPF and used in the UPF.

[3.2. Description of Identification Information Used in Each Embodiment]
Next, the identification information used in each embodiment will be described.

First, the first identification information is a DNN. The first identification information may be information indicating a DNN requested by the UE. The first identification information may be a DNN that identifies a DN to which a PDU session to be established is to be connected.

Furthermore, the second identification information may indicate whether the UE supports the ATSSS-LL function. Furthermore, the second identification information may be information indicating a UE capability. Furthermore, the second identification information may be expressed as information indicating an ATSSS-LL capability.

Furthermore, the third identification information may indicate whether the UE supports the MPTCP function. Furthermore, the third identification information may be information indicating UE capability. Furthermore, the third identification information may be expressed as information indicating MPTCP capability. Furthermore, the second identification information and the third identification information may be expressed as information indicating ATSSS capability.

Furthermore, the fourth identification information may indicate whether the UE supports the eATSSS function. Furthermore, the fourth identification information may be information indicating UE capability. Furthermore, the fourth identification information may be expressed as information indicating eATSSS capability. Furthermore, the information indicating ATSSS capability may include the fourth identification information in addition to the second identification information and the third identification information.

The fifth identification information is a PDU session ID for identifying a PDU session. The fifth identification information may be a PDU session ID for identifying an MA PDU session when the UE requests establishment of an MA PDU session, and may be a PDU session ID for identifying an SA PDU session when the UE requests establishment of an SA PDU session. That is, the fifth identification information may be information associated with the ninth identification information.

The sixth identification information is a PDU session type. The sixth identification information may be information indicating a PDU session type requested by the UE. The sixth identification information may be a PDU session type for identifying the type of the PDU session. The sixth identification information may indicate any of IPv4, IPv6, IPv4v6, Unstructured, and Ethernet (registered trademark).

The seventh identification information may be an SSC mode requested by the UE for the PDU session. The seventh identification information may indicate any one of SSC mode 1, SSC mode 2, and SSC mode 3.

Furthermore, the eighth identification information is one or more S-NSSAIs. Furthermore, the eighth identification information may be one or more S-NSSAIs requested by the UE. Furthermore, the eighth identification information may be one or more S-NSSAIs requested by the UE for the PDU session. Furthermore, the eighth identification information may be one or more S-NSSAIs allowed by the network for at least one of the accesses (3GPP access or non-3GPP access) as an Allowed NSSAI included in a Registration Accept message in the Registration procedure.

Here, an S-NSSAI authorized for both accesses may mean an S-NSSAI that is authorized to connect to the network via 3GPP access and that is authorized to connect to the network via non-3GPP access.

The ninth identification information may be information indicating a request for establishment of an MA PDU session (for the ATSSS function) and/or information indicating a request for establishment of an SA PDU session (for the eATSSS function). The ninth identification information may be information indicating a request for communication by the ATSSS function and/or information indicating a request for communication by the eATSSS function. The ninth identification information may be information indicating a request for establishment of user plane resources via a 3GPP access constituting an MA PDU session, or information indicating a request for establishment of user plane resources via a non-3GPP access constituting an MA PDU session. The ninth identification information may be a request type. That is, the request type, which is the ninth identification information, may indicate a request for establishment of an MA PDU session (for the ATSSS function), and/or a request for establishment of an SA PDU session (for the eATSSS function), and/or a request for communication by the ATSSS function, and/or a request for communication by the eATSSS function, and/or a request for establishment of user plane resources via a 3GPP access constituting an MA PDU session, and/or a request for establishment of user plane resources via a non-3GPP access constituting an MA PDU session. For example, when requesting establishment of an MA PDU session (for the ATSSS function), and/or a request for communication by the ATSSS function, and/or a request for establishment of user plane resources via a 3GPP access constituting an MA PDU session, and/or a request for establishment of user plane resources via a non-3GPP access constituting an MA PDU session, the request type, which is the ninth identification information, may indicate MA PDU request. Also, for example, when requesting establishment of an SA PDU session (for an eATSSS function) and/or when requesting communication via an eATSSS function, the request type, which is the ninth identification information, may indicate eATSSS, or eATSSS request, or SA PDU request.

The tenth identification information is a PDU session ID for identifying an already established SA PDU session. For example, the tenth identification information may be a PDU session ID for identifying an SA PDU session via a 3GPP access when an SA PDU session via a 3GPP access has already been established. For example, the tenth identification information may be a PDU session ID for identifying an SA PDU session via a non-3GPP access when an SA PDU session via a non-3GPP access has already been established.

The 11th identification information may be information that combines one or more pieces of information indicated by the 1st to 10th identification information. For example, the 11th identification information may combine the 2nd to 4th identification information into one piece of identification information. In this way, by using the 11th identification information, it may be possible to provide information as one piece of information that combines the 2nd identification information, the 3rd identification information, and the 4th identification information.

The 21st identification information may be a DNN. The 21st identification information may be information indicating a DNN permitted by the network. The 21st identification information may be a DNN that identifies a DN to which the PDU session to be established is to be connected.

Furthermore, the 22nd identification information may indicate whether the network supports the ATSSS-LL function. Furthermore, the 22nd identification information may be information indicating a network capability. Furthermore, the 22nd identification information may be expressed as information indicating an ATSSS-LL capability.

Furthermore, the 23rd identification information may indicate whether or not the network supports the MPTCP function. Furthermore, the 23rd identification information may be information indicating network capability. Furthermore, the 23rd identification information may be expressed as information indicating MPTCP capability. Furthermore, the 22nd identification information and the 23rd identification information may be expressed as information indicating ATSSS capability.

Furthermore, the 24th identification information may indicate whether the network supports the eATSSS function. Furthermore, the 24th identification information may be information indicating network capability. Furthermore, the 24th identification information may be expressed as information indicating eATSSS capability. Furthermore, the information indicating ATSSS capability may include the 24th identification information in addition to the 22nd identification information and the 23rd identification information.

The 25th identification information is a PDU session ID for identifying the PDU session to be established. The 25th identification information may be a PDU session ID for identifying the MA PDU session when establishment of the MA PDU session is permitted, and may be a PDU session ID for identifying the SA PDU session when establishment of the SA PDU session is permitted.

The 26th identification information is a PDU session type. The 26th identification information may be information indicating a PDU session type permitted by the network. The 26th identification information may be a PDU session type for identifying the type of PDU session. The 26th identification information may indicate any of IPv4, IPv6, IPv4v6, Unstructured, and Ethernet (registered trademark).

The 27th identification information may be an SSC mode that the network has authorized for the PDU session to be established. The 27th identification information may indicate any of SSC mode 1, SSC mode 2, and SSC mode 3.

Furthermore, the 28th identification information is one or more S-NSSAIs. Furthermore, the 28th identification information may be one or more S-NSSAIs authorized by the network. Furthermore, the 28th identification information may be one or more S-NSSAIs authorized by the network for the PDU session to be established. Furthermore, the 28th identification information may be one or more S-NSSAIs selected from one or more S-NSSAIs included in the 8th identification information. Furthermore, the 28th identification information may be one or more S-NSSAIs selected from one or more S-NSSAIs not included in the 8th identification information.

The 29th identification information may be information indicating that it has been permitted by the network. For example, the 29th identification information may indicate that the establishment of a MA PDU session (for the ATSSS function) is permitted, and/or that the establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or that the establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that communication by the ATSSS function is permitted. The 29th identification information may also indicate that the establishment of a SA PDU session (for the eATSSS function) is permitted, and/or that the establishment of user plane resources via 3GPP access is permitted, and/or that the establishment of user plane resources via non-3GPP access is permitted, and/or that communication by the eATSSS function is permitted.

The 30th identification information is an ATSSS rule, or a first ATSSS rule, or a second ATSSS rule. The steering function included in the 30th identification information may indicate a steering function supported by the UE, and/or an ATSSS-LL function, and/or an MPTCP function, and/or an eATSSS function.

The 31st identification information may be information instructing to execute a registration procedure and/or a PDU session establishment procedure. The 31st identification information may be information instructing to execute a registration procedure and/or a PDU session establishment procedure in order to establish an SA PDU session that has not yet been established among two SA PDU sessions used for communication by the eATSSS function. The 31st identification information may be information instructing to execute a registration procedure and/or a PDU session establishment procedure in order to establish an SA PDU session for user plane resources via an access that has not yet been established among MA PDU sessions used for communication by the ATSSS function. The instruction to execute the registration procedure and/or the PDU session establishment procedure may be conveyed by transmitting at least a part of the 21st to 30th, and 32nd identification information.

The 32nd identification information may be information that combines one or more pieces of information indicated by the 21st to 31st identification information. For example, the 32nd identification information may combine the 22nd to 24th identification information into one piece of identification information. In this way, by using the 32nd identification information, it may be possible to provide information as a single piece of information that combines the 22nd identification information, the 23rd identification information, and the 24th identification information.

[4. First embodiment]
In this embodiment, a PDU session establishment procedure for establishing an MA PDU session for communication using the ATSSS function and/or an SA PDU session for communication using the eATSSS function when a UE is registered in the same PLMN (operator's core network) via 3GPP access and non-3GPP access is described with reference to Figures 7 and 8.

In addition, if the UE supports the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function requests communication via the ATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the eATSSS function requests communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function and the eATSSS function requests communication via the ATSSS function and/or communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a user has pre-configured a UE supporting the ATSSS function and/or the eATSSS function to communicate via the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. The UE may also initiate a PDU session establishment procedure based on information pre-stored in the UE, and/or information pre-received from the access network, and/or information pre-received from the core network (e.g., information received in a procedure such as a registration procedure, and/or URSP rules pre-received from the PCF, etc.).

[4.1. PDU Session Establishment Procedure via 3GPP Access]
Next, the PDU session establishment procedure performed via 3GPP access will be described with reference to Figure 7. First, the UE initiates the PDU session establishment procedure by sending a NAS message including an N1SM container including a PDU session establishment request message to the AMF via the access network (S700). The NAS message is, for example, a message sent via the N1 interface, and may be an uplink NAS transport (UL NAS TRANSPORT) message.

Here, the access network can be 3GPP access or non-3GPP access, but the following describes the case of 3GPP access as an example. That is, the UE transmits a NAS message to the AMF via a base station device included in the 3GPP access.

In addition, the UE can notify the network side of the UE's request by sending a PDU session establishment request message, and/or an N1 SM container, and/or a NAS message including at least one of the identification information 1 to 9 and 11.

Here, identification information 1 to 9 and 11 may be as described in Chapter 3.2.

It is preferable that the UE supports at least one of the functions indicated by the second to fourth identification information, and if the UE supports a function, it is preferable that the identification information indicates that the function is supported.

In addition, the UE may transmit the identification information 1 to 9 and 11 in a control message of a layer lower than the NAS layer (e.g., the Radio Resource Control (RRC) layer, the Medium Access Control (MAC) layer, the Radio Link Control (RLC) layer, the Packet Data Convergence Protocol (PDCP) layer, etc.) or in a control message of a layer higher than the NAS layer (e.g., the transport layer, the session layer, the presentation layer, the application layer, etc.).

Next, when the AMF receives the NAS message, it can recognize what the UE is requesting and/or the contents of the information etc. (message, container, information) contained in the NAS message.

Here, the AMF may reject the PDU session establishment request if the UE is registered via both accesses but the S-NSSAI (eighth identity) received from the UE is not authorized for both accesses. The AMF may also reject the PDU session establishment request if the network and/or core network device does not support the ATSSS function and/or the eATSSS function.

Here, the UE being registered via both accesses may mean that the UE is registered to the network via a 3GPP access and the UE is registered to the network via a non-3GPP access.

Additionally, an S-NSSAI that is not authorized for both accesses may mean an S-NSSAI that is not authorized to connect to the network via 3GPP access and is not authorized to connect to the network via non-3GPP access.

Also, when rejecting a request to establish a PDU session, each device may skip, i.e., abort, steps from S702 onwards.

Furthermore, when rejecting a PDU session establishment request, the AMF may send to the UE a NAS message including information indicating that the PDU session establishment request is rejected. At this time, the AMF does not need to send to the SMF at least a portion of the information, etc. (message, container, information) included in the NAS message received from the UE. Furthermore, by receiving this NAS message from the AMF, the UE may detect that the procedure was not completed normally or that the procedure was completed abnormally.

Furthermore, when rejecting the PDU session establishment request, the AMF may send information to the SMF indicating that the PDU session establishment request is rejected, and the SMF may send a NAS message including an N1 SM container including a PDU session establishment rejection message to the UE. At this time, the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message may include information indicating that the PDU session establishment request is rejected. Furthermore, the UE may detect that the procedure was not completed normally or that the procedure was completed abnormally by receiving the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message from the SMF.

Next, the AMF selects an SMF as a destination for transferring at least a portion of the information (message, container, information) contained in the NAS message received from the UE (S702). The AMF may select the destination SMF based on the information (message, container, information) contained in the NAS message, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the AMF, etc. The AMF may also select an SMF that supports the ATSSS function and/or the eATSSS function. Here, it is assumed that SMF_220 supporting the ATSSS function and/or the eATSSS function is selected.

Next, the AMF transmits to the selected SMF at least a portion of the information (message, container, information) contained in the NAS message received from the UE, for example via the N11 interface (S704). The AMF may also transmit to the SMF information indicating that the UE is registered for both accesses.

Next, when the SMF receives information etc. (message, container, information) sent from the AMF, it can recognize what the UE is requesting and/or the content of the information etc. (message, container, information) received from the AMF.

Here, the SMF may perform a first condition determination. The first condition determination may be for determining whether or not to accept the UE request. In the first condition determination, the SMF determines whether the first condition determination is true or false. If the SMF determines that the first condition determination is true, it may start the procedure of (A) in FIG. 7, and if the SMF determines that the first condition determination is false, it may start a procedure to reject the UE request. The procedure to reject the UE request will be described in Chapter 4.4.

Furthermore, the first condition determination may be performed based on information received from the AMF (message, container, information), and/or subscription information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc.

For example, if the network permits the UE's request, the first condition determination may be determined to be true, and if the network does not permit the UE's request, the first condition determination may be determined to be false. Also, if the network to which the UE is connected and/or a device within the network supports the function requested by the UE, the first condition determination may be determined to be true, and if the function requested by the UE is not supported, the first condition determination may be determined to be false. Also, if the transmitted and received identification information is permitted, the first condition determination may be determined to be true, and if the transmitted and received identification information is not permitted, the first condition determination may be determined to be false.

In addition, if the network allows establishment of an SA PDU session for communication using the eATSSS function, and/or allows establishment of user plane resources via 3GPP access, and/or allows communication by the eATSSS function, the first condition determination may be determined to be true. In addition, if the network does not allow establishment of an SA PDU session for communication using the eATSSS function, and/or does not allow establishment of user plane resources via 3GPP access, and/or does not allow communication by the eATSSS function, the first condition determination may be determined to be false.

Furthermore, if the network permits establishment of an MA PDU session, and/or permits establishment of user plane resources via 3GPP access in the MA PDU session, and/or permits communication via the ATSSS function, the first condition determination may be determined to be true. If the network does not permit establishment of an MA PDU session, and/or does not permit establishment of user plane resources via 3GPP access in the MA PDU session, and/or does not permit communication via the ATSSS function, the first condition determination may be determined to be false.

In addition, the conditions for determining whether the first condition judgment is true or false do not have to be limited to the conditions described above.

Next, we explain each step of the procedure in Figure 7(A).

First, the SMF may select a PCF. For example, the SMF may select an appropriate PCF based on the received identification information. For example, the SMF may select a PCF that supports ATSSS and/or eATSSS functions. Here, it is assumed that PCF_250, which supports ATSSS and/or eATSSS functions, is selected.

Next, the SMF may send at least a portion of the information etc. (message, container, information) received from the AMF to the PCF (S706).

In addition, when the SMF determines to permit the establishment of an SA PDU session for communication using the eATSSS function, and/or when the SMF determines to permit the establishment of user plane resources via 3GPP access, and/or when the SMF determines to permit communication by the eATSSS function, the SMF may further transmit additional information to the PCF. Here, the additional information may include "information indicating that the establishment of an SA PDU session for communication using the eATSSS function has been permitted", and/or "information indicating that the establishment of user plane resources via 3GPP access has been permitted", and/or "the fact that communication by the eATSSS function has been permitted", and/or "an access type corresponding to the SA PDU session and/or user plane resources to be established". Here, the access type may indicate 3GPP access.

In addition, when the SMF determines to permit the establishment of the MA PDU session, and/or when the SMF determines to permit the establishment of user plane resources via 3GPP access in the MA PDU session, and/or when the SMF determines to permit communication by the ATSSS function, the SMF may further transmit additional information to the PCF. Here, the additional information may include "information indicating that the establishment of the MA PDU session has been permitted", and/or "information indicating that the establishment of user plane resources via 3GPP access in the MA PDU session has been permitted", and/or "information indicating that communication by the eATSSS function has been permitted", and/or "access type corresponding to the user plane resources in the MA PDU session to be established". Here, the access type may indicate 3GPP access.

Note that although the above determination is described as being made by the SMF, it may also be made by the PCF. That is, the SMF and/or the PCF may make the above determination. If the SMF does not make the above determination, the SMF does not need to send the above additional information to the PCF.

Next, when the PCF receives information (messages, containers, information) sent from the SMF, it can recognize their contents.

In addition, the PCF may make a decision similar to the above decision in the SMF based on information received from the SMF (messages, containers, information), and/or UE policies, and/or operator policies, and/or subscription information, etc.

If the PCF makes the above determination, the PCF may send to the SMF the additional information described above as being sent from the SMF to the PCF.

In addition, when the PCF detects that the above judgment is being made in the SMF, it is not necessary to make this judgment (it may be skipped).

Furthermore, if the SMF and/or PCF allow establishment of an SA PDU session for communication using the eATSSS function, and/or allow establishment of user plane resources via a 3GPP access, and/or allow communication via the eATSSS function, the PCF may generate a first PCC rule.

In addition, if the SMF and/or PCF allows establishment of an MA PDU session, and/or allows establishment of user plane resources via 3GPP access in the MA PDU session, and/or allows communication via the ATSSS function, the PCF may generate a second PCC rule.

Then, if the PCF generates the first PCC rule or the second PCC rule, it may send the generated PCC rule to the SMF.

The PCF may generate the first PCC rule and the second PCC rule as one common PCC rule. That is, the PCC rule may include the first PCC rule and/or the second PCC rule. Then, the PCF may send the generated PCC rule to the SMF.

Next, when the SMF receives the information sent from the PCF, it can recognize the contents of that information.

Then, when the SMF receives the first PCC rule from the PCF, it may generate a first ATSSS rule (the 30th identification information) and a first N4 rule from the first PCC rule. The SMF may also manage (i.e., map) the first PCC rule, the first ATSSS rule, and the first N4 rule in association with each other.

Furthermore, when the SMF receives a second PCC rule from the PCF, it may generate a second ATSSS rule (the 30th identification information) and a second N4 rule from the second PCC rule. Furthermore, the SMF may manage (i.e., map) the second PCC rule, the second ATSSS rule, and the second N4 rule in association with each other.

When the SMF receives a PCC rule from the PCF, rather than the first or second PCC rule, it may generate an ATSSS rule (30th identification information) and an N4 rule from the PCC rule. In this case, the ATSSS rule may include the first ATSSS rule and/or the second ATSSS rule, and the N4 rule may include the first N4 rule and/or the second N4 rule. The SMF may also manage (i.e., map) the PCC rule, the ATSSS rule, and the N4 rule in association with each other.

Next, the SMF selects a UPF for the PDU session to be established and sends an N4 session establishment request message to the selected UPF, for example via the N4 interface (S708).

In addition, when the SMF receives a first PCC rule from the PCF, it may include the first N4 rule in the N4 session establishment request message. In addition, when the SMF receives a second PCC rule from the PCF, it may include the second N4 rule in the N4 session establishment request message. In addition, when the SMF receives a PCC rule from the PCF, it may include the N4 rule in the N4 session establishment request message.

Here, the SMF may select one or more UPFs based on information received from the AMF (message, container, information), and/or information received from the PCF, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc. Furthermore, if multiple UPFs are selected, the SMF may send an N4 session establishment request message to each UPF.

Furthermore, if the SMF and/or PCF allow establishment of an SA PDU session for communication using the eATSSS function, and/or allow establishment of user plane resources via 3GPP access, and/or allow communication using the eATSSS function, the SMF may select a UPF that supports the eATSSS function.

Furthermore, if the SMF and/or PCF allows establishment of an MA PDU session, and/or allows establishment of user plane resources via 3GPP access in the MA PDU session, and/or allows communication via ATSSS functionality, the SMF may select a UPF that supports the ATSSS functionality.

Here, it is assumed that UPF_230, which supports ATSSS and/or eATSSS functions, is selected.

Next, when the UPF receives an N4 session establishment request message (S708), it can recognize the contents of the information received from the SMF.

In addition, the UPF may be configured to operate in accordance with the received N4 rule when it receives the first N4 rule, the second N4 rule, or the N4 rule from the SMF.

That is, when the UPF receives the first N4 rule, it may configure the first SA PDU session via 3GPP access that is to be established in this procedure (PDU session establishment procedure) to operate in accordance with the first N4 rule for downlink traffic in the two SA PDU sessions used for communication by the eATSSS function. Note that the UPF may, although it is preferable not to configure the second SA PDU session via non-3GPP access that is to be established in the second PDU session establishment procedure executed after this procedure to operate in accordance with the first N4 rule at this timing.

In addition, even if the UPF receives the first N4 rule in this procedure (PDU session establishment procedure), the UPF may not configure the first SA PDU session via 3GPP access to operate according to the first N4 rule. In this case, the UPF may configure the first SA PDU session via 3GPP access and the second SA PDU session via non-3GPP access to operate according to the first N4 rule based on the reception of an N4 session establishment request message sent after the establishment of the second SA PDU session via non-3GPP access is permitted in the second PDU session establishment procedure executed after this procedure.

The UPF may also perform similar configuration when it receives an N4 rule that includes the first N4 rule.

In addition, when the UPF receives the second N4 rule, it may configure downlink traffic in the MA PDU session used for communication via the ATSSS function to operate in accordance with the second N4 rule for user plane resources via 3GPP access and user plane resources via non-3GPP access.

The UPF may also perform similar configuration when it receives an N4 rule that includes a second N4 rule.

Furthermore, the UPF may transmit an N4 session establishment response message to the SMF, for example, via the N4 interface, based on receipt of the N4 session establishment request message and/or completion of the above-mentioned configuration (S710). This N4 session establishment response message may include information indicating that the above-mentioned configuration has been completed. Furthermore, if the UPF has not applied the first N4 rule to the SA PDU session via the 3GPP access, the UPF may transmit the N4 session establishment response message including information indicating that the first N4 rule has not been applied to the SA PDU session via the 3GPP access.

Next, when the SMF receives an N4 session establishment response message as a response message to the N4 session establishment request message, it can recognize the contents of the information received from the UPF.

Next, the SMF transmits the N1 SM container and/or the N2 SM information and/or the PDU session ID (25th identification information) to the AMF, for example via the N11 interface, based on the reception of the PDU session establishment request message and/or the selection of the UPF and/or the reception of the N4 session establishment response message (S712). Here, the N1 SM container may include a PDU session establishment acceptance message, and further, the PDU session establishment acceptance message may include an ATSSS container IE (Information Element) and/or a new ATSSS container IE.

Next, the AMF that receives the N1 SM container, and/or the N2 SM information, and/or the PDU session ID (25th identification information) transmits a NAS message to the UE via the access network (S714) (S716). Here, the NAS message is transmitted, for example, via the N1 interface. The NAS message may also be a downlink NAS transport (DL NAS TRANSPORT) message.

Specifically, when the AMF transmits an N2 PDU session request message to the access network (S714), the access network that receives the N2 PDU session request message transmits a NAS message to the UE (S716). Here, the N2 PDU session request message may include a NAS message and/or N2 SM information. In addition, the NAS message may include a PDU session ID (25th identification information) and/or an N1 SM container.

Here, the access network is a 3GPP access. That is, the AMF transmits a NAS message to the UE via a base station device_110 included in the 3GPP access.

The PDU session establishment acceptance message may also be a response message to a PDU session establishment request. The PDU session establishment acceptance message may also indicate that the establishment of the PDU session has been accepted.

Here, the SMF and/or AMF may indicate that at least part of the UE's request in the PDU session establishment request message has been accepted by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a PDU session ID (25th identification information), and/or a NAS message, and/or N2 SM information, and/or an N2 PDU session request message.

Here, when the SMF and/or PCF allows establishment of an SA PDU session for communication using the eATSSS function, and/or when establishment of user plane resources via 3GPP access is allowed, and/or when communication via the eATSSS function is allowed, the SMF and/or AMF may send an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or an NAS message, and/or an N2 SM information, and/or an N2 PDU session request message, including at least one of the identification information items 21 to 32.

Here, the identification information 21 to 32 may be as described in Chapter 3.2.

The 21st identification information is a DNN that identifies the DN to which the SA PDU session is connected for communication using the eATSSS function. The 21st identification information may be the same as the first identification information.

It is also preferable that the network supports at least one of the functions indicated by the identification information 22 to 24, and if the function is supported, it is preferable that the identification information indicates that the function is supported.

Furthermore, the 25th identification information is a PDU session ID for identifying an SA PDU session via 3GPP access, and may be identical to the fifth identification information.

The 29th identification information may also indicate that establishment of an SA PDU session (for the eATSSS function) is permitted, and/or that establishment of user plane resources via 3GPP access is permitted, and/or that communication via the eATSSS function is permitted.

Furthermore, the 30th identification information may be an ATSSS rule or a first ATSSS rule. It is preferable that the steering function included in the 30th identification information indicates a steering function supported by the UE or an eATSSS function.

In addition, the 31st identification information may be information instructing the execution of a PDU session establishment procedure to establish an SA PDU session that has not yet been established out of two SA PDU sessions used for communication via the eATSSS function.

The SMF and/or AMF may also notify the UE that establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that establishment of user plane resources via 3GPP access is permitted, and/or that communication via the eATSSS function is permitted, and/or instruct the UE to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established, of the two SA PDU sessions used for communication via the eATSSS function, by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a NAS message, and/or an N2 SM information, and/or an N2 PDU session request message including at least one of the identification information 21 to 32.

Furthermore, when the SMF and/or PCF permits establishment of an MA PDU session, and/or permits establishment of user plane resources via 3GPP access in the MA PDU session, and/or permits communication via the ATSSS function, the SMF and/or AMF may send an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or an NAS message, and/or an N2 SM information, and/or an N2 PDU session request message, including at least one of the identification information nos. 21 to 30 and 32.

Here, the identification information 21 to 30 and 32 may be as described in Chapter 3.2.

Here, the 21st identification information is a DNN that identifies the DN to which the MA PDU session is connected. The 21st identification information may be the same as the first identification information.

It is also preferable that the network supports at least one of the functions indicated by the identification information from No. 22 to No. 23, and if the function is supported, it is preferable that the identification information indicates that the function is supported.

Furthermore, the 25th identification information is a PDU session ID for identifying the MA PDU session and may be identical to the fifth identification information.

The 29th identification information may also indicate that establishment of an MA PDU session (for the ATSSS function) is permitted, and/or that establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or that communication by the ATSSS function is permitted.

Furthermore, the 30th identification information may be an ATSSS rule or a second ATSSS rule. It is preferable that the steering function included in the 30th identification information indicates a steering function supported by the UE, an ATSSS-LL function, or an MPTCP function.

In addition, the SMF and/or AMF may transmit the identification information 21 to 30, and 32 in a control message of a layer lower than the NAS layer (e.g., RRC layer, MAC layer, RLC layer, PDCP layer, etc.) or in a control message of a layer higher than the NAS layer (e.g., transport layer, session layer, presentation layer, application layer, etc.).

In addition, the SMF and/or AMF may notify the UE that establishment of an MA PDU session is permitted, and/or that establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or that communication via the ATSSS function is permitted, by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a NAS message, and/or an N2 SM information, and/or an N2 PDU session request message including at least one of the identification information 21 to 30 and 32.

The SMF and/or AMF may notify the UE of the contents of these identification information by transmitting at least one of these identification information.

Furthermore, the SMF and/or AMF may select or decide which identification information to include in the ATSSS container IE, and/or the new ATSSS container IE, and/or the PDU session establishment acceptance message, and/or the N1 SM container, and/or the NAS message, and/or the N2 SM information, and/or the N2 PDU session request message based on each received identification information, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF and/or AMF, etc.

Next, when the UE receives the NAS message, for example via the N1 interface (S716), it can recognize that the UE's request in the PDU session establishment request message has been accepted and/or the contents of the information, etc. (message, container, information) contained in the NAS message.

For example, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE and/or a new ATSSS container IE including a 30th identification information including a steering function indicating the eATSSS function, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function is authorized, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via 3GPP access is authorized, and/or that user plane resources via 3GPP access have been established, and/or that communication via the eATSSS function is authorized, and/or that it has been instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established of the two SA PDU sessions used for communication via the eATSSS function.

Also, for example, if the UE transmits a ninth identification indicating that it is requesting establishment of an SA PDU session (for the eATSSS function) or that it is requesting communication via the eATSSS function, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE and/or a new ATSSS container IE including a 30th identification including a steering function indicating a steering function supported by the UE, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function has been authorized, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via 3GPP access has been authorized, and/or that user plane resources via 3GPP access have been established, and/or that communication via the eATSSS function has been authorized, and/or that it has been instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established of the two SA PDU sessions used for communication via the eATSSS function.

Furthermore, for example, when the UE receives identification information No. 24 indicating that the network supports the eATSSS function, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via 3GPP access is permitted, and/or that user plane resources via 3GPP access have been established, and/or that communication via the eATSSS function is permitted, and/or that it has been instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established of the two SA PDU sessions used for communication via the eATSSS function.

Furthermore, for example, when the UE receives identification information No. 29 and/or identification information No. 31, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via 3GPP access is permitted, and/or that user plane resources via 3GPP access have been established, and/or that communication via the eATSSS function is permitted, and/or that the UE has been instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established of the two SA PDU sessions used for communication via the eATSSS function.

In addition, after the UE recognizes that the establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that the establishment of user plane resources via 3GPP access is permitted, and/or that user plane resources via 3GPP access have been established, and/or that communication by the eATSSS function is permitted, and/or that it is instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established among two SA PDU sessions used for communication by the eATSSS function, the SA PDU session via 3GPP access may be in a state in which it is established. In other words, each device including the UE may be in a state in which it can communicate with the DN using an SA PDU session via 3GPP access.

Also, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE and/or a new ATSSS container IE, including a 30th identification information including a steering capability supported by the UE, or an ATSSS-LL capability, or a steering capability indicating MPTCP capability, the UE may recognize that an MA PDU session has been established via 3GPP access and non-3GPP access, and/or user plane resources have been established via 3GPP access in the MA PDU session.

After the UE recognizes that the MA PDU session via 3GPP access and non-3GPP access has been established, and/or that user plane resources via 3GPP access in the MA PDU session have been established, the MA PDU session may be in a state in which the MA PDU session is established using user plane resources via 3GPP access and non-3GPP access. In other words, each device including the UE may be in a state in which it can communicate with the DN using the MA PDU session consisting of user plane resources via 3GPP access. Furthermore, the UE may be able to identify whether the received 25th identification information (PDU session ID) is for identifying the MA PDU session or for identifying the SA PDU session via 3GPP access, based on the contents of the information (message, container, information) included in the NAS message.

The procedure in (A) of Figure 7 can now be completed successfully.

Regarding the subsequent behavior of each device, "when establishment of an MA PDU session is permitted, and/or when establishment of user plane resources via 3GPP access in an MA PDU session is permitted, and/or when communication via ATSSS function is permitted" is explained in Chapter 4.2, and "when establishment of an SA PDU session for communication using eATSSS function is permitted, and/or when establishment of user plane resources via 3GPP access is permitted, and/or when communication via eATSSS function is permitted" is explained in Chapter 4.3.

[4.2. When establishment of MA PDU session for communication via ATSSS function is permitted]
Next, in Chapter 4.1, when the establishment of the MA PDU session is permitted by the SMF and/or the PCF, and/or when the establishment of user plane resources via the 3GPP access in the MA PDU session is permitted, and/or when communication by the ATSSS function is permitted, each device including the UE may execute the procedure of (B) in Fig. 7. The procedure of (B) in Fig. 7 will be described below.

First, the UE that received the NAS message in S716 may be in a state in which it recognizes that an MA PDU session via 3GPP access and non-3GPP access has been established, and/or that user plane resources via 3GPP access in the MA PDU session have been established, as described above. That is, each device including the UE may be in a state in which an MA PDU session using user plane resources via 3GPP access and non-3GPP access has been established. In other words, each device including the UE may be in a state in which it can communicate with the DN using an MA PDU session consisting of user plane resources via 3GPP access.

Next, the SMF may send an N4 session modification request message to the already selected UPF_230 via the N4 interface (S718). Here, the N4 session modification request message does not have to include the N4 rule or the second N4 rule, but may include them.

Next, when UPF_230 receives an N4 session modification request message, it can recognize the contents of the information received from the SMF. In addition, when the UPF receives a second N4 rule, the UPF may configure the downlink traffic in the MA PDU session used for communication by the ATSSS function to operate according to the second N4 rule for user plane resources via 3GPP access and user plane resources via non-3GPP access. In addition, the UPF may perform similar configuration when it receives an N4 rule including the second N4 rule.

UPF_230 may also send an N4 session modification response message to the SMF via the N4 interface (S720). If the above settings have been made, the N4 session modification response message may include information indicating that the settings have been completed.

Next, when the SMF receives the N4 session modification response message, it can recognize the contents of the information received from the UPF. Note that S718 and S720 may be omitted.

Next, the SMF transmits the N2 SM information and/or the PDU session ID and/or the access type to the AMF, for example via the N11 interface (S722). Here, the PDU session ID may be the same as the PDU session ID transmitted in S712, and the access type may indicate non-3GPP access. The SMF does not need to transmit the N1 SM container to the AMF, but may transmit it. In addition, the SMF may indicate that the N2 SM information should be transmitted via non-3GPP access by transmitting the PDU session ID and/or the access type to the AMF.

Then, upon receiving the N2 SM information and/or the PDU session ID and/or the access type, the AMF may recognize that the N2 SM information should be sent via the non-3GPP access specified by the access type.

Next, if the MA PDU session uses untrusted non-3GPP access, the AMF may send an N2 PDU session request message to the N3IWF. Also, if the MA PDU session uses trusted non-3GPP access, the AMF may send an N2 PDU session request message to the TNGF and/or TNAP. Here, it is assumed that the N2 PDU session request message is sent to the N3IWF (S724). Also, the N2 PDU session request message may include N2 SM information. Also, the N2 PDU session request message does not need to include a NAS message, but may include one.

Next, the N3IWF performs a procedure to establish an IPsec child SA (security association) with the UE via the access network (S726).

Specifically, the N3IWF sends an IKE Create_Child_SA request message to the UE according to the IKEv2 standard described in RFC 7296 to establish an IPsec Child SA for the MA PDU session (user plane resources via non-3GPP access in the MA PDU session). Here, the IKE Create_Child_SA request message may indicate that the requested IPsec Child SA operates in tunnel mode. The IKE Create_Child_SA request message may also include a PDU Session ID associated with this Child SA. In other words, the IPsec Child SA may be associated with the PDU Session ID of the MA PDU session.

Next, if the UE accepts the IPsec Child SA, it sends an IKE Create_Child_SA response message to the N3IWF.

As a result, an IPsec Child SA is established between the UE and N3IWF.

After the IPsec Child SA is established, the N3IWF can send a NAS message including a PDU session establishment acceptance message to the UE via the base station device_120. The NAS message may also be a downlink NAS transport (DL NAS TRANSPORT) message.

The SMF and/or AMF may also include at least one of the identification information items 21 to 30 and 32 in the N2 SM information and/or N2 PDU session request message and transmit it. By transmitting at least one of these identification information items, the SMF and/or AMF can notify the UE and/or N3IWF and/or access network of the contents of these identification information items.

The contents of the identification information items 21 to 30 and 32 may be the same as those in the procedure of (A) of Figure 7.

Furthermore, based on receiving an IKE Create_Child_SA request message and/or sending an IKE Create_Child_SA response message, the UE may recognize that establishment of an MA PDU session for communication using the ATSSS function is permitted, and/or that an MA PDU session for communication using the ATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that user plane resources via non-3GPP access in the MA PDU session have been established, and/or that communication via the ATSSS function is permitted.

In addition, application of the N4 rule or the second N4 rule in the UPF may be performed after receiving an N4 session establishment request message of S708, or after receiving an N4 session modification request message of S718.

In addition, application of the ATSSS rule or the second ATSSS rule in the UE may be performed after receiving the NAS message of S716, or after establishing the IPsec Child SA of S726.

With this, the procedure in Figure 7 (B) is completed successfully.

At this stage, each device including the UE can establish an MA PDU session using user plane resources via non-3GPP access in addition to the user plane resources via 3GPP access already established. In other words, each device including the UE may be able to communicate with the DN using an MA PDU session using user plane resources via 3GPP access and user plane resources via non-3GPP access.

[4.3. When establishment of an SA PDU session for communication via the eATSSS function is permitted]
Next, in Chapter 4.1, when the SMF and/or PCF permits the establishment of an SA PDU session for communication using the eATSSS function, and/or permits the establishment of user plane resources via 3GPP access, and/or permits communication by the eATSSS function, and/or instructs the execution of a PDU session establishment procedure to establish an SA PDU session that has not yet been established among two SA PDU sessions used for communication by the eATSSS function, each device including the UE may start the procedure of FIG. 8 (PDU session establishment procedure via non-3GPP access) to establish an SA PDU session (second SA PDU session) via non-3GPP access. In this case, (B) of FIG. 7 does not need to be executed. The procedure of FIG. 8 will be described below.

First, the UE that received the NAS message in S716 may be in a state in which, as described above, the UE recognizes that the establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that the establishment of user plane resources via 3GPP access is permitted, and/or that user plane resources via 3GPP access have been established, and/or that communication by the eATSSS function is permitted, and/or that it is instructed to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established among the two SA PDU sessions used for communication by the eATSSS function. That is, each device including the UE may be in a state in which an SA PDU session (first SA PDU session) via 3GPP access is established. Also, each device including the UE may be in a state in which it can communicate with the DN using the first SA PDU session via 3GPP access.

First, the UE initiates the PDU session establishment procedure by sending a NAS message including an N1SM container including a PDU session establishment request message to the AMF via the access network (S800). The NAS message is, for example, a message sent via the N1 interface, and may be an uplink NAS transport (UL NAS TRANSPORT) message. The PDU session establishment request message may be sent to the AMF using an IPsec SA established for sending and receiving NAS messages between the UE and the AMF prior to this procedure, for example, by performing a registration procedure via non-3GPP access.

Here, the access network is a non-3GPP access. As described above, there are two types of non-3GPP access: untrusted non-3GPP access and trusted non-3GPP access. Here, the case of untrusted non-3GPP access will be described as an example. That is, the UE transmits a NAS message to the AMF via the base station device_120 included in the non-3GPP access.

In addition, the UE can notify the network side of the UE's request by sending a PDU session establishment request message, and/or an N1 SM container, and/or a NAS message including at least one of the identification information 1 to 11.

Here, identification information 1 to 11 may be as described in Chapter 3.2.

Here, the first identification information is a DNN that identifies the DN to which the second SA PDU session is connected. This first identification information is preferably the same as the first identification information and/or the 21st identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access.

It is also preferable that this second identification information is identical to the second identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this third identification information is identical to the third identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this fourth identification information is identical to the fourth identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is preferable that the UE supports at least one of the functions indicated by the second to fourth identification information, and if the UE supports a function, it is preferable that the identification information indicates that the function is supported.

The fifth identification information is a PDU session ID for identifying the second SA PDU session. This fifth identification information is preferably different from the fifth identification information and/or the 25th identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access. This may be because the SA PDU session established in the PDU session establishment procedure performed via the 3GPP access (first SA PDU session) and the SA PDU session established in the PDU session establishment procedure performed via the non-3GPP access (second SA PDU session) are different SA PDU sessions.

It is also preferable that this sixth identification information is identical to the sixth identification information and/or the 26th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

Furthermore, this seventh identification information may be identical to or different from the seventh identification information and/or the 27th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

Furthermore, this eighth identification information may be identical to or different from the eighth identification information and/or the 28th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

Furthermore, the ninth identification information may be information indicating a request for establishment of an SA PDU session (for the eATSSS function) and/or information indicating a request for communication by the eATSSS function. This ninth identification information may be a request type. That is, the request type, which is the ninth identification information, may indicate a request for establishment of an SA PDU session (for the eATSSS function) and/or a request for communication by the eATSSS function. For example, when requesting establishment of an SA PDU session (for the eATSSS function) and/or when requesting communication by the eATSSS function, the request type, which is the ninth identification information, may indicate eATSSS, or eATSSS request, or SA PDU request.

Furthermore, it is preferable that this tenth identification information is identical to the fifth identification information and/or the twenty-fifth identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access, and it is preferable that this tenth identification information is different from the fifth identification information transmitted in this procedure.

In addition, the UE may transmit the identification information 1 to 11 in a control message of a layer lower than the NAS layer (e.g., the RRC layer, the MAC layer, the RLC layer, the PDCP layer) or in a control message of a layer higher than the NAS layer (the transport layer, the session layer, the presentation layer, the application layer).

In addition, if the identification information 1 to 9 and 11 transmitted in this procedure are identical to the identification information 1 to 9 and 11 transmitted in (the PDU session establishment procedure performed via 3GPP access), the UE does not need to transmit at least some of the identification information 1 to 9 and 11 in this PDU session establishment procedure.

Next, when the AMF receives the NAS message, it can recognize what the UE is requesting and/or the contents of the information etc. (message, container, information) contained in the NAS message.

Here, the AMF may reject the request to establish the second SA PDU session if the UE is registered via both accesses but the S-NSSAI (eighth identity) received from the UE is not authorized for both accesses. The AMF may also reject the request to establish the second SA PDU session if the network and/or core network device does not support the eATSSS function.

Here, the UE being registered via both accesses may mean that the UE is registered to the network via a 3GPP access and the UE is registered to the network via a non-3GPP access.

Additionally, an S-NSSAI that is not authorized for both accesses may mean an S-NSSAI that is not authorized to connect to the network via 3GPP access and is not authorized to connect to the network via non-3GPP access.

Also, when rejecting a request to establish a second SA PDU session, each device may skip, i.e., abort, steps S802 and beyond.

Furthermore, when rejecting the establishment request for the second SA PDU session, the AMF may send to the UE a NAS message including information indicating that the establishment request for the second SA PDU session is rejected. At this time, the AMF does not need to send to the SMF at least a portion of the information, etc. (message, container, information) included in the NAS message received from the UE. Furthermore, by receiving this NAS message from the AMF, the UE may detect that the procedure was not completed normally or that the procedure was completed abnormally.

When rejecting the second SA PDU session establishment request, the AMF may send information to the SMF indicating that the PDU session establishment request is rejected, and the SMF may send a NAS message including an N1 SM container including a PDU session establishment rejection message to the UE. At this time, the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message may include information indicating that the second SA PDU session establishment request is rejected. Furthermore, the UE may detect that the procedure has not been completed successfully or that the procedure has been completed abnormally by receiving the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message from the SMF.

Next, the AMF selects an SMF as a destination for transferring at least a portion of the information (message, container, information) contained in the NAS message received from the UE (S802). The AMF may select the destination SMF based on the information (message, container, information) contained in the NAS message, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the AMF, etc. The AMF may also select an SMF that supports the ATSSS function and/or the eATSSS function. Here, it is assumed that SMF_220 supporting the ATSSS function and/or the eATSSS function is selected.

Next, the AMF transmits to the selected SMF at least a portion of the information (message, container, information) contained in the NAS message received from the UE, for example via the N11 interface (S804). The AMF may also transmit to the SMF information indicating that the UE is registered for both accesses.

Next, when the SMF receives information etc. (message, container, information) sent from the AMF, it can recognize what the UE is requesting and/or the content of the information etc. (message, container, information) received from the AMF.

Here, the SMF may perform a first condition determination. The first condition determination may be for determining whether or not to accept the UE request. In the first condition determination, the SMF determines whether the first condition determination is true or false. If the SMF determines that the first condition determination is true, it may start the procedure of (A) in FIG. 8, and if the SMF determines that the first condition determination is false, it may start a procedure to reject the UE request. The procedure to reject the UE request will be described in Chapter 4.4.

Furthermore, the first condition determination may be performed based on information received from the AMF (message, container, information), and/or subscription information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc.

For example, if the network permits the UE's request, the first condition determination may be determined to be true, and if the network does not permit the UE's request, the first condition determination may be determined to be false. Also, if the network to which the UE is connected and/or a device within the network supports the function requested by the UE, the first condition determination may be determined to be true, and if the function requested by the UE is not supported, the first condition determination may be determined to be false. Also, if the transmitted and received identification information is permitted, the first condition determination may be determined to be true, and if the transmitted and received identification information is not permitted, the first condition determination may be determined to be false.

In addition, if the network allows establishment of an SA PDU session for communication using the eATSSS function, and/or allows establishment of user plane resources via non-3GPP access, and/or allows communication by the eATSSS function, the first condition determination may be determined to be true. In addition, if the network does not allow establishment of an SA PDU session for communication using the eATSSS function, and/or does not allow establishment of user plane resources via non-3GPP access, and/or does not allow communication by the eATSSS function, the first condition determination may be determined to be false.

In addition, the conditions for determining whether the first condition judgment is true or false do not have to be limited to the conditions described above.

Next, we explain each step of the procedure in Figure 8(A).

First, the SMF may select a PCF. For example, the SMF may select an appropriate PCF based on the received identification information. For example, the SMF may select a PCF that supports ATSSS and/or eATSSS functions. Also, for example, the SMF may select an already selected PCF if it detects that this procedure has been performed to establish an SA PDU session to be used for communication by the eATSSS function. Here, it is assumed that PCF_250 that supports ATSSS and/or eATSSS functions is selected.

Next, the SMF may send at least a portion of the information etc. (message, container, information) received from the AMF to the PCF (S806).

In addition, when the SMF determines to permit the establishment of an SA PDU session for communication using the eATSSS function, and/or when the SMF determines to permit the establishment of user plane resources via non-3GPP access, and/or when the SMF determines to permit communication by the eATSSS function, the SMF may further transmit additional information to the PCF. Here, the additional information may include "information indicating that the establishment of an SA PDU session for communication using the eATSSS function has been permitted", and/or "information indicating that the establishment of user plane resources via non-3GPP access has been permitted", and/or "the fact that communication by the eATSSS function has been permitted", and/or "the access type corresponding to the SA PDU session and/or user plane resources to be established". Here, the access type may indicate non-3GPP access.

Note that although the above determination is described as being made by the SMF, it may also be made by the PCF. That is, the SMF and/or the PCF may make the above determination. If the SMF does not make the above determination, the SMF does not need to send the above additional information to the PCF.

Next, when the PCF receives information (messages, containers, information) sent from the SMF, it can recognize their contents.

In addition, the PCF may make a decision similar to the above decision in the SMF based on information received from the SMF (messages, containers, information), and/or UE policies, and/or operator policies, and/or subscription information, etc.

If the PCF makes the above determination, the PCF may send to the SMF the additional information described above as being sent from the SMF to the PCF.

In addition, when the PCF detects that the above judgment is being made in the SMF, it is not necessary to make this judgment (it may be skipped).

Furthermore, if the SMF and/or PCF allow establishment of an SA PDU session for communication using the eATSSS function, and/or allow establishment of user plane resources via non-3GPP access, and/or allow communication via the eATSSS function, the PCF may generate a first PCC rule or a PCC rule.

If the first PCC rule or PCC rule generated in the PDU session establishment procedure via 3GPP access includes a distribution rule for a second SA PDU session via non-3GPP access, the PCF does not need to generate this first PCC rule or PCC rule. In this case, there is no need to send the first PCC rule or PCC rule to the SMF.

In addition, if the first PCC rule or PCC rule generated in the PDU session establishment procedure via 3GPP access does not include a distribution rule for the second SA PDU session via non-3GPP access, a first PCC rule or PCC rule including a distribution rule for the second SA PDU session via non-3GPP access may be generated.

In addition, if the PCF does not generate a first PCC rule or a PCC rule in the PDU session establishment procedure via 3GPP access, it may generate a first PCC rule or a PCC rule in this procedure that includes a distribution rule for a second SA PDU session via 3GPP access and a distribution rule for a second SA PDU session via non-3GPP access.

Then, if the PCF generates a first PCC rule, it may send the generated PCC rule to the SMF.

The PCF may generate the first PCC rule as the aforementioned PCC rule. That is, the PCC rule may include the first PCC rule. Then, the PCF may transmit the generated PCC rule to the SMF.

Next, when the SMF receives the information sent from the PCF, it can recognize the contents of that information.

Then, when the SMF receives the first PCC rule from the PCF, it may generate a first ATSSS rule (the 30th identification information) and a first N4 rule from the first PCC rule. The SMF may also manage (i.e., map) the first PCC rule, the first ATSSS rule, and the first N4 rule in association with each other.

When the SMF receives a PCC rule from the PCF instead of the first PCC rule, the SMF may generate an ATSSS rule (the 30th identification information) and an N4 rule from the PCC rule. In this case, the ATSSS rule may be the same as the first ATSSS rule, and the N4 rule may be the same as the first N4 rule. The SMF may also manage (i.e., map) the PCC rule, the ATSSS rule, and the N4 rule in association with each other.

Next, the SMF selects a UPF for the first SA PDU session and sends an N4 session establishment request message to the selected UPF, for example via the N4 interface (S808).

In addition, when the SMF receives a first PCC rule from the PCF, it may include the first N4 rule in the N4 session establishment request message. In addition, when the SMF receives a PCC rule from the PCF, it may include the N4 rule in the N4 session establishment request message.

Here, the SMF may select one or more UPFs based on information received from the AMF (message, container, information), and/or information received from the PCF, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc. Furthermore, if multiple UPFs are selected, the SMF may send an N4 session establishment request message to each UPF.

Furthermore, if the SMF and/or PCF allow establishment of an SA PDU session for communication using the eATSSS function, and/or allow establishment of user plane resources via non-3GPP access, and/or allow communication using the eATSSS function, the SMF may select a UPF that supports the eATSSS function.

The SMF may also select a UPF if one has already been selected in the PDU session establishment procedure performed via 3GPP access.

Here, it is assumed that UPF_230, which supports ATSSS and/or eATSSS functions, is selected.

Next, when the UPF receives an N4 session establishment request message (S808), it can recognize the contents of the information received from the SMF.

In addition, when the UPF receives the first N4 rule or an N4 rule from the SMF, it may be configured to operate in accordance with the received N4 rule.

That is, when the UPF receives the first N4 rule, it may configure the downlink traffic in the two SA PDU sessions used for communication by the eATSSS function to operate according to the first N4 rule for the second SA PDU session via non-3GPP access that is to be established in this procedure (PDU session establishment procedure). Also, when the UPF receives the first N4 rule, it may configure the downlink traffic in the two SA PDU sessions used for communication by the eATSSS function to operate according to the first N4 rule for the first SA PDU session via 3GPP access and the second SA PDU session via non-3GPP access. Also, when the UPF receives an N4 rule with the same content as the first N4 rule, it may configure the same as the above.

In addition, the UPF may transmit an N4 session establishment response message to the SMF, for example via the N4 interface, based on receipt of the N4 session establishment request message and/or completion of the above-mentioned settings (S810). This N4 session establishment response message may include information indicating that the above-mentioned settings have been completed.

Next, when the SMF receives an N4 session establishment response message as a response message to the N4 session establishment request message, it can recognize the contents of the information received from the UPF.

Next, the SMF transmits the N1 SM container and/or the N2 SM information and/or the PDU session ID (25th identification information) to the AMF, for example via the N11 interface, based on the reception of the PDU session establishment request message and/or the selection of the UPF and/or the reception of the N4 session establishment response message (S812). Here, the N1 SM container may include a PDU session establishment acceptance message, and further, the PDU session establishment acceptance message may include an ATSSS container IE (Information Element) and/or a new ATSSS container IE.

The AMF then receives the N1 SM container, and/or N2 SM information, and/or the PDU session ID (25th identification information).

Then, when an SA PDU session is established via a non-3GPP access (untrusted non-3GPP access), the AMF may send an N2 PDU session request message to the N3IWF (S814). Here, the N2 PDU session request message may include a NAS message and/or N2 SM information. The NAS message may also include a PDU session ID (25th identification information) and/or an N1 SM container. Furthermore, when an SA PDU session is established via a trusted non-3GPP access, the AMF may send an N2 PDU session request message to the TNGF and/or TNAP.

Next, the N3IWF performs a procedure to establish an IPsec child SA (security association) with the UE via the access network (S816).

Specifically, the N3IWF sends an IKE Create_Child_SA request message to the UE according to the IKEv2 standard described in RFC 7296 to establish an IPsec Child SA for the SA PDU session over the non-3GPP access. Here, the IKE Create_Child_SA request message may indicate that the requested IPsec Child SA operates in tunnel mode. The IKE Create_Child_SA request message may also include a PDU Session ID associated with this Child SA. In other words, the IPsec Child SA may be associated with the PDU Session ID of the SA PDU session over the non-3GPP access.

Next, if the UE accepts the IPsec Child SA, it sends an IKE Create_Child_SA response message to the N3IWF.

As a result, an IPsec Child SA is established between the UE and N3IWF.

After the IPsec Child SA is established, the N3IWF can send a NAS message including a PDU session establishment acceptance message to the UE via the base station device_120. The NAS message may also be a downlink NAS transport (DL NAS TRANSPORT) message.

The PDU session establishment acceptance message may also be a response message to a PDU session establishment request. The PDU session establishment acceptance message may also indicate that the establishment of the PDU session has been accepted.

Here, the SMF and/or AMF may indicate that at least part of the UE's request in the PDU session establishment request message has been accepted by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a PDU session ID (25th identification information), and/or a NAS message, and/or N2 SM information, and/or an N2 PDU session request message.

Furthermore, when the SMF and/or PCF allows establishment of an SA PDU session for communication using the eATSSS function, and/or when establishment of user plane resources via a 3GPP access is allowed, and/or when communication via the eATSSS function is allowed, the SMF and/or AMF may send an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or an NAS message, and/or an N2 SM information, and/or an N2 PDU session request message, including at least one of the identification information items 21 to 30 and 32.

Here, the identification information 21 to 30 and 32 may be as described in Chapter 3.2.

Here, the 21st identification information is a DNN that identifies the DN to which the second SA PDU session is connected. This 21st identification information is preferably identical to the first identification information and/or the 21st identification information transmitted and received in the PDU session establishment procedure executed via 3GPP access. Also, this 21st identification information is preferably identical to the first identification information transmitted and received in this PDU session establishment procedure.

It is also preferable that this 22nd identification information is identical to the 22nd identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this 23rd identification information is identical to the 23rd identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this 24th identification information is identical to the 24th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that the network supports at least one of the functions indicated by the identification information 22 to 24, and if the function is supported, it is preferable that the identification information indicates that the function is supported.

The 25th identification information may be a PDU session ID that identifies the second SA PDU session. This 25th identification information is preferably different from the fifth identification information and/or the 25th identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access. This 25th identification information may be the same as the fifth identification information transmitted and received in the PDU session establishment procedure.

The 26th identification information may also be a PDU session type of the second SA PDU session. This 26th identification information is preferably identical to the 6th identification information and/or the 26th identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access. This 26th identification information may also be identical to the 6th identification information transmitted and received in this PDU session establishment procedure.

The 27th identification may be the SSC mode of the second SA PDU session. This 27th identification may be the same as or different from the 7th identification and/or the 27th identification transmitted/received in the PDU session establishment procedure performed via the 3GPP access. This 27th identification may be the same as or different from the 7th identification transmitted/received in the PDU session establishment procedure.

The 28th identification information may be one or more S-NSSAIs. This 28th identification information may be the same as or different from the 8th identification information and/or the 28th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access. This 28th identification information may be the same as or different from the 8th identification information transmitted and received in the PDU session establishment procedure.

The 29th identification information may also indicate that establishment of an SA PDU session (for the eATSSS function) is permitted, and/or that establishment of user plane resources via non-3GPP access is permitted, and/or that communication via the eATSSS function is permitted.

Furthermore, the 30th identification information may be an ATSSS rule or a first ATSSS rule. It is preferable that the steering function included in the 30th identification information indicates a steering function supported by the UE or an eATSSS function.

In addition, the SMF and/or AMF may notify the UE that establishment of a SA PDU session for communication using the eATSSS function is permitted, and/or that establishment of user plane resources via non-3GPP access is permitted, and/or that communication via the eATSSS function is permitted, by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a NAS message, and/or an N2 SM information, and/or an N2 PDU session request message including at least one of the identification information items 21 to 30 and 32.

The SMF and/or AMF may notify the UE and/or N3IWF and/or access network of the contents of these identification information by transmitting at least one of these identification information.

Furthermore, the SMF and/or AMF may select or decide which identification information to include in the ATSSS container IE, and/or the new ATSSS container IE, and/or the PDU session establishment acceptance message, and/or the N1 SM container, and/or the NAS message, and/or the N2 SM information, and/or the N2 PDU session request message based on each received identification information, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF and/or AMF, etc.

Next, when the UE receives the NAS message, for example via the N1 interface (S816), it can recognize that the UE's request in the PDU session establishment request message has been accepted and/or the contents of the information, etc. (message, container, information) contained in the NAS message.

For example, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE and/or a new ATSSS container IE including a 30th identification information including a steering function indicating the eATSSS function, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function is authorized, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access is authorized, and/or that user plane resources via non-3GPP access have been established, and/or that communication via the eATSSS function is authorized.

Also, for example, if the UE transmits a 9th identification information indicating a request for establishment of an SA PDU session (for the eATSSS function) or a request for communication via the eATSSS function, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE and/or a new ATSSS container IE including a 30th identification information including a steering function indicating a steering function supported by the UE, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function has been authorized, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access has been authorized, and/or that user plane resources via non-3GPP access have been established, and/or that communication via the eATSSS function has been authorized.

Furthermore, for example, when the UE receives identification information No. 24 indicating that the network supports the eATSSS function, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access is permitted, and/or that user plane resources via non-3GPP access have been established, and/or that communication via the eATSSS function is permitted.

Furthermore, for example, when the UE receives identification information No. 29 indicating that establishment of an SA PDU session (for the eATSSS function) has been permitted, and/or that establishment of user plane resources via non-3GPP access has been permitted, and/or that communication via the eATSSS function has been permitted, the UE may recognize that establishment of an SA PDU session for communication using the eATSSS function has been permitted, and/or that an SA PDU session for communication using the eATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access has been permitted, and/or that user plane resources via non-3GPP access have been established, and/or that communication via the eATSSS function has been permitted.

In addition, the UE may be able to determine that the received 25th identification information (PDU session ID) is for identifying an SA PDU session via non-3GPP access based on the contents of the information etc. (message, container, information) contained in the NAS message.

The procedure in (A) of Figure 8 can now be completed successfully.

At this stage, each device including the UE is in a state in which a second SA PDU session via non-3GPP access is established. The UE may be in a state in which it can communicate with the DN using two SA PDU sessions consisting of the already established first SA PDU session via 3GPP access and the second SA PDU session via non-3GPP access. In other words, the UE may be in a state in which it can communicate using the eATSSS function.

Note that, although the example described here is for untrusted non-3GPP access, the present invention can also be applied to trusted non-3GPP access by replacing base station device_120 and N3IWF_240 with TNAP and TNGF, respectively.

[4.4. When UE request is rejected]
Next, in section 4.1 and/or section 4.3, a procedure for rejecting the UE request is described, which is executed if the first condition determination is false. This procedure may be initiated, for example, when a request to establish a PDU session is rejected, as described above.

First, the SMF sends a PDU session establishment rejection message to the UE via the AMF. Specifically, the SMF sends a PDU session establishment rejection message to the AMF, for example, via the N11 interface. When the AMF receives a PDU session establishment request message from the SMF, it sends a NAS message including a PDU session establishment rejection message to the UE, for example, using the N1 interface.

Here, the SMF may indicate that the UE's request via the PDU session establishment request message has been rejected by sending a PDU session establishment rejection message.

By receiving the PDU session establishment rejection message, the UE can recognize that the UE's request in the PDU session establishment request message has been rejected. In other words, the UE can recognize that the PDU session establishment request has been rejected by the network.

This completes the procedure for rejecting the UE request. Note that the completion of the procedure for rejecting the UE request may mean that the PDU session establishment procedure was not completed normally or that the PDU session establishment procedure was completed abnormally. In this case, the PDU session cannot be established.

[4.5. Application Examples]
In Chapter 4.1, a case has been described in which each device including a UE executes a PDU session establishment procedure via a 3GPP access.

Chapter 4.2 describes the procedures that each device, including the UE, performs after the procedures in Chapter 4.1 when establishment of an MA PDU session is permitted by the SMF and/or PCF in Chapter 4.1, and/or when establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or when communication via the ATSSS function is permitted.

In addition, Chapter 4.3 describes the procedures that each device including the UE performs after the procedures in Chapter 4.1 when, in Chapter 4.1, the SMF and/or PCF permits establishment of an SA PDU session for communication using the eATSSS function, and/or permits establishment of user plane resources via 3GPP access, and/or permits communication via the eATSSS function, and/or instructs to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established out of two SA PDU sessions used for communication via the eATSSS function.

Also, Chapter 4.4 describes a procedure for rejecting a UE request that is executed when the first condition determination is determined to be false in the procedure in Chapter 4.1 and/or the procedure in Chapter 4.3.

In other words, Chapters 4.1 to 4.4 describe a case in which each device, including a UE, first performs a PDU session establishment procedure via 3GPP access, and then, if necessary, performs a PDU session establishment procedure via non-3GPP access.

However, each device including the UE may first execute the PDU session establishment procedure via non-3GPP access, and then, if necessary, execute the PDU session establishment procedure via 3GPP access. In such cases, the above chapters 4.1 to 4.4 can be applied by replacing "3GPP access" with "non-3GPP access" and "base station device_110" with "base station device_120 and N3IWF_240" or "TNAP and TNGF".

[5. Second embodiment]
In this embodiment, a PDU session establishment procedure for establishing an MA PDU session for communication using the ATSSS function and/or an SA PDU session for communication using the eATSSS function when a UE is registered in different PLMNs (operator's core network) via 3GPP access and non-3GPP access is described with reference to Figures 7 and 8.

In addition, if the UE supports the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function requests communication via the ATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the eATSSS function requests communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function and the eATSSS function requests communication via the ATSSS function and/or communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a user has pre-configured a UE supporting the ATSSS function and/or the eATSSS function to communicate via the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, the UE may initiate a PDU session establishment procedure based on information pre-stored in the UE, and/or information pre-received from the access network, and/or information pre-received from the core network (including information received in procedures such as a registration procedure, and/or URSP rules pre-received from the PCF), etc.

[5.1. PDU Session Establishment Procedure via 3GPP Access]
Next, the PDU session establishment procedure executed via 3GPP access will be described with reference to Fig. 7. The contents of Chapter 4.1 can be directly applied to this chapter, so the description of this chapter will be omitted.

Regarding the behavior of each device after the procedure in (A) of Figure 7 is successfully completed, "when establishment of an MA PDU session is permitted, and/or when establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or when communication via the ATSSS function is permitted" is described in Chapter 5.2, and "when establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or when establishment of user plane resources via 3GPP access is permitted, and/or when communication via the eATSSS function is permitted" is described in Chapter 5.3.

The procedure for rejecting a UE request is described in Chapter 5.4.

[5.2. When establishment of MA PDU session for communication via ATSSS function is permitted]
Next, in Chapter 5.1, when the establishment of the MA PDU session is permitted by the SMF and/or the PCF, and/or when the establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or when communication by the ATSSS function is permitted, each device including the UE may start the procedure of Fig. 8 (PDU session establishment procedure via non-3GPP access) to establish user plane resources via non-3GPP access. In this case, (B) of Fig. 7 does not need to be executed. The procedure of Fig. 8 will be described below.

First, the UE that received the NAS message in S716 may be in a state in which it recognizes that an MA PDU session via 3GPP access and non-3GPP access has been established, and/or that user plane resources via 3GPP access in the MA PDU session have been established, as described above. That is, each device including the UE may be in a state in which an MA PDU session using user plane resources via 3GPP access and non-3GPP access has been established. In other words, each device including the UE may be in a state in which it can communicate with the DN using an MA PDU session consisting of user plane resources via 3GPP access.

First, the UE initiates the PDU session establishment procedure by sending a NAS message including an N1SM container including a PDU session establishment request message to the AMF via the access network (S800). The NAS message is, for example, a message sent via the N1 interface, and may be an uplink NAS transport (UL NAS TRANSPORT) message. The PDU session establishment request message may be sent to the AMF using an IPsec SA established for sending and receiving NAS messages between the UE and the AMF prior to this procedure, for example, by performing a registration procedure via non-3GPP access.

Here, the access network is a non-3GPP access. As described above, there are two types of non-3GPP access: untrusted non-3GPP access and trusted non-3GPP access. Here, the case of untrusted non-3GPP access will be described as an example. That is, the UE transmits a NAS message to the AMF via the base station device_120 included in the non-3GPP access.

In addition, the UE can notify the network side of the UE's request by sending a PDU session establishment request message, and/or an N1 SM container, and/or a NAS message including at least one of the identification information 1 to 9 and 11.

Here, identification information 1 to 9 and 11 may be as described in Chapter 3.2.

The first identification information is a DNN that identifies the DN to which the MA PDU session is connected. It is preferable that this first identification information is the same as the first identification information and/or the 21st identification information transmitted and received in the PDU session establishment procedure executed via the 3GPP access.

It is also preferable that this second identification information is identical to the second identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this third identification information is identical to the third identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this fourth identification information is identical to the fourth identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is preferable that the UE supports at least one of the functions indicated by the second to fourth identification information, and if the UE supports a function, it is preferable that the identification information indicates that the function is supported.

The fifth identification information is a PDU session ID for identifying the MA PDU session. It is preferable that this fifth identification information is the same as the fifth identification information and/or the 25th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access. This may be because this procedure is a PDU session establishment procedure performed to establish user plane resources via non-3GPP access that constitute the MA PDU session established in the PDU session establishment procedure performed via 3GPP access. In other words, this may be because the MA PDU sessions are the same.

The sixth identification is a PDU session type of the MA PDU session. This sixth identification is preferably the same as the sixth identification and/or the 26th identification transmitted or received in the PDU session establishment procedure performed via the 3GPP access.

The seventh identification is the SSC mode requested by the UE for the MA PDU session. This seventh identification may be the same as or different from the seventh identification and/or the 27th identification transmitted or received in the PDU session establishment procedure performed via the 3GPP access.

The eighth identification information is one or more S-NSSAIs requested by the UE. The eighth identification information may be one or more S-NSSAIs allowed by the network for both accesses (3GPP access and non-3GPP access) as Allowed NSSAIs included in the Registration Accept message in the Registration procedure performed before starting this procedure. This eighth identification information may be the same as or different from the eighth identification information and/or the 28th identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access.

Furthermore, the ninth identification information may indicate a request for communication via the ATSSS function. This ninth identification information may indicate a request for communication via the ATSSS function.

The ninth identification information may be information indicating a request for establishment of a MA PDU session (for the ATSSS function) and/or information indicating a request for communication by the ATSSS function. This ninth identification information may be a request type. The ninth identification information may be information indicating a request for establishment of user plane resources via a non-3GPP access constituting a MA PDU session. This ninth identification information may be a request type. That is, the request type, which is the ninth identification information, may indicate a request for establishment of a MA PDU session (for the ATSSS function), and/or a request for communication by the ATSSS function, and/or a request for establishment of user plane resources via a non-3GPP access constituting a MA PDU session. For example, when requesting establishment of a MA PDU session (for the ATSSS function), and/or when requesting communication by the eATSSS function, and/or when requesting establishment of user plane resources via a non-3GPP access constituting a MA PDU session, the request type, which is the ninth identification information, may indicate MA PDU request.

In addition, the UE may transmit identification information 1 to 9 and 11 in a control message of a layer lower than the NAS layer (e.g., RRC layer, MAC layer, RLC layer, PDCP layer) or in a control message of a layer higher than the NAS layer (transport layer, session layer, presentation layer, application layer).

In addition, if the identification information 1 to 9 and 11 in this PDU session establishment procedure are identical to the identification information 1 to 9 and 11 in the previous PDU session establishment procedure (PDU session establishment procedure performed via 3GPP access), the UE does not need to transmit the identification information 1 to 9 and 11 in this PDU session establishment procedure.

Next, when the AMF receives the NAS message, it can recognize what the UE is requesting and/or the contents of the information etc. (message, container, information) contained in the NAS message.

Here, the AMF may reject a request to establish user plane resources via a non-3GPP access constituting an MA PDU session if the UE is registered via both accesses but the S-NSSAI (eighth identification information) received from the UE is not authorized for both accesses. In addition, the AMF may reject a request to establish user plane resources via a non-3GPP access constituting an MA PDU session if it does not support the ATSSS function.

Here, the UE being registered via both accesses may mean that the UE is registered to the network via a 3GPP access and the UE is registered to the network via a non-3GPP access.

Additionally, an S-NSSAI that is not authorized for both accesses may mean an S-NSSAI that is not authorized to connect to the network via 3GPP access and is not authorized to connect to the network via non-3GPP access.

Also, when rejecting a request to establish user plane resources via a non-3GPP access constituting an MA PDU session, each device may skip, i.e., abort, steps S802 and onwards.

Furthermore, when rejecting a request to establish user plane resources via a non-3GPP access constituting the MA PDU session, the AMF may transmit to the UE a NAS message including information indicating that the request to establish user plane resources via a non-3GPP access constituting the MA PDU session is rejected. At this time, the AMF does not need to transmit to the SMF at least a portion of the information, etc. (message, container, information) included in the NAS message received from the UE. Furthermore, the UE may detect that the procedure has not been completed normally or that the procedure has been completed abnormally by receiving this NAS message from the AMF.

When rejecting the request to establish user plane resources via a non-3GPP access constituting the MA PDU session, the AMF may transmit information to the SMF indicating that the request to establish user plane resources via a non-3GPP access constituting the MA PDU session is rejected, and the SMF may transmit a NAS message including an N1 SM container including a PDU session establishment rejection message to the UE. At this time, the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message may include information indicating that the request to establish user plane resources via a non-3GPP access constituting the MA PDU session is rejected. Furthermore, the UE may detect that the procedure has not been completed normally or that the procedure has been completed abnormally by receiving the PDU session establishment rejection message and/or the N1 SM container and/or the NAS message from the SMF.

Next, the AMF selects an SMF as a destination for transferring at least a portion of the information (message, container, information) contained in the NAS message received from the UE (S802). The AMF may select the destination SMF based on the information (message, container, information) contained in the NAS message, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the AMF, etc. The AMF may also select an SMF that supports the ATSSS function and/or the eATSSS function. Here, it is assumed that SMF_220 supporting the ATSSS function and/or the eATSSS function is selected.

Next, the AMF transmits to the selected SMF at least a portion of the information (message, container, information) contained in the NAS message received from the UE, for example via the N11 interface (S804). The AMF may also transmit to the SMF information indicating that the UE is registered for both accesses.

Next, when the SMF receives information etc. (message, container, information) sent from the AMF, it can recognize what the UE is requesting and/or the content of the information etc. (message, container, information) received from the AMF.

Here, the SMF may perform a first condition determination. The first condition determination may be for determining whether or not to accept the UE request. In the first condition determination, the SMF determines whether the first condition determination is true or false. If the SMF determines that the first condition determination is true, it may start the procedure of (A) in FIG. 8, and if the SMF determines that the first condition determination is false, it may start a procedure to reject the UE request. The procedure to reject the UE request will be described in Chapter 5.4.

Furthermore, the first condition determination may be performed based on information received from the AMF (message, container, information), and/or subscription information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc.

For example, if the network permits the UE's request, the first condition determination may be determined to be true, and if the network does not permit the UE's request, the first condition determination may be determined to be false. Also, if the network to which the UE is connected and/or a device within the network supports the function requested by the UE, the first condition determination may be determined to be true, and if the function requested by the UE is not supported, the first condition determination may be determined to be false. Also, if the transmitted and received identification information is permitted, the first condition determination may be determined to be true, and if the transmitted and received identification information is not permitted, the first condition determination may be determined to be false.

Furthermore, if the network permits establishment of an MA PDU session, and/or permits establishment of user plane resources via non-3GPP access in the MA PDU session, and/or permits communication via the ATSSS function, the first condition determination may be determined to be true. If the network does not permit establishment of an MA PDU session, and/or does not permit establishment of user plane resources via non-3GPP access in the MA PDU session, and/or does not permit communication via the ATSSS function, the first condition determination may be determined to be false.

In addition, the conditions for determining whether the first condition judgment is true or false do not have to be limited to the conditions described above.

Next, we explain each step of the procedure in Figure 8(A).

First, the SMF may select a PCF. For example, the SMF may select an appropriate PCF based on the received identification information. For example, the SMF may select a PCF that supports the ATSSS and/or eATSSS functions. Also, for example, if the SMF detects that this procedure has been performed to establish user plane resources via non-3GPP access that constitute an MA PDU session used for communication by the ATSSS function, it may select an already selected PCF. Here, it is assumed that PCF_250 that supports the ATSSS and/or eATSSS functions has been selected.

Next, the SMF may send at least a portion of the information etc. (message, container, information) received from the AMF to the PCF (S806).

In addition, when the SMF determines to permit the establishment of a MA PDU session for communication using the ATSSS function, and/or when the SMF determines to permit the establishment of user plane resources via non-3GPP access in the MA PDU session, and/or when the SMF determines to permit communication by the ATSSS function, the SMF may further transmit additional information to the PCF. Here, the additional information may include "information indicating that the establishment of a MA PDU session for communication using the ATSSS function has been permitted", and/or "information indicating that the establishment of user plane resources via non-3GPP access in the MA PDU session has been permitted", and/or "the fact that communication by the ATSSS function has been permitted", and/or "the access type corresponding to the MA PDU session and/or user plane resources to be established". Here, the access type may indicate non-3GPP access.

Note that although the above determination is described as being made by the SMF, it may also be made by the PCF. That is, the SMF and/or the PCF may make the above determination. If the SMF does not make the above determination, the SMF does not need to send the above additional information to the PCF.

Next, when the PCF receives information (messages, containers, information) sent from the SMF, it can recognize their contents.

In addition, the PCF may make a decision similar to the above decision in the SMF based on information received from the SMF (messages, containers, information), and/or UE policies, and/or operator policies, and/or subscription information, etc.

If the PCF makes the above determination, the PCF may send to the SMF the additional information described above as being sent from the SMF to the PCF.

In addition, when the PCF detects that the above judgment is being made in the SMF, it is not necessary to make this judgment (it may be skipped).

In addition, if the SMF and/or PCF allow establishment of an MA PDU session for communication using the ATSSS functionality, and/or allow establishment of user plane resources via non-3GPP access in the MA PDU session, and/or allow communication via the ATSSS functionality, the PCF may generate a second PCC rule or PCC rules.

If the second PCC rule or PCC rule generated in the PDU session establishment procedure via 3GPP access includes a distribution rule for user plane resources via non-3GPP access, the PCF does not need to generate this second PCC rule or PCC rule. In this case, there is no need to send the second PCC rule or PCC rule to the SMF.

In addition, if the second PCC rule or PCC rule generated in the PDU session establishment procedure via 3GPP access does not include a distribution rule for user plane resources via non-3GPP access, a second PCC rule or PCC rule including a distribution rule for user plane resources via non-3GPP access may be generated.

In addition, if the PCF did not generate a second PCC rule or a PCC rule in the PDU session establishment procedure via 3GPP access, it may generate a second PCC rule or a PCC rule in this procedure that includes distribution rules for user plane resources via 3GPP access and distribution rules for user plane resources via 3GPP access.

Then, if the PCF generates a second PCC rule, it may send the generated PCC rule to the SMF.

The PCF may generate the second PCC rule as the aforementioned PCC rule. That is, the PCC rule may be identical to the second PCC rule. Then, the PCF may send the generated PCC rule to the SMF.

Next, when the SMF receives the information sent from the PCF, it can recognize the contents of that information.

When the SMF receives the second PCC rule from the PCF, the SMF may generate a second ATSSS rule (the 30th identification information) and a second N4 rule from the second PCC rule. The SMF may also manage (i.e., map) the second PCC rule, the second ATSSS rule, and the second N4 rule in association with each other.

When the SMF receives a PCC rule instead of the second PCC rule from the PCF, it may generate an ATSSS rule (30th identification information) and an N4 rule from the PCC rule. In this case, the ATSSS rule may be the same as the second ATSSS rule, and the N4 rule may be the same as the second N4 rule. Furthermore, the SMF may manage (i.e., map) the PCC rule, the ATSSS rule, and the N4 rule in association with each other.

Next, the SMF selects a UPF for the MA PDU session and sends an N4 session establishment request message to the selected UPF, for example via the N4 interface (S808).

In addition, when the SMF receives a second PCC rule from the PCF, it may include the second N4 rule in the N4 session establishment request message. In addition, when the SMF receives a PCC rule from the PCF, it may include the N4 rule in the N4 session establishment request message.

Here, the SMF may select one or more UPFs based on information received from the AMF (message, container, information), and/or information received from the PCF, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF, etc. Furthermore, if multiple UPFs are selected, the SMF may send an N4 session establishment request message to each UPF.

Furthermore, if the SMF and/or PCF allow establishment of an MA PDU session for communication using the ATSSS function, and/or allow establishment of user plane resources via non-3GPP access in the MA PDU session, and/or allow communication using the ATSSS function, the SMF may select a UPF that supports the ATSSS function.

The SMF may also select a UPF if one has already been selected in the PDU session establishment procedure performed via 3GPP access.

Here, it is assumed that UPF_230, which supports ATSSS and/or eATSSS functions, is selected.

Next, when the UPF receives an N4 session establishment request message (S808), it can recognize the contents of the information received from the SMF.

In addition, the UPF may be configured to operate in accordance with the received N4 rule when it receives a second N4 rule or an N4 rule from the SMF.

That is, when the UPF receives the second N4 rule, it may configure the downlink traffic in the MA PDU session used for communication by the ATSSS function to operate according to the second N4 rule for the user plane resources via non-3GPP access in the MA PDU session to be established in this procedure (PDU session establishment procedure). Also, when the UPF receives the second N4 rule, it may configure the downlink traffic in the MA PDU session used for communication by the ATSSS function to operate according to the second N4 rule for the user plane resources via 3GPP access and the user plane resources via non-3GPP access. Also, when the UPF receives an N4 rule with the same content as the second N4 rule, it may configure the same as the above.

In addition, the UPF may transmit an N4 session establishment response message to the SMF, for example via the N4 interface, based on receipt of the N4 session establishment request message and/or completion of the above-mentioned settings (S810). This N4 session establishment response message may include information indicating that the above-mentioned settings have been completed.

Next, when the SMF receives an N4 session establishment response message as a response message to the N4 session establishment request message, it can recognize the contents of the information received from the UPF.

Next, the SMF transmits the N1 SM container and/or the N2 SM information and/or the PDU session ID (25th identification information) to the AMF, for example via the N11 interface, based on the reception of the PDU session establishment request message and/or the selection of the UPF and/or the reception of the N4 session establishment response message (S812). Here, the N1 SM container may include a PDU session establishment acceptance message, and further, the PDU session establishment acceptance message may include an ATSSS container IE (Information Element) and/or a new ATSSS container IE.

The AMF then receives the N1 SM container, and/or N2 SM information, and/or the PDU session ID (25th identification information).

Then, when user plane resources are established via non-3GPP access (untrusted non-3GPP access), the AMF may send an N2 PDU session request message to the N3IWF (S814). Here, the N2 PDU session request message may include a NAS message and/or N2 SM information. The NAS message may also include a PDU session ID (25th identification information) and/or an N1 SM container. Furthermore, when user plane resources are established via trusted non-3GPP access, the AMF may send an N2 PDU session request message to the TNGF and/or TNAP.

Next, the N3IWF performs a procedure to establish an IPsec child SA (security association) with the UE via the access network (S816).

Specifically, the N3IWF sends an IKE Create_Child_SA request message to the UE in accordance with the IKEv2 standard described in RFC 7296 to establish an IPsec Child SA for user plane resources via non-3GPP access. Here, the IKE Create_Child_SA request message may indicate that the requested IPsec Child SA operates in tunnel mode. The IKE Create_Child_SA request message may also include a PDU session ID associated with this Child SA. In other words, the IPsec Child SA may be associated with the PDU session ID of the MA PDU session that includes the user plane resources via non-3GPP access.

Next, if the UE accepts the IPsec Child SA, it sends an IKE Create_Child_SA response message to the N3IWF.

As a result, an IPsec Child SA is established between the UE and N3IWF.

After the IPsec Child SA is established, the N3IWF can send a NAS message including a PDU session establishment acceptance message to the UE via the base station device_120. The NAS message may also be a downlink NAS transport (DL NAS TRANSPORT) message.

The PDU session establishment acceptance message may also be a response message to a PDU session establishment request. The PDU session establishment acceptance message may also indicate that the establishment of the PDU session has been accepted.

Here, the SMF and/or AMF may indicate that at least part of the UE's request in the PDU session establishment request message has been accepted by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a PDU session ID (25th identification information), and/or a NAS message, and/or N2 SM information, and/or an N2 PDU session request message.

Furthermore, when the SMF and/or PCF permits establishment of an MA PDU session for communication using the ATSSS function, and/or permits establishment of user plane resources via non-3GPP access in an MA PDU session, and/or permits communication using the ATSSS function, the SMF and/or AMF may send an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or an NAS message, and/or an N2 SM information, and/or an N2 PDU session request message, including at least one of the identification information nos. 21 to 30 and 32.

Here, the identification information 21 to 30 and 32 may be as described in Chapter 3.2.

Here, the 21st identification information is a DNN that identifies the DN to which the MA PDU session is connected. It is preferable that this 21st identification information is identical to the first identification information and/or the 21st identification information transmitted and received in the PDU session establishment procedure executed via 3GPP access. It is also preferable that this 21st identification information is identical to the first identification information transmitted and received in this PDU session establishment procedure.

It is also preferable that this 22nd identification information is identical to the 22nd identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this 23rd identification information is identical to the 23rd identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that this 24th identification information is identical to the 24th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access.

It is also preferable that the network supports at least one of the functions indicated by the identification information 22 to 24, and if the function is supported, it is preferable that the identification information indicates that the function is supported.

The 25th identification information may be a PDU session ID that identifies the MA PDU session. It is preferable that this 25th identification information is identical to the fifth identification information and/or the 25th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access. The 25th identification information may be identical to the fifth identification information transmitted and received in the PDU session establishment procedure.

The 26th identification information may also be a PDU session type of the MA PDU session. This 26th identification information is preferably identical to the 6th identification information and/or the 26th identification information transmitted and received in the PDU session establishment procedure performed via the 3GPP access. This 26th identification information may also be identical to the 6th identification information transmitted and received in the PDU session establishment procedure.

The 27th identification information may also be the SSC mode of the MA PDU session. This 27th identification information may be the same as or different from the 7th identification information and/or the 27th identification information transmitted or received in the PDU session establishment procedure performed via the 3GPP access. This 27th identification information may also be the same as or different from the 7th identification information transmitted or received in the PDU session establishment procedure.

The 28th identification information may be one or more S-NSSAIs. This 28th identification information may be the same as or different from the 8th identification information and/or the 28th identification information transmitted and received in the PDU session establishment procedure performed via 3GPP access. This 28th identification information may be the same as or different from the 8th identification information transmitted and received in the PDU session establishment procedure.

In addition, the 29th identification information may indicate that establishment of an MA PDU session for communication using the ATSSS function is permitted, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that communication via the ATSSS function is permitted.

The 30th identification information is an ATSSS rule or a second ATSSS rule. It is preferable that the steering function included in the 30th identification information indicates a steering function supported by the UE, an ATSSS-LL function, or an MPTCP function.

In addition, the SMF and/or AMF may notify the UE that establishment of an MA PDU session for communication using the ATSSS function is permitted, and/or that an MA PDU session for communication using the ATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that user plane resources via non-3GPP access in the MA PDU session has been established, and/or that communication via the ATSSS function is permitted, by sending an ATSSS container IE, and/or a new ATSSS container IE, and/or a PDU session establishment accept message, and/or an N1 SM container, and/or a NAS message, and/or an N2 SM information, and/or an N2 PDU session request message including at least one of the identification information 21 to 30 and 32.

The SMF and/or AMF may notify the UE and/or N3IWF and/or access network of the contents of these identification information by transmitting at least one of these identification information.

Furthermore, the SMF and/or AMF may select or decide which identification information to include in the ATSSS container IE, and/or the new ATSSS container IE, and/or the PDU session establishment acceptance message, and/or the N1 SM container, and/or the NAS message, and/or the N2 SM information, and/or the N2 PDU session request message based on each received identification information, and/or subscriber information, and/or network capability information, and/or UE policy, and/or operator policy, and/or network status, and/or user registration information, and/or context held by the SMF and/or AMF, etc.

Next, when the UE receives the NAS message, for example via the N1 interface (S816), it can recognize that the UE's request in the PDU session establishment request message has been accepted and/or the contents of the information, etc. (message, container, information) contained in the NAS message.

For example, when a UE receives a PDU session establishment acceptance message including an ATSSS container IE including a 30th identification information including a steering function indicating the ATSSS capability, the UE may recognize that establishment of an MA PDU session for communication using the ATSSS capability is permitted, and/or that an MA PDU session for communication using the ATSSS capability has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that user plane resources via non-3GPP access in the MA PDU session have been established, and/or that communication via the ATSSS capability is permitted.

Also, for example, if the UE transmits a ninth identification information indicating that it is requesting establishment of an MA PDU session (for the ATSSS function) or that it is requesting communication via the ATSSS function, when the UE receives a PDU session establishment acceptance message including an ATSSS container IE including a 30th identification information including a steering function indicating a steering function supported by the UE, the UE may recognize that establishment of an MA PDU session for communication using the ATSSS function has been permitted, and/or that an MA PDU session for communication using the ATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session has been permitted, and/or that user plane resources via non-3GPP access in the MA PDU session has been established, and/or that communication via the ATSSS function has been permitted.

Furthermore, for example, when the UE receives identification information No. 22 indicating that the network supports the ATSSS-LL function and/or identification information No. 23 indicating that the network supports the MPTCP function, the UE may recognize that establishment of an MA PDU session for communication using the ATSSS function is permitted, and/or that an MA PDU session for communication using the ATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session is permitted, and/or that user plane resources via non-3GPP access in the MA PDU session have been established, and/or that communication via the ATSSS function is permitted.

Furthermore, for example, when the UE receives identification information No. 29 indicating that establishment of an MA PDU session (for the ATSSS function) has been permitted, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session has been permitted, and/or that communication via the ATSSS function has been permitted, the UE may recognize that establishment of an MA PDU session for communication using the ATSSS function has been permitted, and/or that an MA PDU session for communication using the ATSSS function has been established, and/or that establishment of user plane resources via non-3GPP access in the MA PDU session has been permitted, and/or that user plane resources via non-3GPP access in the MA PDU session has been established, and/or that communication via the ATSSS function has been permitted.

In addition, the UE may be able to determine that the received 25th identification information (PDU session ID) is for identifying an MA PDU session based on the contents of information etc. (message, container, information) contained in the NAS message.

The procedure in (A) of Figure 8 can now be completed successfully.

At this stage, each device including the UE is in a state where user plane resources via non-3GPP access are established. The UE may be in a state where it can communicate with the DN using an MA PDU session consisting of the already established user plane resources via 3GPP access and user plane resources via non-3GPP access. In other words, the UE may be in a state where it can communicate using the ATSSS function.

Note that, although the example described here is for untrusted non-3GPP access, it can also be applied to trusted non-3GPP access by replacing base station device_120 and N3IWF_240 with TNAP and TNGF, respectively.

[5.3. When establishment of an SA PDU session for communication via the eATSSS function is permitted]
Next, in Chapter 5.1, when the SMF and/or PCF permits the establishment of an SA PDU session for communication using the eATSSS function, and/or permits the establishment of user plane resources via 3GPP access, and/or permits communication by the eATSSS function, and/or instructs the execution of a PDU session establishment procedure to establish an SA PDU session that has not yet been established among two SA PDU sessions used for communication by the eATSSS function, each device including the UE may start the procedure of FIG. 8 (PDU session establishment procedure via non-3GPP access) to establish an SA PDU session via non-3GPP access (second SA PDU session). In this case, (B) of FIG. 7 does not need to be executed. The procedure of FIG. 8 will be described below. This chapter can be applied as it is to the contents described in Chapter 4.3, so the description of this chapter will be omitted. The procedure for rejecting a UE request will be described in Chapter 5.4.

[5.4. When UE request is rejected]
Next, the procedure for rejecting the UE request, which is executed when the first condition determination is false in Chapter 5.1 and/or Chapter 5.3, is described. The contents described in Chapter 4.4 can be applied to this chapter as is, so the description of this chapter is omitted.

[5.5. Application Examples]
In Chapter 5.1, a case has been described in which each device including a UE performs a PDU session establishment procedure via a 3GPP access.

Chapter 5.2 describes the procedures that each device, including the UE, performs after the procedures in Chapter 5.1 when establishment of an MA PDU session is permitted by the SMF and/or PCF in Chapter 5.1, and/or when establishment of user plane resources via 3GPP access in an MA PDU session is permitted, and/or when communication via ATSSS function is permitted.

In addition, Chapter 5.3 describes the procedures that each device including the UE performs after the procedures in Chapter 5.1 when, in Chapter 5.1, the SMF and/or PCF permits establishment of an SA PDU session for communication using the eATSSS function, and/or permits establishment of user plane resources via 3GPP access, and/or permits communication via the eATSSS function, and/or instructs to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established out of two SA PDU sessions used for communication via the eATSSS function.

Also, Chapter 5.4 describes a procedure for rejecting a UE request that is executed when the first condition determination is determined to be false in the procedure in Chapter 5.1 and/or the procedure in Chapter 5.3.

In other words, Chapters 5.1 to 5.4 describe a case in which each device, including a UE, first performs a PDU session establishment procedure via 3GPP access, and then, if necessary, performs a PDU session establishment procedure via non-3GPP access.

However, each device including the UE may first execute the PDU session establishment procedure via non-3GPP access, and then, if necessary, execute the PDU session establishment procedure via 3GPP access. In such cases, the above chapters 5.1 to 5.4 can be applied by replacing "3GPP access" with "non-3GPP access" and "base station device_110" with "base station device_120 and N3IWF_240" or "TNAP and TNGF".

[6. Third embodiment]
In this embodiment, a PDU session establishment procedure for establishing an MA PDU session for communication using the ATSSS function and/or an SA PDU session for communication using the eATSSS function when a UE is registered in a PLMN (operator's core network) via 3GPP access or non-3GPP access is described with reference to Figures 7 and 8.

In addition, if the UE supports the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function requests communication via the ATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the eATSSS function requests communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a UE supporting the ATSSS function and the eATSSS function requests communication via the ATSSS function and/or communication via the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, if a user has pre-configured a UE supporting the ATSSS function and/or the eATSSS function to communicate via the ATSSS function and/or the eATSSS function, the UE may initiate a PDU session establishment procedure. In addition, the UE may initiate a PDU session establishment procedure based on information pre-stored in the UE, and/or information pre-received from the access network, and/or information pre-received from the core network (including information received in procedures such as a registration procedure, and/or URSP rules pre-received from the PCF), etc.

Here, we consider the case where the UE is registered to one PLMN via 3GPP access and is not registered to a PLMN via non-3GPP access.

[6.1. PDU Session Establishment Procedure via 3GPP Access]
Next, since the UE is registered to a PLMN via 3GPP access, the PDU session establishment procedure performed via 3GPP access will be described with reference to Figure 7. This chapter can be applied to the contents described in Chapter 4.1 as it is, so the description of this chapter will be omitted.

Regarding the behavior of each device after the procedure in (A) of Figure 7 is successfully completed, "when establishment of an MA PDU session is permitted, and/or when establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or when communication via the ATSSS function is permitted" is described in Chapter 6.3, and "when establishment of an SA PDU session for communication using the eATSSS function is permitted, and/or when establishment of user plane resources via 3GPP access is permitted, and/or when communication via the eATSSS function is permitted" is described in Chapter 6.4.

Also, after the procedure of (A) in Figure 7 in Chapter 6.1 is successfully completed, before performing the procedure in Chapter 6.3 or the procedure in Chapter 6.4, the UE needs to be registered to the network via non-3GPP access, and therefore the procedure in Chapter 6.2 needs to be performed.

The procedure for rejecting a UE request is described in Chapter 6.5.

[6.2. Registration Procedure]
Next, after the procedure in FIG. 7(A) in the procedure in Chapter 6.1 is normally completed, in order to execute the procedure in Chapter 6.3 or the procedure in Chapter 6.4, the UE executes a registration procedure via non-3GPP access in order to register to the network via non-3GPP access. This registration procedure will be described with reference to FIG. 6. Here, the non-3GPP access will be described taking the case of untrusted non-3GPP access as an example. The registration procedure is also referred to as this procedure. The registration procedure is a procedure in 5GS. The registration procedure is a procedure for the UE to take the initiative in registering to the access network, and/or the core network, and/or the DN. If the UE is not registered to the network, it can execute this procedure at any time, such as when the power is turned on. In other words, if the UE is in a deregistered state (RM-DEREGISTERED state), it can start this procedure at any time. In addition, each device (especially the UE and the AMF) can transition to a registered state (RM-REGISTERED state) based on completion of the registration procedure.

Furthermore, the registration procedure may be a procedure for updating location registration information of the UE in the network and/or for periodically notifying the network of the status of the UE from the UE and/or for updating certain parameters relating to the UE in the network.

The UE may initiate the registration procedure when mobility across TAs occurs. In other words, the UE may initiate the registration procedure when it moves to a TA different from the TA indicated in the TA list it holds. Furthermore, the UE may initiate this procedure when an active timer expires. Furthermore, the UE may initiate the registration procedure when it is necessary to update the context of each device due to disconnection or invalidation of a PDU session. Furthermore, the UE may initiate the registration procedure when there is a change in the capability information and/or preferences regarding the establishment of the UE's PDU session. Furthermore, the UE may initiate the registration procedure periodically. Furthermore, the UE may initiate the registration procedure based on the completion of a UE configuration update procedure. Note that the UE can execute the registration procedure at any timing, not limited to the above.

First, the UE may initiate a procedure to establish an IPsec SA (security association) with the N3IWF.

Then, the UE starts the registration procedure by transmitting a registration request message to the AMF via the 5G AN (S600) (S602) (S604). Specifically, the UE transmits a registration request message to the N3IWF via the base station device_120 in the 5G AN (S600). The registration request message is a NAS message.

Here, the UE can send the registration request message including the identification information 2 to 4, 8, and 11, but it may also send the same in a control message that is different from these.

Here, the identification information 2 to 4, 8 and 11 may be as described in Chapter 3.2.

The UE can inform the network of the contents of these identities by transmitting these identities. These identities may be included in these messages to indicate the UE's requests.

The UE may also initiate a PDU session establishment procedure during the registration procedure by sending a registration request message including an SM message (e.g., a PDU session establishment request message) or by sending an SM message (e.g., a PDU session establishment request message) together with the registration request message.

When the N3IWF in the 5G AN receives the registration request message, it selects an AMF to which to forward the registration request message (S602). The N3IWF in the 5G AN can select an AMF based on the information contained in the registration request message. Here, it is assumed that AMF_210 is selected. The gNB_110 in the 5G AN forwards the received registration request message to the selected AMF_210 (S604).

When AMF_210 receives a registration request message, it can recognize that a UE is making the request and/or the contents of the various identification information contained in the registration request message.

When AMF_210 receives the registration request message, it can perform a second condition determination. The second condition determination is for determining whether the network (or AMF) accepts the UE's request. If the second condition determination is true, the AMF starts the procedure of (A) in Figure 6.

The second condition determination may be performed based on the reception of a registration request message, and/or each identification information included in the registration request message, and/or subscriber information, and/or network capability information, and/or operator policy, and/or network status, and/or user registration information, and/or a context held by the AMF. For example, if the network permits the UE request, the second condition determination may be true, and if the network does not permit the UE request, the second condition determination may be false. Also, if the network to which the UE is registered and/or a device in the network supports the function requested by the UE, the second condition determination may be true, and if the network does not support the function requested by the UE, the second condition determination may be false. Furthermore, if the identification information to be transmitted and received is permitted, the second condition determination may be true, and if the identification information to be transmitted and received is not permitted, the second condition determination may be false. The conditions for determining the truth or falsity of the second condition determination may not be limited to the above-mentioned conditions.

First, we will explain the case where the second condition determination is true. In the procedure of (A) of Figure 6, AMF_210 may first execute the fourth condition determination. The fourth condition determination is for determining whether AMF_210 sends and receives SM messages between itself and the SMF. Furthermore, if the second condition determination is true, the fourth condition determination does not need to be executed.

The fourth condition determination may be performed based on whether AMF_210 has received an SM message. The fourth condition determination may also be performed based on whether an SM message is included in the registration request message. For example, if AMF_210 has received an SM message and/or if the registration request message includes an SM message, the fourth condition determination may be true, and if AMF_210 has not received an SM message and/or if the registration request message does not include an SM message, the fourth condition determination may be false. The conditions that determine whether the fourth condition determination is true or false do not have to be limited to the conditions described above.

If the fourth condition decision is true, AMF_210 selects an SMF and sends and receives SM messages with the selected SMF, but if the fourth condition decision is false, it does not do so (S606). Here, it is assumed that SMF_220 is selected. In addition, even if the fourth condition decision is true, AMF_210 may abort the procedure of (A) in Figure 6 if it receives an SM message indicating rejection from the SMF.

In addition, in S606, when AMF_210 transmits and receives SM messages with SMF_220, it can notify SMF_220 of the identification information received in the registration request message. SMF_220 can obtain the identification information received from AMF_210 by transmitting and receiving SM messages with AMF.

Then, once an IPsec SA is established between the UE and N3IWF, the N3IWF notifies the AMF that the UE context has been established.

Next, AMF_210 transmits a registration accept message to the UE via the N3IWF and base station device_120 as a response message to the registration request message based on receipt of the registration request message and/or completion of transmission and reception of an SM message with SMF_220 (S608). For example, if the fourth condition determination is true, AMF_210 may transmit a registration accept message based on receipt of a registration request message from the UE. Also, if the fourth condition determination is false, AMF_210 may transmit a registration accept message based on completion of transmission and reception of an SM message with SMF_220. The registration accept message is a NAS message transmitted and received on the N1 interface.

AMF_210 may send the registration acceptance message including at least one of identification information 22-24, 28, and 32.

Here, the identification information 22 to 24, 28, and 32 may be as described in Chapter 3.2.

Furthermore, AMF_210 can notify the UE of the contents of these identification information by transmitting at least one of these identification information. Furthermore, AMF_210 can indicate that the network supports each function by transmitting these identification information, or that the UE's request has been accepted. Furthermore, two or more of these identification information may be configured as one or more identification information. Furthermore, the information indicating support for each function and the information indicating a request to use each function may be transmitted and received as the same identification information, or may be transmitted and received as different identification information.

AMF_210 may also select and determine which identification information to include in the registration acceptance message based on each received identification information, and/or subscriber information, and/or network capability information, and/or operator policy, and/or network status, and/or user registration information, and/or context held by AMF_210, etc.

Furthermore, AMF_210 can either include an SM message (e.g., a PDU session establishment acceptance message) in the registration acceptance message and send it, or send an SM message (e.g., a PDU session establishment acceptance message) together with the registration acceptance message. However, this transmission method may be executed when an SM message (e.g., a PDU session establishment request message) is included in the registration request message and the fourth condition determination is true. Also, this transmission method may be executed when an SM message (e.g., a PDU session establishment request message) is included together with the registration request message and the fourth condition determination is true. By performing such a transmission method, the AMF can indicate that the procedure for SM has been accepted in the registration procedure.

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

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

The UE receives a registration acceptance message via gNB_110 (S608). By receiving the registration acceptance message, the UE can recognize that the UE's request in the registration request message has been accepted and/or the contents of each identification information included in the registration acceptance message.

The UE can further transmit a registration completion message to AMF_210 via gNB_110 as a response message to the registration acceptance message (S610). When the UE receives an SM message such as a PDU session establishment acceptance message, the UE may transmit an SM message such as a PDU session establishment completion message including the registration completion message, or may indicate that the procedure for SM has been completed by including the SM message. Here, the registration completion message is a NAS message transmitted and received on the N1 interface, but is transmitted and received between the UE and the gNB included in an RRC message.

AMF_210 receives a registration completion message via gNB_110 (S610). In addition, each device completes the procedure of (A) in Figure 6 based on the sending and receiving of a registration acceptance message and/or a registration completion message.

Upon completion of the procedure (A) of Figure 6, the UE may be registered in the network via non-3GPP access.

Next, we will explain the case where the second condition judgment is false. AMF_210 transmits a Registration reject message to the UE via N3IWF and base station device_120 as a response message to the Registration request message (S612). Here, the Registration reject message is a NAS message transmitted and received on the N1 interface.

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

The UE receives a registration rejection message via the N3IWF and base station device_120 (S612). By receiving the registration rejection message, the UE can recognize that the UE's request in the registration request message has been rejected, and the contents of the various identification information included in the registration rejection message. In addition, if the UE does not receive a registration rejection message even after a predetermined period of time has elapsed after sending the registration request message, the UE may recognize that the UE's request has been rejected. Each device completes this procedure based on the sending and receiving of the registration rejection message.

In the procedure of FIG. 6(A), if the fourth condition determination is true, AMF_210 may send a registration rejection message including an SM message indicating a rejection of a PDU session establishment rejection message, or may indicate that the procedure for SM has been rejected by including an SM message indicating a rejection. In that case, the UE may further receive an SM message indicating a rejection of a PDU session establishment rejection message, or may recognize that the procedure for SM has been rejected.

Each device completes the registration procedure based on the completion of the procedure in (A) of FIG. 6. In addition, each device may transition to a state in which the UE is registered in the network (RM_REGISTERED state) based on the completion of the procedure in (A) of FIG. 6. In addition, the transition of each device to each state may be performed based on the completion of the registration procedure or the establishment of a PDU session.

Furthermore, each device may perform processing based on the information transmitted and received during the registration procedure based on the completion of the registration procedure. For example, when transmitting and receiving information indicating that some of the UE's requests have been rejected, the device may recognize the reason why the UE's requests were rejected. Furthermore, each device may perform this procedure again based on the reason why the UE's request was rejected, or may perform the registration procedure for the core network or another cell.

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

[6.3. When establishment of MA PDU session for communication via ATSSS function is permitted]
Next, in Chapter 6.1, when the establishment of the MA PDU session is permitted by the SMF and/or PCF, and/or when the establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or when communication by the ATSSS function is permitted, each device including the UE that has completed the registration procedure in Chapter 6.2 may start the procedure in Figure 8 (PDU session establishment procedure via non-3GPP access) to establish user plane resources via non-3GPP access. In this case, (B) in Figure 7 does not need to be executed. The procedure in Figure 8 will be described below. This chapter can be applied as it is to the contents described in Chapter 5.2, so the description of this chapter will be omitted.

The procedure for rejecting a UE request is explained in Chapter 6.5.

[6.4. When establishment of an SA PDU session for communication via the eATSSS function is permitted]
Next, in Chapter 6.1, when the establishment of an SA PDU session for communication using the eATSSS function is permitted by the SMF and/or PCF, and/or the establishment of user plane resources via 3GPP access is permitted, and/or communication by the eATSSS function is permitted, and/or a PDU session establishment procedure is instructed to be performed to establish an SA PDU session that has not yet been established among two SA PDU sessions used for communication by the eATSSS function, each device including the UE that has completed the registration procedure in Chapter 6.2 may start the procedure in FIG. 8 (PDU session establishment procedure via non-3GPP access) to establish an SA PDU session via non-3GPP access (second SA PDU session). In this case, (B) in FIG. 7 does not need to be executed. The procedure in FIG. 8 will be described below. This chapter can be applied as it is to the contents described in Chapter 5.3, so the description of this chapter will be omitted. The procedure for rejecting a UE request will be described in Chapter 6.5.

[6.5. When UE request is rejected]
Next, the procedure for rejecting the UE request, which is executed when the first condition determination is false in Chapter 6.1 and/or Chapter 6.4, is described. The contents described in Chapter 4.4 can be applied to this chapter as is, so the description of this chapter is omitted.

[6.6. Application Examples]
In Chapter 6.1, a case has been described in which each device including a UE performs a PDU session establishment procedure via 3GPP access.

Chapter 6.2 describes the case where each device, including the UE, performs the registration procedure via non-3GPP access.

In addition, Chapter 6.3 describes the procedures that each device, including the UE, performs after the procedures in Chapter 6.2 when the establishment of an MA PDU session is permitted by the SMF and/or PCF in Chapter 6.1, and/or the establishment of user plane resources via 3GPP access in the MA PDU session is permitted, and/or communication via the ATSSS function is permitted.

In addition, Chapter 6.4 describes the procedures that each device including the UE performs after the procedures in Chapter 6.2 when, in Chapter 6.1, the SMF and/or PCF permits establishment of an SA PDU session for communication using the eATSSS function, and/or permits establishment of user plane resources via 3GPP access, and/or permits communication via the eATSSS function, and/or instructs to perform a PDU session establishment procedure to establish an SA PDU session that has not yet been established out of two SA PDU sessions used for communication via the eATSSS function.

Also, Chapter 6.5 describes a procedure for rejecting a UE request that is executed when the first condition determination is determined to be false in the procedure in Chapter 6.1 and/or the procedure in Chapter 6.4.

In other words, Chapters 6.1 to 6.5 describe a case in which each device, including a UE, first performs a PDU session establishment procedure via 3GPP access, and then, if necessary, performs a PDU session establishment procedure via non-3GPP access.

However, each device including the UE may first execute the PDU session establishment procedure via non-3GPP access, and then, if necessary, execute the PDU session establishment procedure via 3GPP access. This can also be applied to such cases by replacing "3GPP access" with "non-3GPP access" and "base station device_110" with "base station device_120 and N3IWF_240" or "TNAP and TNGF" in the above Chapters 6.1 to 6.5.

[7. Other]
A program that operates on an apparatus according to an aspect of the present invention may be a program that controls a Central Processing Unit (CPU) or the like to cause a computer to function so as to realize the functions of an embodiment according to an aspect of the present invention. The program or information handled by the program is temporarily stored in a volatile memory such as a Random Access Memory (RAM), a non-volatile memory such as a flash memory, a Hard Disk Drive (HDD), or other storage device system.

A program for realizing the functions of an embodiment according to one aspect of the present invention may be recorded on a computer-readable recording medium. The program may be read into a computer system and executed to realize the functions. The term "computer system" as used here refers to a computer system built into a device, and includes hardware such as an operating system and peripheral devices. The term "computer-readable recording medium" may be a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a medium that dynamically holds a program for a short period of time, or any other recording medium that can be read by a computer.

In addition, each functional block or feature of the device used in the above-mentioned embodiment may be implemented or performed by an electric circuit, for example, an integrated circuit or multiple integrated circuits. The electric circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or a conventional processor, controller, microcontroller, or state machine. The electric circuit may be composed of digital circuits or analog circuits. In addition, if a technology for integrated circuitization that replaces current integrated circuits emerges due to advances in semiconductor technology, one or more aspects of the present invention may use a new integrated circuit based on that technology.

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

Although an embodiment of the present invention has been described above in detail with reference to the drawings, the specific configuration is not limited to this embodiment, and design modifications and the like that do not depart from the gist of the present invention are also included. Furthermore, the present invention can be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. Also included are configurations in which elements described in the above embodiments are substituted for elements that have the same effect.

1. Mobile communication systems
10UE
100 Access Network
102 Access Network
110 Base Station Equipment
120 Base Station Equipment
200 Core Network
210 AMF
220 SMF
230 UPF
240 N3IWF
250 PCF
300DN

Claims (1)

A UE (User Equipment) including a control unit and a transceiver unit,
The transmitting/receiving unit is
sending a PDU session establishment request message to the core network, the message including information indicating a request for permission to communicate using an eATSSS function that communicates using two SA PDU sessions consisting of a first SA PDU session via a 3GPP access and a second SA PDU session via a non-3GPP access;
When receiving a PDU session establishment acceptance message including an ATSSS container IE including an ATSSS rule including a steering function indicating the eATSSS function from the core network , the control unit recognizes that an SA PDU session for the eATSSS function has been established.
The UE is characterized by:

Images