JP7765405B2 - UE (User Equipment) - Google Patents

Description

The present invention relates to UE (User Equipment). This application claims priority to Japanese Patent Application No. 2020-193359, filed on November 20, 2020, the contents of which are incorporated herein by reference.

The 3GPP (3rd Generation Partnership Project) is studying the system architecture of the 5th generation (5G) mobile communications system, 5GS (5G System), and is discussing how to support new procedures and new functions (see Non-Patent Documents 1 to 3). The Release 16 standard introduced the concept of NPN (Non-Public Network), and its functional extensions are being discussed in Release 17 (see Non-Patent Document 4).

3GPP TS 23.501 V16.6.0 (2020-09); 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.6.0 (2020-09); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System; Stage 2 (Release 16) 3GPP TS 24.501 V17.0.0 (2020-09); 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 TR 23.700-07 V1.1.0 (2020-10); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on enhanced support of non-public networks (Release 17)

Non-Patent Document 4 was intended to discuss support for non-3GPP access to SNPN (Stand-alone NPN), a form of NPN, but has not yet done so. Furthermore, specifically, it does not disclose any method for connecting to an SNPN service using non-3GPP access, a method for connecting to a PLMN service via an SNPN connected using non-3GPP access, or a method for connecting to an SNPN service via a PLMN connected using non-3GPP access.

One aspect of the present invention has been made in consideration of the above circumstances, and aims to clarify a method of connecting to an SNPN service using non-3GPP access, a method of connecting to a PLMN service via an SNPN connected using non-3GPP access, and a method of connecting to an SNPN service via a PLMN connected using non-3GPP access.

One aspect of the UE of the present invention is a UE (User Equipment) equipped with a control unit, which, when connecting to an SNPN (Stand-alone Non-Public Network) using non-3GPP access, operates in SNPN access mode on the non-3GPP access.

In another aspect of the present invention, a UE (User Equipment) is provided with a control unit, and when connecting to an SNPN (Stand-alone Non-Public Network) service via a PLMN (Public Land Mobile Network) using non-3GPP access, the control unit does not operate in SNPN access mode for the PLMN, but operates in SNPN access mode for the SNPN.

According to one aspect of the present invention, a method for connecting to an SNPN service using non-3GPP access, a method for connecting to a PLMN service via an SNPN connected using non-3GPP access, and a method for connecting to an SNPN service via a PLMN connected using non-3GPP access can be provided.

1 is a diagram illustrating an outline of a mobile communication system 1. FIG. FIG. 1 is a diagram illustrating a detailed configuration of a mobile communication system 1. FIG. 1 is a diagram illustrating an outline of a mobile communication system 2. FIG. 2 is a diagram illustrating a detailed configuration of the mobile communication system 2. FIG. 2 is a diagram illustrating a detailed configuration of the mobile communication system 2. FIG. 1 is a diagram illustrating an outline of a mobile communication system 3. FIG. 2 is a diagram illustrating a detailed configuration of a mobile communication system 3. FIG. 2 is a diagram illustrating a detailed configuration of a mobile communication system 3. FIG. 1 is a diagram illustrating the device configuration of a UE. A diagram explaining the configuration of an access network device (gNB) in 5GS. A diagram explaining the configuration of core network devices (AMF/SMF/UPF/N3IWF/NF) in 5GS. FIG. 10 is a diagram illustrating a registration procedure. A diagram explaining the PDU session establishment procedure.

The best mode for implementing one aspect of the present invention will be described below with reference to the drawings. In this embodiment, as an example, an embodiment of a mobile communication system to which one aspect of the present invention is applied will be described.

[1. System Overview]
Here, each mobile communication system will be explained.

First, Figure 1 is a diagram for explaining the outline of mobile communication system 1, and Figure 2 is a diagram for explaining its detailed configuration. Furthermore, Figure 3 is a diagram for explaining the outline of mobile communication system 2, and Figures 4 and 5 are diagrams for explaining its detailed configuration. Furthermore, Figure 6 is a diagram for explaining the outline of mobile communication system 3, and Figures 7 and 8 are diagrams for explaining its detailed configuration.

Figure 1 shows a communication system 1 consisting of a UE (User Equipment)_10, an access network_100, a core network_200, and a DN (Data Network)_250.

Hereinafter, these symbols may be omitted. Furthermore, the access network _100 in FIG. 1 may be either 3GPP access or non-3GPP access, but here it is assumed to be non-3GPP access. The communication system 1 in FIG. 1 assumes that the UE connects directly to an SNPN service (hereinafter also referred to as a service provided by an SNPN, or an SNPN) via non-3GPP access. In other words, when the UE connects directly to an SNPN service, it performs a registration procedure with the core network _200 via the non-3GPP access (access network _100) in the SNPN to enter a registered state, and then performs a PDU session establishment procedure to establish a PDU session (hereinafter also referred to as a first PDU session) that enables communication with the DN _250. At this time, the UE can be said to be connected to the SNPN service. Furthermore, the access network _100, and/or the core network _200, and/or the DN _250 can be said to be networks that constitute the SNPN. Furthermore, it can be said that the devices and network functions included in the access network 100, the core network 200, and the DN 250 are devices and network functions that constitute the SNPN. The communication system 1 is such a communication system.

Figure 2 also shows devices and network functions such as UE_10, AMF_210, SMF_220, UPF_230, N3IWF_240, and DN_250, as well as the interfaces that connect them to each other.

Hereinafter, these symbols may be omitted. Note that the AMF, SMF, UPF, and N3IWF may be included in the core network 200. Also, although not shown in Figure 2, a base station device or an access point is installed between the UE and the N3IWF. The base station device or access point may be included in the access network.

Figure 3 also shows a communication system 2 consisting of UE_10, access network_102, core network_202, DN_252, core network_200, and DN_250.

Hereinafter, these symbols may be omitted. Also, while access network_102 in FIG. 3 may be 3GPP access or non-3GPP access, it is assumed here that it is non-3GPP access. Communication system 2 in FIG. 3 assumes that the UE connects to an SNPN service via a PLMN. Specifically, communication system 2 in FIG. 3 assumes that the UE first connects to a PLMN service (hereinafter also referred to as a service provided by a PLMN, or PLMN) via non-3GPP access, and then connects to an SNPN service via 3GPP access or non-3GPP access. More specifically, the UE first performs a registration procedure with core network_202 via non-3GPP access (access network_102) in the PLMN to enter a registered state, and then performs a PDU session establishment procedure to establish a PDU session (hereinafter also referred to as a second PDU session), enabling communication with DN_252. At this time, it may be said that the UE is connected to the PLMN service. Here, when the UE connects to the SNPN service via the PLMN, the access network_102, core network_202, and DN_252 constituting the PLMN, and/or the second PDU session, and/or the user plane resources (communication resources for transmitting and receiving user data) constituting the second PDU session may be treated as 3GPP access or non-3GPP access (access network_100). Then, when the UE further connects to the SNPN service via the PLMN, it performs a registration procedure with the core network_200 via the 3GPP access or non-3GPP access to enter a registered state, and then performs a PDU session establishment procedure to establish a PDU session (hereinafter also referred to as a third PDU session) to enable communication with the DN_250. At this time, it may be said that the UE is connected to the SNPN service via the PLMN. Furthermore, it may be said that the access network _102, and/or the core network _202, and/or the DN 252 are networks constituting a PLMN. It may be said that the devices and network functions included in the access network _102, the core network _202, and the DN 252 are devices and network functions constituting a PLMN. It may be said that when the portions of the access network _102, the core network _202, and the DN 252 constituting a PLMN, and/or the second PDU session and/or the user plane resources constituting the second PDU session are treated as the access network _100, it may be said that the access network _100, and/or the core network _200, and/or the DN 250 are networks constituting an SNPN, or networks constituting an SNPN via a PLMN, or networks constituting an SNPN when connecting to an SNPN service via a PLMN. Furthermore, the devices and network functions included in the access network 100, the core network 200, and the DN 250 may be said to be devices and network functions that constitute an SNPN, devices and network functions that constitute an SNPN via a PLMN, or devices and network functions that constitute an SNPN when connecting to an SNPN service via a PLMN. Communication system 2 is such a communication system.

The third PDU session can also be said to be a PDU session that uses the second PDU session, or a PDU session included in the second PDU session. In this way, the third PDU session can also be said to be a PDU session that is different from normal PDU sessions (the first PDU session and the second PDU session).

Note that the access network _100 shown in dashed lines in Figure 3 is not used in communication system 2. The access network _100 is shown in dashed lines to compare communication system 2 with communication system 1.

Figure 4 also shows a detailed configuration of communication system 2 when the access network 102, core network 202, and DN 252 portions constituting the PLMN, and/or the second PDU session and/or the user plane resources constituting the second PDU session, are treated as non-3GPP access (access network 100). Figure 4 shows devices and network functions such as UE 10, AMF 210, AMF 212, SMF 220, SMF 222, UPF 230, UPF 232, N3IWF 240, N3IWF 242, DN 250, and DN 252, as well as interfaces connecting these to each other.

Hereinafter, these symbols may be omitted. Note that AMF_212, SMF_222, UPF_232, and N3IWF_242 may be included in core network_202. Furthermore, AMF_210, SMF_220, UPF_230, and N3IWF_240 may be included in core network_200. Furthermore, although not shown in Figure 4, a base station device or access point is installed between the UE and N3IWF_242. This base station device or access point may be included in access network_102.

Figure 5 also shows a detailed configuration of communication system 2 when the access network 102, core network 202, and DN 252 portions constituting the PLMN, and/or the second PDU session and/or the user plane resources constituting the second PDU session, are treated as 3GPP access (access network 100). Figure 5 shows devices and network functions such as UE 10, AMF 210, AMF 212, SMF 220, SMF 222, UPF 230, UPF 232, N3IWF 242, DN 250, DN 252, and NF 260, as well as interfaces connecting these to each other.

Hereinafter, these symbols may be omitted. Note that AMF_212, SMF_222, UPF_232, and N3IWF_242 may be included in core network_202. Furthermore, AMF_210, SMF_220, UPF_230, and NF_260 may be included in core network_200. Furthermore, although not shown in Figure 5, a base station device or access point is installed between the UE and N3IWF_242. This base station device or access point may be included in access network_102.

Here, NF_260 may be a gateway (hereinafter also referred to as an endpoint) installed in the SNPN so that the UE can connect to the SNPN service via the PLMN.

Furthermore, NF_260 may be a device/network function installed in the SNPN's core network_200. In this case, NF_260 may be an existing device/network function (e.g., AMF, SMF, UPF, etc.) installed in the core network_200, or may be a new device/network function.

In addition, NF_260 may be a device or function installed in the SNPN access network_100. In this case, a base station device installed in the access network_100 may have this function.

NF_260 may also have the function of, for example, forwarding control information and user data (non-control information) to appropriate devices and network functions. Specifically, NF_260 may have the function of forwarding control information and user data received from DN_252 to devices and network functions constituting the SNPN using a second PDU session established between the UE and DN_252, and/or the function of forwarding control information and user data received from devices and network functions constituting the SNPN to DN_252 or the second PDU session. More specifically, when NF_260 receives an MM message (e.g., a registration request message, etc.) and/or an SM message (e.g., a PDU session establishment request message, etc.) for the SNPN sent from the UE using the second PDU session from DN_252, it may have the function of forwarding the message to an apparatus/network function (e.g., AMF or SMF) that constitutes the SNPN, and/or the function of forwarding an MM message (e.g., a registration acceptance message, etc.) and/or an SM message (e.g., a PDU session establishment acceptance message, etc.) received from an apparatus/network function (e.g., AMF or SMF) that constitutes the SNPN to DN_252 or the second PDU session.

NF_260 may also have the function of performing ciphering and/or integrity protection processing on MM messages (e.g., registration request messages, etc.) and/or SM messages (e.g., PDU session establishment request messages, etc.) for the SNPN sent from the UE and received from DN_252, and/or the function of performing ciphering and/or integrity protection processing on MM messages (e.g., registration acceptance messages, etc.) and/or SM messages (e.g., PDU session establishment acceptance messages, etc.) received from devices/network functions (e.g., AMF and SMF) constituting the SNPN.

NF_260 may also have the function of determining whether the UE should connect to the SNPN service via the PLMN.

In addition, NF_260 may have a function of storing the third PDU session in association with the second PDU session when a third PDU session is established between the UE and DN_250. Specifically, when the third PDU session is established, NF_260 may have a function of forwarding user data transmitted from the UE to DN_250 when received via DN_252, and/or a function of forwarding user data received from DN_250 to DN_252.

Figure 6 also shows a communication system 3 consisting of UE_10, access network_100, core network_200, DN_250, core network_202, and DN_252.

Hereinafter, these symbols may be omitted. Also, while access network_100 in FIG. 6 may be 3GPP access or non-3GPP access, it is assumed here that it is non-3GPP access. Communication system 3 in FIG. 6 assumes that a UE connects to a PLMN service via an SNPN. Specifically, communication system 3 in FIG. 6 assumes that a UE first connects to an SNPN service via non-3GPP access, and then connects to a PLMN service via 3GPP access or non-3GPP access. More specifically, the UE first performs a registration procedure with core network_200 via non-3GPP access (access network_100) in the SNPN to enter a registered state. Then, the UE performs a PDU session establishment procedure to establish a PDU session (hereinafter referred to as the fourth PDU session) that enables communication with DN_250. Here, the fourth PDU session may be the same as the first PDU session described above. At this time, it may be said that the UE is connected to the SNPN service. Here, when the UE connects to the PLMN service via the SNPN, the access network_100, the core network_200, and the DN_250 constituting the SNPN, and/or the fourth PDU session, and/or the user plane resources constituting the fourth PDU session, may be treated as a 3GPP access or a non-3GPP access (access network_102). Then, when the UE further connects to the PLMN service via the SNPN, it performs a registration procedure with the core network_202 via the 3GPP access or the non-3GPP access to become registered, and then performs a PDU session establishment procedure to establish a PDU session (hereinafter also referred to as a fifth PDU session) and becomes capable of communicating with the DN_252. At this time, it may be said that the UE is connected to the PLMN service via the SNPN. Furthermore, it may be said that the access network_100, the core network_200, and/or the DN_250 are networks constituting the SNPN. Furthermore, the devices and network functions included in access network _100, core network _200, and DN _250 may be considered to be devices and network functions constituting an SNPN. Furthermore, if the portions of access network _100, core network _200, and DN _250 constituting an SNPN, and/or the fourth PDU session and/or the user plane resources constituting the fourth PDU session are treated as access network _102, then access network _102, core network _202, and/or DN _252 may be considered to be networks constituting a PLMN, networks constituting a PLMN via an SNPN, or networks constituting a PLMN when connecting to a PLMN service via an SNPN. Furthermore, the devices and network functions included in access network _102, core network _202, and DN _252 may be considered to be devices and network functions constituting a PLMN, devices and network functions constituting a PLMN via an SNPN, or devices and network functions constituting a PLMN when connecting to a PLMN service via an SNPN. Communication system 3 is such a communication system.

The fifth PDU session can also be said to be a PDU session that uses the fourth PDU session, or a PDU session included in the fourth PDU session. In this way, the fifth PDU session can also be said to be a PDU session that is different from a normal PDU session (the fourth PDU session).

Note that access network _102, shown in dashed lines in Figure 6, is not used in communication system 3. Access network _102 is shown in dashed lines to compare communication system 3 with communication system 2.

Figure 7 also shows a detailed configuration of communication system 3 when the access network 100, core network 200, and DN 250 that constitute the SNPN, and/or the fourth PDU session, and/or the user plane resources that constitute the fourth PDU session, are treated as non-3GPP access (access network 102). Figure 7 shows devices and network functions such as UE 10, AMF 210, AMF 212, SMF 220, SMF 222, UPF 230, UPF 232, N3IWF 240, N3IWF 242, DN 250, and DN 252, as well as interfaces that connect them to each other.

Hereinafter, these symbols may be omitted. Note that AMF_210, SMF_220, UPF_230, and N3IWF_240 may be included in core network_200. Also, AMF_212, SMF_222, UPF_232, and N3IWF_242 may be included in core network_202. Also, although not shown in Figure 7, a base station device or access point is installed between the UE and N3IWF_240. That base station device or access point may be included in access network_100.

Figure 8 also shows a detailed configuration of communication system 3 when the access network 100, core network 200, and DN 250 that constitute the SNPN, and/or the fourth PDU session, and/or the user plane resources that constitute the fourth PDU session, are treated as 3GPP access (access network 102). Figure 8 shows devices and network functions such as UE 10, AMF 210, AMF 212, SMF 220, SMF 222, UPF 230, UPF 232, N3IWF 240, DN 250, DN 252, and NF 262, as well as interfaces that connect these to each other.

Hereinafter, these symbols may be omitted. Note that AMF_210, SMF_220, UPF_230, and N3IWF_240 may be included in core network_200. Also, AMF_212, SMF_222, UPF_232, and NF_262 may be included in core network_202. Also, although not shown in Figure 8, a base station device or access point is installed between the UE and N3IWF_240. That base station device or access point may be included in access network_100.

Here, NF_262 may be a gateway (hereinafter also referred to as an endpoint) installed in the PLMN for the UE to connect to PLMN services via the SNPN.

NF_262 may be a device/network function installed in the PLMN's core network_202. In this case, NF_262 may be an existing device/network function (e.g., AMF, SMF, UPF, etc.) installed in the core network_202, or it may be a new device/network function.

NF_262 may also be a device or function installed in the PLMN access network_102. In this case, a base station device installed in the access network_102 may have this function.

NF_262 may also have the function of, for example, forwarding control information and user data (non-control information) to appropriate devices and network functions. Specifically, NF_262 may have the function of forwarding control information and user data received from DN_250 to devices and network functions constituting the PLMN using the fourth PDU session established between the UE and DN_250, and/or the function of forwarding control information and user data received from devices and network functions constituting the PLMN to DN_250 or the fourth PDU session. More specifically, when NF_262 receives an MM message (e.g., a registration request message, etc.) and/or an SM message (e.g., a PDU session establishment request message, etc.) for the PLMN sent from the UE using the fourth PDU session from DN_250, it may have the function of forwarding the message to an apparatus/network function (e.g., an AMF or SMF) constituting the PLMN, and/or the function of forwarding an MM message (e.g., a registration acceptance message, etc.) and/or an SM message (e.g., a PDU session establishment acceptance message, etc.) received from an apparatus/network function (e.g., an AMF or SMF) constituting the PLMN to DN_250 or the fourth PDU session.

NF_262 may also have the function of performing ciphering and/or integrity protection processing on MM messages (e.g., registration request messages, etc.) and/or SM messages (e.g., PDU session establishment request messages, etc.) for the PLMN sent from the UE and received from DN_250, and/or the function of performing ciphering and/or integrity protection processing on MM messages (e.g., registration acceptance messages, etc.) and/or SM messages (e.g., PDU session establishment acceptance messages, etc.) received from devices/network functions (e.g., AMF and SMF) constituting the PLMN.

NF_262 may also have the function of determining whether the UE should connect to PLMN services via the SNPN.

In addition, NF_262 may have a function to associate and store the fifth PDU session with the fourth PDU session when a fifth PDU session is established between the UE and DN_252. Specifically, when a fifth PDU session is established, NF_262 may have a function to forward user data transmitted from the UE to DN_252 when it is received via DN_250, and/or a function to forward user data received from DN_252 to DN_250.

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

A UE is a device that can connect to network services via 3GPP access (also referred to as a 3GPP access network or 3GPP AN) and/or non-3GPP access (also referred to as a non-3GPP access network or non-3GPP AN). A 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. A UE may also be equipped with a UICC (Universal Integrated Circuit Card) or eUICC (Embedded UICC). A UE may also be referred to as a user device or a terminal device.

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

In addition, one or more base station devices are deployed in the NG-RAN. These base station devices may be, for example, gNBs (gNodeBs). The gNB is a node that provides the NR (New Radio) user plane and control plane to UEs, 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 different functions from the base station device (eNB) used in EPS. Furthermore, when there are multiple gNBs, the gNBs are connected to each other, for example, via an Xn interface.

NG-RAN is sometimes referred to as 3GPP access. Non-3GPP AN is sometimes referred to as non-3GPP access. Nodes deployed in the access network are sometimes collectively referred to as NG-RAN nodes.

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

In addition, base station equipment or access points are located in the access network.

The core network also supports 5GC (5G Core Network). 5GC includes, for example, AMF, UPF, SMF, PCF, N3IWF, etc. Here, 5GC may also be expressed as 5GCN.

Furthermore, in the following, the core network and/or 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 DN, or it may be a core network for a mobile network operator that operates and manages a mobile communications system, 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 communication services to the UE. Furthermore, 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 a DN may mean connecting to a communication terminal or server device located in the DN. Furthermore, transmitting and receiving user data to and from a DN may mean transmitting and receiving user data to and from a communication terminal or server device located in the DN.

Furthermore, hereinafter, at least a portion of the access network, core network, and DN may be referred to as a network or network device. Furthermore, one or more devices included in at least a portion of the access network, core network, and DN may be referred to as a network or network device. In other words, when a network or network device sends or receives messages and/or performs a procedure, it may mean that at least a portion of the access network, core network, or DN, or one or more devices included therein, sends or receives messages and/or performs a procedure.

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 core network. In other words, the UE can send and receive (communicate) user data with the DN. When the UE sends and receives user data, it can 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 contain data sent and received by devices and functions included in EPS and devices and functions included in 5GS.

Non-IP communication refers to 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 achieved by sending and receiving application data without an IP header, or it may be user data sent and received by a 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, as logical (virtual) hardware configured on general-purpose hardware, or 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.

Note that each memory unit (memory unit_340, memory unit_540, memory unit_740) in each device/function mentioned below is composed of, for example, semiconductor memory, SSD (Solid State Drive), HDD (Hard Disk Drive), etc. Furthermore, each memory unit can store not only information that was originally set at the time of shipment, but also various information sent and received between devices/functions other than the device/function itself (e.g., UE, and/or access network device, and/or core network device, and/or PDN, and/or DN). Furthermore, each memory unit can store identification information, control information, flags, parameters, etc. contained in control messages sent and received within the various communication procedures described below. Furthermore, each memory unit may store this information for each UE.

[2.1. UE Device Configuration]
First, an example of the device configuration of UE (User Equipment) will be explained using Figure 9. The UE is composed of a control unit 300, an antenna 310, a transceiver unit 320, and a memory unit 340. The control unit 300, the transceiver unit 320, and the memory unit 340 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. Furthermore, 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 _340). The control unit _300 realizes various processes in the UE by reading and executing various programs stored in the memory unit _340 as necessary.

The transceiver unit _320 is a functional unit for wireless communication with base station devices, etc. 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 core network device, and/or PDN, and/or DN.

The UE can also communicate with a base station device (gNB) within the 5G AN by using the transceiver unit 320. The UE can also send and receive AMF and NAS (Non-Access-Stratum) messages via the N1 interface by using the transceiver unit 320.

The memory unit _340 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UE. The memory unit _340 may also have the function of storing control information transmitted and received between the access network device, core network device, and DN.

[2.2. gNB (base station equipment) and access point equipment configuration]
Next, an example of the gNB device configuration will be described using Figure 10. The gNB is composed of a control unit _500, an antenna _510, a network connection unit _520, a transceiver unit _530, and a memory unit _540. The control unit _500, the network connection unit _520, the transceiver unit _530, and the memory unit _540 are connected via a bus. The transceiver unit _530 is connected to the antenna _510.

The control unit _500 is a functional unit that controls the operation and functions of the entire gNB. Furthermore, the control unit _500 may process all functions that are not possessed by other functional units in the base station device (network connection unit _520, transceiver unit _530, memory unit _540). The control unit _500 realizes various processes in the gNB 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 gNB to communicate with the AMF and/or UPF. That is, the gNB can send and receive user data and/or control information between the AMF and/or UPF using the network connection unit _520.

The transceiver unit _530 is a functional unit for wireless communication with the UE via the antenna _510. That is, the gNB can transmit and receive user data and/or control information to and from the UE using the transceiver unit _530.

A gNB in a 5G AN can communicate with the AMF via the N2 interface by using the network connection unit _520, and can communicate with the UPF via the N3 interface. The gNB can also communicate with the UE by using the transceiver unit _530.

The memory unit _540 is a functional unit for storing programs, user data, control information, etc. necessary for each operation of the gNB. The memory unit _540 may also have the function of storing control information transmitted and received between the UE, other access network devices (base station devices), core network devices, and DNs.

Furthermore, the access point can have the same device configuration as the gNB.

[2.3. AMF device configuration]
Next, an example of the device configuration of the AMF will be explained using Figure 11. The AMF is composed of a control unit _700, a network connection unit _720, and a memory unit _740. The control unit _700, the network connection unit _720, and the memory unit _740 are connected via a bus. The AMF may be a node that handles the control plane (also called C-plane).

The control unit _700 is a functional unit that controls the operation and functions of the entire AMF. Furthermore, the control unit _700 may process all functions that other functional units in the AMF (network connection unit _720, memory unit _740) do not have. The control unit _700 realizes various processes in the AMF by reading and executing various programs stored in the memory unit _740 as necessary.

The network connection unit _720 is a functional unit for the AMF to connect to a base station device, and/or an N3IWF, and/or other AMFs, and/or an SMF, and/or a PCF, and/or an NSSF (Network Slice Selection Function), and/or an UDM (Unified Data Management), and/or an SCEF. In other words, the AMF can use the network connection unit _720 to send and receive user data and/or control information between the base station device, and/or an N3IWF, and/or other AMFs, and/or an SMF, and/or a PCF, and/or an NSSF, and/or an UDM, and/or an SCEF.

By using the network connection unit _720, the AMF in the 5GCN can communicate with a base station device or N3IWF via the N2 interface, with other AMFs via the N14 interface, with the SMF via the N11 interface, with the PCF via the N15 interface, with the NSSF via the N22 interface, and with the UDM via the N8 interface. Furthermore, by using the network connection unit _720, the AMF can send and receive NAS messages with the UE via the N1 interface. 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 _740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the AMF. The memory unit _740 may also have the function of storing control information transmitted and received between the UE, access network devices, other core network devices, and DN.

The AMF has functions such as exchanging control messages with the RAN using the N2 interface, exchanging NAS messages with the UE using the N1 interface, encrypting and protecting the integrity of NAS messages, registration management (RM), connection management (CM), reachability management, mobility management for UEs, etc., transferring SM (Session Management) messages between the UE and SMF, access authentication (Access Authorization), security anchor functionality (SEA), security context management (SCM), supporting the N2 interface to the N3IWF (Non-3GPP Interworking Function), supporting the sending and receiving of NAS signals with the UE via the N3IWF, and authenticating UEs connected via the N3IWF.

In addition, registration management manages the RM state for each UE. The RM state may be synchronized between the UE and AMF. RM states include the unregistered state (RM-DEREGISTERED state) and the registered state (RM-REGISTERED state). In the RM-DEREGISTERED state, the UE is not registered with 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 with the network, so the UE can receive services that require registration with the network. The RM state may also 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, 5GMM-REGISTERED may mean that each device has established a 5GMM context, or that each device has established a PDU session context. When each device is 5GMM-REGISTERED, the UE may start sending and receiving user data and control messages, or may respond to paging. Furthermore, when each device is 5GMM-REGISTERED, the UE may perform registration procedures other than the registration procedure for initial registration, and/or service request procedures.

Furthermore, 5GMM-DEREGISTERED may mean that each device has not established a 5GMM context, that the UE's location information is not known to the network, or that the UE is unreachable by the network. Note that when each device is 5GMM-DEREGISTERED, the UE may initiate a registration procedure or establish a 5GMM context by performing the registration procedure.

Connection management also manages the CM state for each UE. The CM state may be synchronized between the UE and the AMF. CM states include 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 or an N3 interface 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 and/or an N3 interface connection.

Furthermore, connection management may be performed separately for the CM state in 3GPP access and the CM state in non-3GPP access. In this case, the CM state in 3GPP access may include 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 include 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). Note that the non-connected state may be expressed as idle mode, and the connected state mode may be expressed as connected mode.

The CM state may also be expressed as 5GMM mode. In this case, the unconnected state may also be expressed as 5GMM-IDLE mode, and the connected state may also be expressed as 5GMM-CONNECTED mode. Furthermore, the unconnected state in 3GPP access may also be expressed as 5GMM-IDLE mode over 3GPP access, and the connected state in 3GPP access may also be expressed as 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 the core network. In addition, an AMF may be an NF (Network Function) 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 among multiple NSIs.

Note that the N3IWF is a device and/or function located between the non-3GPP access and the 5GCN when the UE connects to the 5GS via the non-3GPP access. It is preferable that the N3IWF be located in the core network.

[2.4. SMF device configuration]
Next, an example of the device configuration of the SMF will be explained using Figure 11. The SMF is composed of a control unit 700, a network connection unit 720, and a memory unit 740. The control unit 700, the network connection unit 720, and the memory unit 740 are connected via a bus. The SMF may be a node that handles the control plane.

The control unit _700 is a functional unit that controls the operation and functions of the entire SMF. Furthermore, the control unit _500 may process all functions that other functional units in the SMF (network connection unit _720, memory unit _740) do not have. The control unit _700 realizes various processes in the SMF by reading and executing various programs stored in the memory unit _740 as needed.

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

By using the network connection unit _720, the SMF within the 5GCN can communicate with the AMF via the N11 interface, with the UPF via the N4 interface, with the PCF via the N7 interface, and with the UDM via the N10 interface.

The memory unit _740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the SMF. The memory unit _740 may also have the function of storing control information transmitted and received between the UE, access network devices, other core network devices, and DN.

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

[2.5. UPF device configuration]
Next, an example of the device configuration of the UPF will be explained using Figure 11. The UPF is composed of a control unit _700, a network connection unit _720, and a memory unit _740. The control unit _700, the network connection unit _720, and the memory unit _740 are connected via a bus. The UPF may be a node that handles the control plane.

The control unit _700 is a functional unit that controls the operation and functions of the entire UPF. Furthermore, the control unit _700 may process all functions that other functional units in the AMF (network connection unit _720, memory unit _740) do not have. The control unit _700 realizes various processes in the UPF by reading and executing various programs stored in the memory unit _740 as needed.

The network connection unit _720 is a functional unit that enables the UPF to connect to a base station device (gNB), and/or SMF, and/or DN within a 5G AN. In other words, the UPF can use the network connection unit _720 to send and receive user data and/or control information between a base station device, and/or N3IWF, and/or SMF, and/or DN, and/or other UPFs.

By using the network connection unit _720, a UPF within a 5GCN can communicate with a base station device or N3IWF via the N3 interface, with an SMF via the N4 interface, with a DN via the N6 interface, and with other UPFs via the N9 interface.

The memory unit _740 is a functional unit for storing programs, user data, control information, etc. required for each operation of the UPF. The memory unit _740 may also have the function of storing control information transmitted and received between the UE, access network devices, other core network devices, and DN.

The UPF functions as an anchor point for intra-RAT or inter-RAT mobility, as an external PDU session point for interconnecting to DNs (i.e., as a gateway between the DN and the core network, forwarding user data), as a packet routing and forwarding function, as a UL CL (Uplink Classifier) function that supports routing of multiple traffic flows to one DN, as a branching point that supports multi-homed PDU sessions, as a QoS (Quality of Service) processing function for the user plane, as a function for verifying uplink traffic, as a function for buffering downlink packets, and as a function for triggering downlink data notifications.

The UPF may also be a gateway for IP communications and/or non-IP communications. The UPF may also have the function of forwarding IP communications and the function of converting non-IP communications to IP communications. 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 refers to user data transmitted and received between the UE and the network. The user plane may be transmitted and received using a PDN connection or a PDU session. Furthermore, in the case of EPS, the user plane may be transmitted and received using the LTE-Uu interface, and/or the S1-U interface, and/or the S5 interface, and/or the S8 interface, and/or the SGi interface. 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. Hereinafter, the user plane may be referred to as the U-Plane.

Furthermore, the control plane refers to control messages sent and received to control UE communications, etc. The control plane may be sent and received using the NAS (Non-Access-Stratum) signaling connection between the UE and MME. Furthermore, in the case of EPS, the control plane may be sent and received using the LTE-Uu interface and the S1-MME interface. Furthermore, in the case of 5GS, the control plane may be sent and received using the interface between the UE and NG RAN and the N2 interface. Hereinafter, the control plane may be referred to as the control plane or the C-Plane.

Furthermore, the U-Plane (User Plane; UP) may be a communication path for sending and receiving user data and may be composed of multiple bearers.Furthermore, the C-Plane (Control Plane; CP) may be a communication path for sending and receiving control messages and may be composed of multiple bearers.

[2.6. N3IWF device configuration]
Next, an example of the device/functional configuration of the N3IWF used in each embodiment will be described using Figure 11. The N3IWF is placed in the core network when the UE connects to 5GS via non-3GPP access (Untrusted non-3GPP Access). The N3IWF is composed of a control unit 700, a network connection unit 720, and a memory unit 740. The control unit 700, the network connection unit 720, and the memory unit 740 are connected via a bus.

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

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

In other words, by using the network connection unit _720, the N3IWF can communicate with a base station device or an access point via the Y2 interface. 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 it goes without saying that the N3IWF can communicate with devices/functions other than those listed above, i.e., core network devices other than those listed above.

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

The N3IWF has the following functions: 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 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 UPF (including encapsulating/decapsulating packets for IPsec and N3 tunnels), acting as a local mobility anchor in an untrusted non-3GPP access network, and selecting an AMF. All of these functions are controlled by the control unit 700.

In addition, NF_260 can have the same device configuration as N3IWF, except that the access used is 3GPP access.

[2.7. Description of other devices and/or functions and identification information in this embodiment]
Next, other devices and/or functions and identification information will be described.

A network refers to at least a portion of an access network, a core network, or a DN. Furthermore, one or more devices included in at least a portion of an access network, a core network, or 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 the network transmits, receives, receives, and/or processes messages, it may mean that the network transmits, receives, receives, and/or processes messages.

In addition, an NSSF (Network Slice Selection Function) may be a network function (also referred to as an NF) that has the function of selecting a network slice to serve a UE.

In addition, an NWDAF (Network Data Analytics Function) may be an NF that has the function of collecting data from NFs and application functions (also referred to as AFs).

In addition, a PCF (Policy Control Function) may be an NF that has the function of determining policies for controlling network behavior.

An NRF (Network Repository Function) may be an NF with a service discovery function. An NRF may be an NF with the function of providing information about the discovered NF when it receives a discovery request for another NF from another NF.

SM (Session Management) messages (also referred to as NAS (Non-Access-Stratum) SM messages) may be NAS messages used in SM procedures and may be control messages transmitted and received between the UE and the SMF via the AMF. SM messages may also include PDU session establishment request messages, PDU session establishment accept messages, PDU session establishment reject messages, PDU session modification request messages, PDU session modification command messages, PDU session modification complete messages, PDU session modification command reject messages, PDU session modification reject messages, PDU session release request messages, PDU session release reject messages, PDU session release command messages, and PDU session release complete messages.

In addition, the procedures for SM or SM procedures may include a PDU session establishment procedure, a PDU session modification procedure, and a UE-requested PDU session release procedure. Each procedure may be initiated by the UE or the network.

Furthermore, an MM (Mobility management) message (also referred to as a NAS MM message) may be a NAS message used in procedures for MM, or may be a control message transmitted and received between UE10 and AMF. Furthermore, MM messages may include a registration request message, a registration accept message, a registration reject message, a de-registration request message, a de-registration accept message, a configuration update command message, a configuration update complete message, a service request message, a service accept message, a service reject message, a notification message, a notification response message, etc.

Furthermore, the procedures for MM or MM procedures may include a registration procedure, a de-registration procedure, a generic UE configuration update procedure, an authentication and authorization procedure, a service request procedure, a paging procedure, and a notification procedure.

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

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

The PDN (Packet Data Network) type indicates the type of PDN connection, and can be IPv4, IPv6, IPv4v6, or non-IP. If IPv4 is specified, it indicates that data will be sent and received using IPv4. If IPv6 is specified, it indicates that data will be sent and received using IPv6. If IPv4v6 is specified, it indicates that data will be sent and received using either IPv4 or IPv6. If non-IP is specified, it indicates that communication will not be via IP, but rather via a communication method other than IP.

A PDU (Protocol Data Unit/Packet Data Unit) session can be defined as an association between a DN that provides PDU connectivity services and a UE, but it may also be connectivity established between a UE and an external gateway. In 5GS, a UE can transmit and receive user data to and from a DN using a PDU session by establishing a PDU session via the access network and core network. Here, this external gateway may be a UPF, SCEF, etc. The UE can use the PDU session to transmit and receive user data to and from devices such as an application server located in the DN.

In addition, each device (UE, and/or access network device, and/or core network device) may associate one or more identification information with a PDU session and manage it.In addition, this identification information may include one or more of the DNN, QoS rule, PDU session type, application identification information, NSI identification information, and access network identification information, or may further include other information.Furthermore, when multiple PDU sessions are established, each identification information associated with a PDU session may be the same or different.

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 PGW/UPF that connects the core network. Furthermore, the DNN may be equivalent to an APN (Access Point Name).

The PDU (Protocol Data Unit/Packet Data Unit) session type indicates the type of PDU session, and can be IPv4, IPv6, Ethernet, or Unstructured. If IPv4 is specified, it indicates that data will be sent and received using IPv4. If IPv6 is specified, it indicates that data will be sent and received using IPv6. If Ethernet is specified, it indicates that Ethernet frames will be sent and received. Ethernet may also indicate that communication using IP is not performed. If Unstructured is specified, it indicates that data will be sent and received to an application server or the like in the DN using Point-to-Point (P2P) tunneling technology. As a 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 if the UE is capable of using both IPv4 and IPv6.

A PLMN (Public Land Mobile Network) is a communication network that provides mobile wireless communication services. A PLMN is a network managed by an operator, which is a telecommunications carrier, and the operator can be identified by a PLMN ID. A PLMN that matches the MCC (Mobile Country Code) and MNC (Mobile Network Code) of the UE's IMSI (International Mobile Subscriber Identity) may be the Home PLMN (HPLMN). Furthermore, the UE may store an Equivalent HPLMN list in the USIM to identify one or more Equivalent HPLMNs (EPLMNs). A PLMN different from the HPLMN and/or EPLMN may be a Visited PLMN (VPLMN). A PLMN to which the UE has successfully registered may be a Registered PLMN (RPLMN). Note that services provided by a PLMN may be referred to as PLMN services, and services provided by an SNPN may be referred to as SNPN services.

An SNPN is a type of NPN that is a 5GS service deployed for non-public use. It is operated by an NPN operator and is independent of the NF provided by the PLMN. An SNPN is identified by a combination of a PLMN ID and an NID (Network Identifier). A UE capable of using an SNPN may support the SNPN access mode. A UE configured to operate in the SNPN access mode may be able to select and register with an SNPN, but may not be able to select a PLMN. A UE configured to operate in the SNPN access mode may be able to perform an SNPN selection procedure, but may not be able to perform a PLMN selection procedure. Even if a UE is enabled for an SNPN (SNPN), a UE not configured to operate in the SNPN access mode may not be able to select and register with an SNPN, but may be able to select a PLMN. A UE not configured to operate in the SNPN access mode may not be able to perform an SNPN selection procedure, but may be able to perform a PLMN selection procedure.

Also, a UE operating in SNPN access mode may be able to select an SNPN via Uu (3GPP access). Also, a UE operating in SNPN access mode may be able to select an SNPN via Uu or NWu established via a PDU session provided by a selected PLMN via Uu or NWu (non-3GPP access). Also, a UE not operating in SNPN access mode may be able to select a PLMN via Uu or NWu established via a PDU session provided by a selected SNPN via Uu or NWu (non-3GPP access).

The SNPN access mode may be managed and applied on an access basis. That is, it may be managed and applied separately for 3GPP access and non-3GPP access. In other words, activation or deactivation of the SNPN access mode for 3GPP access may be independent of activation or deactivation of the SNPN access mode for non-3GPP access. That is, when the SNPN access mode for 3GPP access is activated, the SNPN access mode for non-3GPP access may be activated or deactivated. Furthermore, when the SNPN access mode for 3GPP access is deactivated, the SNPN access mode for non-3GPP access may be activated or deactivated.

Here, SNPN access mode for 3GPP access may also be referred to as SNPN access mode over 3GPP access or SNPN access mode via 3GPP access.

In addition, SNPN access mode for non-3GPP access may also be referred to as SNPN access mode over non-3GPP access or SNPN access mode via non-3GPP access.

Also, "activated" may be read as "to operate," and "deactivated" may be read as "not to operate." In other words, activating the SNPN access mode for 3GPP access may mean operating in the SNPN access mode for 3GPP access. Deactivating the SNPN access mode for 3GPP access may mean not operating in the SNPN access mode for 3GPP access. Activating the SNPN access mode for non-3GPP access may mean operating in the SNPN access mode for non-3GPP access. Deactivating the SNPN access mode for non-3GPP access may mean not operating in the SNPN access mode for non-3GPP access.

In addition, the SNPN access mode state in the UE may be one of the following states 1 to 9.

Here, the first state is a state in which the UE does not operate in SNPN access mode.

The second state is a state in which the UE operates in SNPN access mode.

The third state is a state in which the device does not operate in SNPN access mode on 3GPP access and does not operate in SNPN access mode on non-3GPP access.

The fourth state is a state in which the device does not operate in SNPN access mode on 3GPP access, but operates in SNPN access mode on non-3GPP access.

The fifth state is a state in which the device operates in SNPN access mode on 3GPP access and does not operate in SNPN access mode on non-3GPP access.

The sixth state is a state in which the device operates in SNPN access mode on 3GPP access and in SNPN access mode on non-3GPP access.

The seventh state is a state in which the device operates in SNPN access mode when connecting to an SNPN service, and does not operate in SNPN access mode when connecting to a PLMN service.

The eighth state is a state in which, when connected to an SNPN via non-3GPP access and also connected to a PLMN via non-3GPP access, the SNPN operates in SNPN access mode but does not operate in SNPN access mode for the PLMN. The eighth state may also be a state in which, when connected to an SNPN via 3GPP access and also connected to a PLMN via 3GPP access, the SNPN operates in SNPN access mode but does not operate in SNPN access mode for the PLMN.

The ninth state refers to a state in which, when connected to a PLMN via non-3GPP access and also connected to an SNPN via non-3GPP access, the device does not operate in SNPN access mode for the PLMN but operates in SNPN access mode for the SNPN. The ninth state may also refer to a state in which, when connected to a PLMN via 3GPP access and also connected to an SNPN via 3GPP access, the device does not operate in SNPN access mode for the PLMN but operates in SNPN access mode for the SNPN.

The first, second, seventh, eighth, and ninth states may be states that are applied when the SNPN access mode is not managed on an access-by-access basis. The third, fourth, fifth, and sixth states may be states that are applied when the SNPN access mode is managed on an access-by-access basis. The seventh and eighth states may be states that are applied when connecting to a PLMN service via an SNPN. The seventh and ninth states may be states that are applied when connecting to an SNPN service via a PLMN.

A network slice (NS) is a logical network that provides specific network capabilities and network characteristics. UEs and/or networks can support network slices (NW slices; NS) in 5GS. Network slices are sometimes simply referred to as slices.

A network slice instance (NSI) is composed of an instance (entity) of a network function (NF) and a set of required resources, forming a deployed network slice. Here, an NF is a processing function in a network adopted or defined by 3GPP. An NSI is an entity of one or more NSs configured within a core network. An NSI may also be composed of virtual NFs (Network Functions) generated using an NST (Network Slice Template). Here, an NST is associated with resource requirements for providing the required communication services and capabilities and is a logical representation of one or more NFs. In other words, an NSI may be a collection within a core network composed of multiple NFs. An NSI may also be a logical network configured to separate user data delivered by services, etc. One or more NFs may be configured in an NS. The NFs configured in an NS may or may not be devices shared with other NSs. A UE and/or a device in the network can 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 APNs. The UE usage type is a parameter value included in the UE registration information and 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 consist of only SST (Slice/Service type), or may consist of both SST and SD (Slice Differentiator). Here, SST is information indicating the expected behavior of the NS in terms of functions and services. SD may also be information that interpolates the SST when selecting one NSI from multiple NSIs indicated by the SST. S-NSSAI may be information specific to each PLMN, or may be standard information common among PLMNs. The network may also store one or more S-NSSAIs in the UE's registration information as default S-NSSAIs. If the S-NSSAI is the default S-NSSAI, and the UE does not send a valid S-NSSAI to the network in a registration request message, the network may provide the NS related to the UE.

Also, NSSAI (Network Slice Selection Assistance Information) is a collection of S-NSSAI. Each S-NSSAI included in 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. Also, NSSAI may be information used to select an AMF.

Also, the configured NSSAI (also referred to as the configured NSSAI) is an NSSAI that is provided and stored in the UE. The UE may store the configured NSSAI for each PLMN. The configured NSSAI may be information configured by the network (or PLMN). The S-NSSAI included in the configured NSSAI may be expressed as the configured S-NSSAI. The configured S-NSSAI may be configured to include an S-NSSAI and a mapped S-NSSAI.

The requested NSSAI (also referred to as the requested NSSAI) is the NSSAI provided by the UE to the network during the registration procedure. The requested NSSAI may be the allowed NSSAI or the configured NSSAI stored by the UE. Specifically, the requested NSSAI may be information indicating the network slice that the UE wants to access. The S-NSSAI included in the requested NSSAI may be expressed as the requested S-NSSAI. For example, the requested NSSAI is transmitted in an NAS message or an RRC (Radio Resource Control) message including a NAS (Non-Access-Stratum) message transmitted from the UE to the network, such as a registration request message or a PDU session establishment request message.

Also, the allowed NSSAI (also referred to as the permitted NSSAI or Allowed NSSAI) is information indicating one or more network slices to which the UE is allowed. In other words, the allowed NSSAI is information that identifies the network slice to which the network has allowed the UE to connect. The UE and the network each store and manage the allowed NSSAI for each access (3GPP access or non-3GPP access) as UE information. The S-NSSAI included in the allowed NSSAI may be expressed as the allowed S-NSSAI. The allowed S-NSSAI may be composed of an S-NSSAI and a mapped S-NSSAI.

Furthermore, a mapped S-NSSAI (also referred to as a mapped S-NSSAI) is an S-NSSAI of an HPLMN mapped to an S-NSSAI of a registered PLMN in a roaming scenario. The UE may store one or more mapped S-NSSAIs mapped to the configured NSSAI and the S-NSSAI included in the Allowed NSSAI for each access type. Furthermore, the UE may store one or more mapped S-NSSAIs for the S-NSSAI included in the rejected NSSAI.

Furthermore, a rejected NSSAI (also referred to as a rejected NSSAI) is information indicating one or more network slices to which the UE is not permitted to connect. In other words, a rejected NSSAI is information identifying a network slice to which the network does not permit the UE to connect. A rejected NSSAI may be information including one or more combinations of an S-NSSAI and a rejection reason value. Here, the rejection reason value is information indicating the reason why the network rejects the corresponding S-NSSAI. The UE and the network may store and manage the rejected NSSAI appropriately based on the rejection reason value associated with each S-NSSAI. Furthermore, the rejected NSSAI may be included in an NAS message sent from the network to the UE, such as a registration accept message, a configuration update command, or a registration rejection message, or in an RRC message including an NAS message. An S-NSSAI included in a rejected NSSAI may be expressed as a rejected S-NSSAI. The rejected NSSAI may be any one of the first to third rejected NSSAIs, a pending NSSAI, or a combination of these. An S-NSSAI included in a rejected NSSAI may be expressed as a rejected S-NSSAI. The rejected S-NSSAI may be configured to include an S-NSSAI and a mapped S-NSSAI.

Here, the first rejected NSSAI is a set of one or more S-NSSAIs that the UE included in the requested NSSAI and that are unavailable in the current PLMN. The first rejected NSSAI may be a 5GS rejected NSSAI for the current PLMN, a rejected S-NSSAI for the current PLMN, or an S-NSSAI included in the rejected NSSAI for the current PLMN. The first rejected NSSAI may be a rejected NSSAI stored by the UE or the NW, or may be a rejected NSSAI sent from the NW to the UE. If the first rejected NSSAI is a rejected NSSAI sent from the NW to the UE, the first rejected NSSAI may be information that includes one or more combinations of an S-NSSAI and a reason value. The rejection reason value at this time may be "S-NSSAI is not available in the current PLMN" or may be information indicating that the S-NSSAI associated with the rejection reason value is not available in the current PLMN.

Furthermore, the first rejected NSSAI is valid for the entire registered PLMN. In other words, the UE and/or NW may treat the first rejected NSSAI and the S-NSSAI included in the first rejected NSSAI as information independent of the access type. In other words, the first rejected NSSAI may be information valid for both 3GPP access and non-3GPP access.

The UE may delete the first rejected NSSAI from its memory if it transitions to an unregistered state for the current PLMN in both 3GPP access and non-3GPP access. In other words, if the UE transitions to an unregistered state for the current PLMN via one access, or if it successfully registers to a new PLMN via one access, or if it fails to register to the new PLMN via one access and transitions to an unregistered state, and if the UE is not registered (unregistered) via the other access, the UE deletes the first rejected NSSAI.

The second rejected NSSAI is a set of one or more S-NSSAIs that the UE included in the requested NSSAI are not available in the current registration area. The second rejected NSSAI may be a 5GS rejected NSSAI for the current registration area. The second rejected NSSAI may be a rejected NSSAI stored by the UE or the NW, or may be a rejected NSSAI transmitted from the NW to the UE. If the second rejected NSSAI is a rejected NSSAI transmitted from the NW to the UE, the second rejected NSSAI may be information including one or more combinations of an S-NSSAI and a reason value. In this case, the reason value may be "S-NSSAI is not available in the current registration area" or may be information indicating that the S-NSSAI associated with the reason value is not available in the current registration area.

Furthermore, the second rejected NSSAI is valid within the current registration area. That is, the UE and/or NW may treat the second rejected NSSAI and the S-NSSAI included in the second rejected NSSAI as information for each access type. That is, the second rejected NSSAI may be information valid for either 3GPP access or non-3GPP access. That is, the UE may delete the second rejected NSSAI from its memory once it transitions to an unregistered state for a certain access.

The third rejected NSSAI is a set of one or more S-NSSAIs that require an NSSAA and for which the NSSAA for that S-NSSAI has failed or been revoked. The third rejected NSSAI may be an NSSAI stored by the UE and/or NW, or may be transmitted from the NW to the UE. When the third rejected NSSAI is transmitted from the NW to the UE, the third rejected NSSAI may be information that includes one or more combinations of an S-NSSAI and a rejection reason value. In this case, the rejection reason value may be "S-NSSAI is not available due to the failed or revoked network slice-specific authorization and authentication" or may be information indicating that the NSSAA for the S-NSSAI associated with the rejection reason value has failed or been revoked.

The third rejected NSSAI is also valid across the entire registered PLMN. In other words, the UE and/or NW may treat the third rejected NSSAI and the S-NSSAI included in the third rejected NSSAI as information independent of the access type. In other words, the third rejected NSSAI may be information valid for 3GPP access and non-3GPP access. The third rejected NSSAI may be an NSSAI different from the rejected NSSAI. The third rejected NSSAI may be the first rejected NSSAI.

The third rejected NSSAI is a rejected NSSAI that identifies a slice that the UE has rejected due to an NSSAA failure or cancellation from the core network. Specifically, while the UE stores the third rejected NSSAI, it does not initiate a registration request procedure for the S-NSSAI included in the third rejected NSSAI. The third rejected NSSAI may be identification information including one or more S-NSSAIs received from the core network in association with a rejection reason value indicating an NSSAA failure. The third rejected NSSAI is information independent of the access type. Specifically, when the UE stores the third rejected NSSAI, the UE may not attempt to send a registration request message including the S-NSSAI included in the third rejected NSSAI to both 3GPP access and non-3GPP access. Alternatively, the UE may send a registration request message including the S-NSSAI included in the third rejected NSSAI based on UE policy. Alternatively, the UE may delete the third rejected NSSAI based on the UE policy and transition to a state in which it can transmit a registration request message including an S-NSSAI included in the third rejected NSSAI. In other words, when the UE transmits a registration request message including an S-NSSAI included in the third rejected NSSAI based on the UE policy, the UE may delete the S-NSSAI from the third rejected NSSAI.

A pending NSSAI (also referred to as a Pending NSSAI) is a collection of one or more S-NSSAIs that are S-NSSAIs for which the network requires network slice specific authentication, for which network slice specific authentication has not been completed, and which cannot be used in the current PLMN. A pending NSSAI may be a 5GS Rejected NSSAI due to NSSAA or a pending NSSAI. A pending NSSAI may be an NSSAI stored by the UE or NW, or an NSSAI sent from the NW to the UE. Note that a pending NSSAI is not limited to a rejected NSSAI, and may be an NSSAI independent of the rejected NSSAI. When a pending NSSAI is an NSSAI sent from the NW to the UE, the pending NSSAI may be information that includes one or more combinations of an S-NSSAI and a rejection reason value. The rejection reason value at this time may be "NSSAA is pending for the S-NSSAI" and may be information indicating that the S-NSSAI associated with the rejection reason value is prohibited or pending use by the UE until the NSSAA for that S-NSSAI is completed.

The pending NSSAI is also valid across the entire registered PLMN. In other words, the UE and/or NW may treat the third rejected NSSAI and the S-NSSAI included in the pending NSSAI as information independent of the access type. In other words, the pending NSSAI may be information valid for both 3GPP access and non-3GPP access. The pending NSSAI may be an NSSAI different from the rejected NSSAI. The pending NSSAI may also be the first rejected NSSAI.

The pending NSSAI is an NSSAI consisting of one or more S-NSSAIs that identify slices for which the UE is pending a procedure. Specifically, while the UE stores the pending NSSAI, it does not initiate a registration request procedure for the S-NSSAI included in the pending NSSAI. In other words, the UE does not use the S-NSSAI included in the pending NSSAI during the registration procedure until the NSSAA for the S-NSSAI included in the pending NSSAI is completed. The pending NSSAI is identification information that includes one or more S-NSSAIs received from the core network in association with a rejection reason value indicating pending for the NSSAA. The pending NSSAI is information that is independent of the access type. Specifically, when the UE stores the pending NSSAI, the UE does not attempt to send a registration request message including the S-NSSAI included in the pending NSSAI to both 3GPP access and non-3GPP access.

A tracking area is a single or multiple ranges managed by the core network that can be represented by the UE's location information. A tracking area may consist of multiple cells. Furthermore, a tracking area may be an area in which control messages such as paging are broadcast, or an area in which a UE can move without performing a handover procedure. Furthermore, a tracking area may be a routing area, a location area, or anything similar. Hereinafter, a tracking area may be a TA (Tracking Area). A tracking area may be identified by a TAI (Tracking Area Identity) consisting of a TAC (Tracking area code) and a PLMN.

A registration area is a collection of one or more TAs assigned to a UE by the AMF. Note that while a UE is moving within one or more TAs included in the registration area, it may be able to move without sending or receiving signals for tracking area updates. In other words, a registration area may be a group of information indicating areas in which a UE can move without performing a tracking area update procedure. A registration area may be identified by a TAI list consisting of one or more TAIs.

UE ID is information for identifying a UE. Specifically, for example, UE ID may be SUCI (Subscription Concealed Identifier), or SUPI (Subscription Permanent Identifier), or GUTI (Globally Unique Temporary Identifier), or IMEI (International Mobile Subscriber Identity), or IMEISV (IMEI Software Version), or TMSI (Temporary Mobile Subscriber Identity). Alternatively, UE ID may be other information set within an application or network. Furthermore, UE ID may be information for identifying a user.

Network Slice-Specific Authentication and Authorization (NSSAA) is a function for realizing network slice-specific authentication and authorization. Network slice-specific authentication and authorization allows UE authentication and authorization to be performed outside the core network, such as by a third party. PLMNs and network devices with NSSAA functionality can perform NSSAA procedures for a certain S-NSSAI based on the UE's registration information. Furthermore, UEs with NSSAA functionality can manage and store rejected NSSAIs pending for NSSAA and/or rejected NSSAIs due to NSSAA failure. In this document, NSSAA may be referred to as the network slice-specific authentication and authorization procedure or the authentication and authorization procedure.

An S-NSSAI requiring NSSAA is an S-NSSAI requiring NSSAA that is managed by the core network and/or core network device. The core network and/or core network device may store an S-NSSAI requiring NSSAA by associating the S-NSSAI with information indicating whether or not an NSSAA is required. The core network and/or core network device may further store an S-NSSAI requiring NSSAA in association with information indicating whether or not the NSSAA has been completed, or information indicating that the NSSAA has been completed and is in an allowed or successful state. The core network and/or core network device may manage an S-NSSAI requiring NSSAA as information unrelated to the access network.

Furthermore, the Uu interface (hereinafter also referred to as Uu) may refer to the interface between a UE and a 3GPP access or a base station device installed in the 3GPP access. In this specification, Uu may be used synonymously with 3GPP access. Furthermore, the NWu interface (hereinafter also simply referred to as NWu) may refer to the interface between an N3IWF and a UE. In this specification, NWu may be used synonymously with non-3GPP access.

Next, we will explain the identification information that is sent, received, stored, and managed by each device in this embodiment.

First, the first identification information is UE capability information. The first identification information may be 5GMM capability. The first identification information may also indicate whether the UE supports a certain function. The first identification information may also indicate whether the UE supports connecting to a PLMN service via an SNPN. The first identification information may also indicate whether the UE supports connecting to an SNPN service via a PLMN.

The second identification information may also be a Requested NSSAI. The second identification information may be composed of one or more requested S-NSSAIs. The second identification information may also indicate an S-NSSAI that can connect to an SNPN. The second identification information may also indicate an S-NSSAI that can connect to a PLMN. The second identification information may also indicate an S-NSSAI that can connect to an SNPN service via a PLMN. The second identification information may also indicate an S-NSSAI that can connect to a PLMN service via an SNPN.

The third identification information is also the type of registration requested. The third identification information may be a 5GS registration type. The third identification information may also indicate initial registration, mobility registration updating, periodic registration updating, emergency registration, or registration to a PLMN via an SNPN.

Furthermore, the fourth identification information is identification information that includes at least two of the first to third identification information.

Furthermore, the 11th identification information is network capability information. The 11th identification information may be 5GS network feature support. Further, the 11th identification information may indicate whether the network supports a certain function. Further, the first identification information may indicate whether the network supports connecting to a PLMN service via an SNPN. Further, the first identification information may indicate whether the network supports connecting to an SNPN service via a PLMN.

Furthermore, the 12th identification information is an Allowed NSSAI. The 12th identification information may consist of one or more S-NSSAIs.

The 13th identification information is a Rejected NSSAI. The 13th identification information may consist of one or more S-NSSAIs.

Furthermore, the 14th identification information is a Configured NSSAI. The 14th identification information may be composed of one or more S-NSSAIs.

Furthermore, the 15th identification information is a Pending NSSAI. The 15th identification information may consist of one or more S-NSSAIs.

Furthermore, the 16th identification information is identification information that includes at least two of the 11th to 15th identification information.

Furthermore, the 21st identification information is a PDU session ID that identifies a PDU session. Furthermore, the 21st identification information may be a PDU session ID that identifies a PDU session that is requested to be established. When requesting the establishment of a first PDU session, the 21st identification information may be a PDU session ID that identifies the first PDU session. Furthermore, when requesting the establishment of a second PDU session, the 21st identification information may be a PDU session ID that identifies the second PDU session. Furthermore, when requesting the establishment of a third PDU session, the 21st identification information may be a PDU session ID that identifies the third PDU session. Furthermore, when requesting the establishment of a fourth PDU session, the 21st identification information may be a PDU session ID that identifies the fourth PDU session. Furthermore, when requesting the establishment of a fifth PDU session, the 21st identification information may be a PDU session ID that identifies the fifth PDU session.

Furthermore, the 22nd identification information is a PDU session type that identifies the type of PDU session. Furthermore, the 22nd identification information may be a PDU session type requested by the UE for the PDU session. Furthermore, the 22nd identification information may indicate any of IPv4, IPv6, IPv4v6, Unstructured, or Ethernet (registered trademark).

Furthermore, the 23rd identification information is the SSC mode. Furthermore, the 23rd identification information may be the SSC mode requested by the UE for the PDU session. Furthermore, the 23rd identification information may indicate any of SSC mode 1, SSC mode 2, or SSC mode 3.

Furthermore, the 24th identification information is UE capability information. The 24th identification information may be 5GSM capability. Further, the 24th identification information may indicate whether the UE supports a certain function. Further, the 24th identification information may indicate whether the UE supports connecting to an SNPN service via a PLMN. Further, the 24th identification information may indicate whether the UE supports a function of establishing a PDU session to an SNPN via a PLMN. Further, the 24th identification information may indicate whether the UE supports connecting to a PLMN service via an SNPN. Further, the 24th identification information may indicate whether the UE supports a function of establishing a PDU session to a PLMN via an SNPN.

The 25th identification information may also be one or more S-NSSAIs. The 25th identification information may also be one or more S-NSSAIs requested by the UE for the PDU session to be established. The 25th identification information may also be one or more S-NSSAIs selected from the Allowed NSSAIs for the current access type. Specifically, the 25th identification information may be one or more S-NSSAIs for at least one of the accesses (3GPP access or non-3GPP access) allowed by the network as an Allowed NSSAI included in a Registration Accept message in the registration procedure.

Furthermore, the 26th identification information is a DNN. Further, the 26th identification information may be a DNN that identifies the DN to which the PDU session that the UE requests to establish is connected.

Furthermore, the 27th identification information may be a PDU session ID that identifies an already established PDU session. For example, when requesting the establishment of a third PDU session, the 27th identification information may be a PDU session ID that identifies a PDU session (second PDU session) to be established in the PLMN. Further, when requesting the establishment of a fifth PDU session, the 27th identification information may be a PDU session ID that identifies a PDU session (fourth PDU session) to be established in the SNPN.

Furthermore, the 28th identification information is identification information that includes at least two of the 21st to 27th identification information.

Furthermore, the 31st identification information is a PDU session ID that identifies a PDU session. It may be a PDU session ID that identifies a PDU session that is permitted to be established by the network. The 31st identification information may be the same as the 21st identification information.

Furthermore, the 32nd identification information is a PDU session type that identifies the type of PDU session. Furthermore, the 32nd identification information may be a PDU session type selected by the network. Furthermore, the 32nd identification information may indicate any of IPv4, IPv6, IPv4v6, Unstructured, or Ethernet (registered trademark).

Furthermore, the 33rd identification information is the SSC mode. Further, the 33rd identification information may be the SSC mode selected by the network for the PDU session. Further, the 33rd identification information may indicate any of SSC mode 1, SSC mode 2, or SSC mode 3.

Furthermore, the 34th identification information is network UE capability information. The 34th identification information may be 5GSM network feature support. Further, the 34th identification information may indicate whether the network supports a certain function. Further, the 24th identification information may indicate whether the network supports connecting to an SNPN service via a PLMN. Further, the 24th identification information may indicate whether the network supports a function to establish a PDU session to an SNPN via a PLMN. Further, the 24th identification information may indicate whether the network supports connecting to a PLMN service via an SNPN. Further, the 24th identification information may indicate whether the network supports a function to establish a PDU session to a PLMN via an SNPN.

Furthermore, the 35th identification information is one or more S-NSSAIs.

Furthermore, the 36th identification information is a DNN. Further, the 36th identification information may be a DNN that identifies the DN to which the PDU session is connected.

Furthermore, the 37th identification information is identification information that includes at least two of the 31st to 36th identification information.

[3. Registration Procedure]
This chapter describes the registration procedure shown in Figure 12. In this chapter, the registration procedure is also referred to as the main procedure.

The registration procedure is a UE-initiated procedure for a UE to register with an access network, and/or core network, and/or DN. If the UE is not registered with the network, it can execute this procedure at any time, for example, when powered on. In other words, if the UE is in a deregistered state (5GMM-DEREGISTERED state), it can start this procedure at any time. Furthermore, each device (especially the UE and AMF) can transition to a registered state (5GMM-REGISTEDED state) upon completion of the registration procedure. Each registration state may be managed by each device for each access. Specifically, each device may independently manage its registration state for 3GPP access (registered state or unregistered state) and its registration state for non-3GPP access.

Furthermore, the registration procedure may be a procedure for updating the location registration information of the UE in the network, and/or for the UE to periodically notify the network of the UE's status, and/or for updating certain parameters related to the UE in the network.

The UE may initiate the registration procedure when it performs mobility across TAs. 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 maintains. Furthermore, the UE may initiate the registration procedure when the context of each device needs to be updated due to the 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 the registration procedure, the completion of the PDU session establishment procedure, or information received from the network during each procedure. Note that the UE is not limited to these and can perform the registration procedure at any time.

The procedure for the UE to transition from a state in which it is not registered with the network (unregistered state) to a registered state (registered state) may be an initial registration procedure or a registration procedure for initial registration. Furthermore, the registration procedure performed when the UE is registered with the network (registered state) may be a registration procedure for mobility and periodic registration update or a mobility and periodic registration procedure.

First, the UE initiates the registration procedure by sending a registration request message to the AMF via the access network (S600, S602, S604). Here, the access network may include a base station or an access point. That is, the UE sends an RRC message including a registration request message to the base station or access point (S600). The registration request message is a NAS message transmitted and received over the N1 interface. The RRC message may be a control message transmitted and received between the UE and the base station or access point. Furthermore, if the access network is non-3GPP access, an IKE message or EAP message may be used instead of the RRC message. Hereinafter, for simplicity's sake, IKE messages or EAP messages will also be referred to as RRC messages. That is, the RRC message in this chapter may be understood as a concept that includes RRC messages, IKE messages, and EAP messages. Furthermore, NAS messages are processed in the NAS layer, and RRC messages are processed in the RRC layer, which is lower than the NAS layer.

Here, the UE may transmit at least one of the first to fourth identification information in a registration request message and/or an RRC message.

The UE may transmit at least one of these pieces of identification information in a control message other than the above, for example, a control message for a layer lower than the RRC layer (e.g., the MAC (Medium Access Control) layer, the RLC (Radio Link Control) layer, the PDCP (Packet Data Convergence Protocol) layer, the SDAP (Service Data Adaptation Protocol) layer, etc.). By transmitting this identification information, the UE may indicate that it supports each function, indicate a request from the UE, or indicate both.

In addition, the UE may select and decide whether to transmit at least one of these pieces of identification information based on the UE's capability information, and/or UE policy, and/or UE status, and/or user registration information, and/or context held by the UE, etc.

The UE may include information other than these identification information in the registration request message and/or RRC message, such as the UE ID and/or PLMN ID and/or AMF identification information, and may transmit the message. Here, the AMF identification information may be information that identifies an AMF or a set of AMFs, such as the 5G-S-TMSI (5G S-Temporary Mobile Subscription Identifier) or the GUAMI (Globally Unique AMF Identifier).

When the base station device receives an RRC message including a registration request message, it selects an AMF to which to forward the registration request message (S602). The base station device can select an AMF based on the received message and/or information. The base station device may also select an AMF based on other conditions.

The base station device extracts the registration request message from the received RRC message and forwards the registration request message to the selected AMF (S604). Note that if at least one of the first to fourth identification information is included in the RRC message but not in the registration request message, the identification information included in the RRC message may be forwarded to the selected AMF together with the registration request message (S604).

When the AMF receives a registration request message, it can perform a first condition determination. The first condition determination is for determining whether the network will accept the UE's request. If the AMF determines that the first condition determination is true, it may perform procedures S610 to S612. Also, if the AMF determines that the first condition determination is false, it may perform the procedure S610.

If the first condition determination is true, the control message sent and received in S610 may be a Registration accept message, and if the first condition determination is false, the control message sent and received in S610 may be a Registration reject message.

In addition, the first condition determination may be performed based on the receipt of a registration request message, and/or each identification information contained 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 context held by the AMF, 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. Furthermore, if the network to which the UE is registered 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. Furthermore, if the identification information to be transmitted and received is permitted, the first condition determination may be determined to be true, and if the identification information to be transmitted and received is not permitted, the first condition determination may be determined to be false.

Here, we will continue the explanation assuming that the first condition test is determined to be true.

The AMF may transmit a control message including one or more of the identification information items 11 to 16. Furthermore, the 11th identification information may be information that is sent only when the first identification information is received, or information that is sent even if the first identification information is not received. By transmitting these identification information items and/or control messages, the AMF may indicate that the network supports each function, may indicate that the UE's request has been accepted, may indicate that the request from the UE has not been permitted, or may indicate a combination of these. Furthermore, when multiple identification information items are transmitted and received, two or more of these identification information items may be configured as one or more identification information items. 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.

When the AMF sends a control message (registration acceptance message), it does not have an allowed S-NSSAI (allowed NSSAI) for the UE, but if it plans to perform an NSSAA procedure after completing this procedure or in parallel with this procedure, or if an NSSAA procedure is currently being performed between the UE and the network, or if it sends a pending NSSAI in the control message, it may send an empty value in the allowed NSSAI.

In addition, the AMF may determine which of the identification information 11 to 16 to include in the control 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 the AMF, etc.

The AMF 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 subscription 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.

The UE receives a control message (registration acceptance message) via the base station device (S610). By receiving the registration acceptance message, the UE can recognize that the UE's request via the registration request message has been accepted, and the contents of the various identification information included in the registration acceptance message.

The UE can further send a registration completion message to the AMF via the base station device as a response message to the registration acceptance message (S612). Here, the registration completion message is a NAS message sent and received over the N1 interface, but may be included in an RRC message and sent and received between the UE and the base station device.

The AMF receives a registration completion message via the base station device (S612). Each device then completes this procedure based on the sending and receiving of a registration acceptance message and/or a registration completion message.

In addition, each device may transition to or maintain a state in which the UE is registered in the network (RM_REGISTERED state or 5GMM-REGISTERED state) based on sending or receiving a registration acceptance message and/or a registration completion message, or based on completion of the registration procedure.

In addition, each device may store the information sent and received in this procedure in association with each other.

In addition, these states may be maintained or transitioned based on the information and control messages sent and received in this procedure, or based on the information and control messages sent and received in procedures executed prior to this procedure.

[4. PDU Session Establishment Procedure]
This chapter describes the PDU session establishment procedure shown in Figure 13. In this chapter, the PDU session establishment procedure is also referred to as this procedure.

The PDU session establishment procedure is a procedure performed by the UE to establish a PDU session and is a UE-initiated procedure.

First, the UE initiates the PDU session establishment procedure by sending a NAS message including an N1 SM container containing a PDU session establishment request message to the AMF via the access network (S800). Here, the access network may include a base station device or an access point. That is, the UE sends the NAS message to the AMF via the base station device or the access point. 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 UE can also notify the network side of its request by sending a PDU session establishment request message, and/or an N1 SM container, and/or an NAS message containing at least one of the identification information items 21 to 28.

In addition, the UE may determine which of the identification information 21 to 28 to transmit to the network based on the UE's capability information, and/or UE policy, and/or UE status, and/or user registration information, and/or context held by the UE, etc.

In addition, the UE may transmit this identification information in a different control message, such as a control message for a layer lower than the NAS layer (e.g., RRC layer, MAC layer, RLC layer, PDCP layer, SDAP layer, etc.) or a control message for a layer higher than the NAS layer (e.g., transport layer, session layer, presentation layer, application layer, etc.).

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

Next, the AMF selects an SMF as the destination for transferring at least part 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.

Next, the AMF sends at least a portion of the information (message, container, information) contained in the NAS message received from the UE to the selected SMF, for example via the N11 interface (S804).

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

Here, the SMF may make a second condition determination. The second condition determination may be for determining whether the network will accept the UE's request. If the SMF determines that the second condition determination is true, it may initiate the procedure shown in (A) of Figure 9. If the SMF determines that the second condition determination is false, it may initiate the procedure shown in (B) of Figure 9.

In addition, the second 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 second condition determination may be determined to be true, and if the network does not permit the UE's request, the second condition determination may be determined to be false. Furthermore, if the network to which the UE is connected and/or a device within the network supports the function requested by the UE, the second condition determination may be determined to be true, and if the function requested by the UE is not supported, the second condition determination may be determined to be false. Furthermore, if the transmitted and received identification information is permitted, the second condition determination may be determined to be true, and if the transmitted and received identification information is not permitted, the second condition determination may be determined to be false. The conditions for determining whether the second condition determination is true or false do not have to be limited to the conditions described above.

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

The SMF may then select a UPF for the PDU session to be established and send an N4 session establishment request message to the selected UPF, for example via the N4 interface (S808). The N4 session establishment request message may include at least a portion of the PCC rules received from the PCF.

Here, the SMF may select one or more UPFs based on information received from the AMF (messages, containers, information), and/or information such as PCC rules received from the PCF, and/or subscriber information, and/or network capability information, and/or UE policies, and/or operator policies, and/or network status, and/or user registration information, and/or context held by the SMF. If multiple UPFs are selected, the SMF may send an N4 session establishment request message to each UPF. Here, it is assumed that UPF_232 (hereinafter also referred to as UPF) is selected.

Next, when the UPF receives the N4 session establishment request message (S808), it can recognize the contents of the information received from the SMF. Based on the reception of the N4 session establishment request message, the UPF may also send an N4 session establishment response message to the SMF, for example, via the N4 interface (S810).

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 sends an N1 SM container, N2 SM information, and/or PDU session ID to the AMF, for example via the N11 interface, based on the receipt of the PDU session establishment request message, and/or the selection of the UPF, and/or the receipt of the N4 session establishment response message (S812). Here, the N1 SM container may include a PDU session establishment acceptance message.

Next, the AMF that has received the N1 SM container, and/or N2 SM information, and/or PDU session ID, transmits a NAS message to the UE via a base station device included in the access network (S814) (S816). 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, the AMF transmits an N2 PDU session request message to a base station device included in the access network (S814), and the base station device that receives the N2 PDU session request message transmits an NAS message to the UE (S816). Here, the N2 PDU session request message may include an NAS message and/or N2 SM information. The NAS message may also include a PDU session ID and/or an N1 SM container.

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 a PDU session establishment acceptance message, and/or an N1 SM container, and/or a PDU session ID, and/or an NAS message, and/or N2 SM information, and/or an N2 PDU session request message.

Here, the SMF and/or AMF may include at least one of the identification information 31 to 37 in 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 and send it. Here, the identification information 31 shall be identical to the identification information 21 of this procedure.

By sending these identification information and/or a PDU session establishment acceptance message, the SMF may indicate that the network supports each function, that the UE's request has been accepted, that the UE's request has not been authorized, or a combination of these. Furthermore, when multiple identification information is transmitted and received, 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 as different identification information.

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.

In addition, the SMF and/or AMF may determine which identification information to include in the PDU session establishment acceptance message, and/or N1 SM container, and/or NAS message, and/or N2 SM information, and/or 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 an NAS message (S816), for example via the N1 interface, 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 (message, container, information) included in the NAS message. For example, based on the received identification information 31, 32, and 33, the UE may recognize the PDU session type and SSC mode set for the PDU session identified by identification information 31. Furthermore, based on the received identification information 34, the UE may recognize the functions supported by the network.

Next, we will explain each step of the procedure in Figure 9 (B).

First, based on receiving the PDU session establishment request message, the SMF sends an N1 SM container and/or a PDU session ID to the AMF, for example via the N11 interface (S818). Here, the N1 SM container may include a PDU session establishment rejection message.

Next, the AMF that has received the N1 SM container and/or the PDU session ID transmits a NAS message to the UE via a first base station device included in the access network (S820) (S822). Here, the NAS message is transmitted, for example, via the N1 interface. The NAS message may be a downlink NAS transport (DL NAS TRANSPORT) message. The NAS message may include the PDU session ID and/or the N1 SM container.

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

Here, the SMF and/or AMF 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, and/or an N1 SM container, and/or a PDU session ID, and/or a NAS message.

By sending a PDU session establishment rejection message, the SMF may indicate that the network does not support each function, that the UE request has been rejected, that the request from the UE has not been authorized, or a combination of these. Furthermore, when multiple pieces of identification information are transmitted and received, two or more of these pieces of identification information may be configured as one or more pieces of 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 as different identification information.

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.

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

Each device may complete this procedure based on sending and receiving a PDU session establishment acceptance message. At this time, each device may transition to a state in which it can communicate with the DN using the established PDU session.

Each device may complete this procedure based on sending and receiving a PDU session establishment rejection message. At this time, each device cannot establish a PDU session, and therefore cannot communicate with the DN if there is no already established PDU session.

In addition, the processes performed by the UE based on the reception of each identification information shown above may be performed during this procedure or after completion of this procedure, or may be performed after completion of this procedure based on the completion of this procedure.

In addition, each device may store the information sent and received in this procedure in association with each other.

In addition, these states may be maintained or transitioned based on the information and control messages sent and received in this procedure, or based on the information and control messages sent and received in procedures executed prior to this procedure.

Here, we assume that a PDU session establishment acceptance message is received and the PDU session is established.

5. First Embodiment
In this embodiment, in order for the UE to directly connect to the SNPN service, the UE performs the registration procedure of Chapter 5.1 with the core network 200 via the non-3GPP access (access network 100) in the SNPN to enter a registered state, and then performs the PDU session establishment procedure of Chapter 5.2 to establish a PDU session (first PDU session), and becomes capable of communicating with the DN 250 using the established PDU session. In this embodiment, this series of procedures will be explained using Figures 1, 2, 12, and 13.

5.1. Registration Procedures for SNPN
First, the registration procedure for the SNPN will be explained using Figure 12. In this chapter, the registration procedure for the SNPN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 2, state 4, state 6, or state 7. Specifically, a UE in any of these states can perform the SNPN selection procedure to select an SNPN, and then perform this procedure for the selected SNPN via non-3GPP access. Here, the PLMN ID and NID used to identify and select the SNPN may be, for example, those originally possessed by the UE, or may be those included in system information broadcast from the base station device or access point of the SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered with the SNPN, and may be in the second, fourth, sixth, or seventh state. At this time, the UE may be in a state where it can receive SNPN services.

5.2. PDU Session Establishment Procedure for SNPN
Next, the PDU session establishment procedure for the SNPN will be explained using Figure 13. In this chapter, the PDU session establishment procedure for the SNPN will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE that has performed the procedure in Chapter 5.1 one or more times and is in state 2, 4, 6, or 7 may perform this procedure via non-3GPP access. Specifically, a UE in any of these states may perform this procedure to establish a PDU session when it is registered to an SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (first PDU session), and may be in the second, fourth, sixth, or seventh state. At this time, the UE may be in a state where it can receive SNPN services.

6. Second Embodiment
In this embodiment, in order to connect to an SNPN service via a PLMN, a UE performs the registration procedure of Chapter 6.1 with a core network _202 via a non-3GPP access (access network _102) in the PLMN to become registered, and then performs the PDU session establishment procedure of Chapter 6.2 to become capable of communicating with DN_252 using the established PDU session (second PDU session). Then, the UE further performs the registration procedure of Chapter 6.3 with a core network _200 via a non-3GPP access (access network _100) to become registered, and then performs the PDU session establishment procedure of Chapter 6.4 to become capable of communicating with DN_250 using the established PDU session (third PDU session). In this embodiment, these series of procedures will be described using Figures 3, 4, 12, and 13.

6.1. PLMN Registration Procedure
First, the registration procedure for a PLMN will be explained using Figure 12. In this chapter, the registration procedure for a PLMN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 1, state 3, state 5, or state 7. Specifically, a UE in any of these states can perform a PLMN selection procedure to select a PLMN, and then perform this procedure for the selected PLMN via non-3GPP access. Here, the PLMN ID used to identify and select a PLMN may be, for example, one originally possessed by the UE, or may be one included in system information broadcast from a base station device or access point of the PLMN.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered with the PLMN, and may be in the first, third, fifth, or seventh state. At this time, the UE may be in a state where it can receive PLMN services.

6.2. PDU Session Establishment Procedure for PLMN
Next, the PDU session establishment procedure for the PLMN will be explained using Figure 13. In this chapter, the PDU session establishment procedure for the PLMN will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE that has performed the procedure in Chapter 6.1 one or more times and is in state 1, state 3, state 5, or state 7 may perform this procedure via non-3GPP access. Specifically, a UE in any of these states may perform this procedure to establish a PDU session when it is registered with a PLMN.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (second PDU session), and may be in state 1, state 3, state 5, state 7, or state 9. At this time, the UE may be in a state where it can receive PLMN services.

6.3. Registration Procedure for SNPN (via PLMN)
Next, the registration procedure for the SNPN performed via the PLMN will be described with reference to Figure 12. In this chapter, the registration procedure for the SNPN performed via the PLMN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 7 or state 9. Specifically, a UE in state 7 or state 9 may perform an SNPN selection procedure to select an SNPN, and then perform this procedure for the selected SNPN via non-3GPP access. Here, the PLMN ID and NID used to identify and select an SNPN may be, for example, those originally possessed by the UE, or may be those included in system information broadcast from a base station device or access point of the SNPN or PLMN.

In addition, the registration request message, registration acceptance message, registration rejection message, and registration completion message in this procedure are sent and received between the UE and core network devices such as AMF (AMF_210) via N3IWF_240.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered not only with the PLMN but also with the SNPN, and may be in the seventh or ninth state. At this time, the UE may be in a state where it can receive SNPN services. In other words, the UE may be in a state where it can receive SNPN services via the PLMN.

6.4. PDU Session Establishment Procedure for SNPN (via PLMN)
Next, the PDU session establishment procedure for the SNPN, which is executed via the PLMN, will be described with reference to Figure 13. In this chapter, the PDU session establishment procedure for the SNPN, which is executed via the PLMN, will also be referred to as this procedure. Since the PDU session establishment procedure in Chapter 4 can be applied to this procedure, details of the procedure will be omitted here.

Note that a UE in state 7 or 9 may perform this procedure via 3GPP access after performing the procedure in Chapter 6.3 one or more times. Specifically, a UE in state 7 or 9 may perform this procedure to establish a PDU session when it is registered with a PLMN and an SNPN.

In addition, the PDU session establishment request message, PDU session establishment acceptance message, and PDU session establishment rejection message in this procedure are sent and received between the UE and core network devices such as SMF (SMF_220) via N3IWF_240.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (third PDU session), and may be in the seventh or ninth state. At this time, the UE may be in a state where it can receive SNPN services. In other words, the UE may be in a state where it can receive SNPN services via the PLMN.

7. Third Embodiment
In this embodiment, in order to connect to an SNPN service via a PLMN, a UE performs the registration procedure of Chapter 7.1 with a core network _202 via a non-3GPP access (access network _102) in the PLMN to become registered, and then performs the PDU session establishment procedure of Chapter 7.2 to become capable of communicating with DN_252 using the established PDU session (second PDU session).The UE then performs the registration procedure of Chapter 7.3 with a core network _200 via a 3GPP access (access network _100) to become registered, and then performs the PDU session establishment procedure of Chapter 7.4 to become capable of communicating with DN_250 using the established PDU session (third PDU session).In this embodiment, these series of procedures will be described using Figures 3, 5, 12, and 13.

7.1. PLMN Registration Procedure
First, the registration procedure for a PLMN will be explained using Figure 12. In this chapter, the registration procedure for a PLMN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 1, state 3, state 5, or state 7. Specifically, a UE in any of these states can perform a PLMN selection procedure to select a PLMN, and then perform this procedure for the selected PLMN via non-3GPP access. Here, the PLMN ID used to identify and select a PLMN may be, for example, one originally possessed by the UE, or may be one included in system information broadcast from a base station device or access point of the PLMN.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered with the PLMN, and may be in the first, third, fifth, or seventh state. At this time, the UE may be in a state where it can receive PLMN services.

7.2. PDU Session Establishment Procedure for PLMN
Next, the PDU session establishment procedure for the PLMN will be explained using Figure 13. In this chapter, the PDU session establishment procedure for the PLMN will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE that has performed the procedure in Chapter 7.1 one or more times and is in state 1, state 3, state 5, or state 7 may perform this procedure via non-3GPP access. Specifically, a UE in any of these states may perform this procedure to establish a PDU session when it is registered with a PLMN.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (second PDU session), and may be in the first state, third state, fifth state, or seventh state. At this time, the UE may be in a state where it can receive PLMN services.

7.3. Registration Procedure for SNPN (via PLMN)
Next, the registration procedure for the SNPN performed via the PLMN will be described with reference to Figure 12. In this chapter, the registration procedure for the SNPN performed via the PLMN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in the fifth state. Specifically, a UE in the fifth state may perform an SNPN selection procedure to select an SNPN, and then perform this procedure for the selected SNPN via 3GPP access. Here, the PLMN ID and NID used to identify and select an SNPN may be, for example, those originally possessed by the UE, or may be those included in system information broadcast from a base station device or access point of the SNPN or PLMN.

In addition, the registration request message, registration acceptance message, registration rejection message, and registration completion message in this procedure are sent and received between the UE and core network devices such as AMF (AMF_210) via NF_260.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered not only with the PLMN but also with the SNPN, and may enter the fifth state. At this time, the UE may be in a state where it can receive SNPN services. In other words, the UE may be in a state where it can receive SNPN services via the PLMN.

7.4. PDU Session Establishment Procedure for SNPN (via PLMN)
Next, the PDU session establishment procedure for the SNPN, which is executed via the PLMN, will be described with reference to Figure 13. In this chapter, the PDU session establishment procedure for the SNPN, which is executed via the PLMN, will also be referred to as this procedure. Since the PDU session establishment procedure in Chapter 4 can be applied to this procedure, details of the procedure will be omitted here.

Note that a UE in state 5 may perform this procedure via 3GPP access after performing the procedure in Chapter 7.3 one or more times. Specifically, a UE in state 5 may perform this procedure to establish a PDU session when it is registered with a PLMN and an SNPN.

In addition, the PDU session establishment request message, PDU session establishment acceptance message, and PDU session establishment rejection message in this procedure are sent and received between the UE and core network devices such as SMF (SMF_220) via NF_260.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (third PDU session) and may enter the fifth state. At this time, the UE may be in a state where it can receive SNPN services. In other words, the UE may be in a state where it can receive SNPN services via the PLMN.

8. Fourth Embodiment
In this embodiment, in order to connect to a PLMN service via an SNPN, a UE performs the registration procedure of Chapter 8.1 with respect to a core network 200 via a non-3GPP access (access network 100) in the SNPN to become registered, and then performs the PDU session establishment procedure of Chapter 8.2 to become capable of communicating with a DN 250 using the established PDU session (fourth PDU session). The UE then performs the registration procedure of Chapter 8.3 with respect to a core network 202 via a non-3GPP access (access network 102) to become registered, and then performs the PDU session establishment procedure of Chapter 8.4 to become capable of communicating with a DN 252 using the established PDU session (fifth PDU session). In this embodiment, these series of procedures will be described using Figures 6, 7, 12, and 13.

8.1. Registration Procedures for SNPN
First, the registration procedure for the SNPN will be explained using Figure 12. In this chapter, the registration procedure for the SNPN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 2, state 4, state 6, or state 7. Specifically, a UE in any of these states can perform the SNPN selection procedure to select an SNPN, and then perform this procedure for the selected SNPN via non-3GPP access. Here, the PLMN ID and NID used to identify and select the SNPN may be, for example, those originally possessed by the UE, or may be those included in system information broadcast from the base station device or access point of the SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered with the SNPN, and may be in the second, fourth, sixth, or seventh state. At this time, the UE may be in a state where it can receive SNPN services.

8.2. PDU Session Establishment Procedure for SNPN
Next, the PDU session establishment procedure for the SNPN will be explained using Figure 13. In this chapter, the PDU session establishment procedure for the SNPN will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE that has performed the procedure in Chapter 8.1 one or more times and is in state 2, 4, 6, or 7 may perform this procedure via non-3GPP access. Specifically, a UE in any of these states may perform this procedure to establish a PDU session when it is registered to an SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (fourth PDU session), and may be in the second state, fourth state, sixth state, seventh state, or eighth state. At this time, the UE may be in a state where it can receive SNPN services.

8.3. Registration Procedure for PLMN (via SNPN)
Next, the registration procedure for the PLMN performed via the SNPN will be described with reference to Figure 12. In this chapter, the registration procedure for the PLMN performed via the SNPN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 7 or state 8. Specifically, a UE in state 7 or state 8 may perform a PLMN selection procedure to select a PLMN, and then perform this procedure for the selected PLMN via non-3GPP access. Here, the PLMN ID used to identify and select a PLMN may be, for example, one originally possessed by the UE, or may be one included in system information broadcast from a base station device or access point of the PLMN or SNPN.

In addition, the registration request message, registration acceptance message, registration rejection message, and registration completion message in this procedure are sent and received between the UE and core network devices such as AMF (AMF_212) via N3IWF_242.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered not only with the SNPN but also with the PLMN, and may be in the seventh or eighth state. At this time, the UE may be in a state where it can receive PLMN services. In other words, the UE may be in a state where it can receive PLMN services via the SNPN.

8.4. PDU Session Establishment Procedures for PLMN (via SNPN)
Next, the PDU session establishment procedure for the PLMN, which is executed via the SNPN, will be described with reference to Figure 13. In this chapter, the PDU session establishment procedure for the PLMN, which is executed via the SNPN, will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE in state 7 or 8 may perform this procedure via non-3GPP access after having performed the procedure in Chapter 8.3 one or more times. Specifically, a UE in state 7 or 8 may perform this procedure to establish a PDU session when it is registered with a PLMN and an SNPN.

In addition, the PDU session establishment request message, PDU session establishment acceptance message, and PDU session establishment rejection message in this procedure are sent and received between the UE and core network devices such as SMF (SMF_222) via N3IWF_242.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (fifth PDU session) and may be in the seventh or eighth state. At this time, the UE may be in a state where it can receive PLMN services. In other words, the UE may be in a state where it can receive PLMN services via the SNPN.

9. Fifth Embodiment
In this embodiment, in order to connect to a PLMN service via an SNPN, a UE performs the registration procedure of Chapter 9.1 with a core network _200 via a non-3GPP access (access network _100) in the SNPN to become registered, and then performs the PDU session establishment procedure of Chapter 9.2 to become capable of communicating with DN_250 using the established PDU session (fourth PDU session).The UE then performs the registration procedure of Chapter 9.3 with a core network _202 via a 3GPP access (access network _102) to become registered, and then performs the PDU session establishment procedure of Chapter 9.4 to become capable of communicating with DN_252 using the established PDU session (fifth PDU session).In this embodiment, these series of procedures will be described using Figures 6, 8, 12, and 13.

9.1. Registration Procedures for SNPN
First, the registration procedure for the SNPN will be explained using Figure 12. In this chapter, the registration procedure for the SNPN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in state 2, state 4, state 6, or state 7. Specifically, a UE in any of these states can perform the SNPN selection procedure to select an SNPN, and then perform this procedure for the selected SNPN via non-3GPP access. Here, the PLMN ID and NID used to identify and select the SNPN may be, for example, those originally possessed by the UE, or may be those included in system information broadcast from the base station device or access point of the SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered with the SNPN, and may be in the second, fourth, sixth, or seventh state. At this time, the UE may be in a state where it can receive SNPN services.

9.2. PDU Session Establishment Procedure for SNPN
Next, the PDU session establishment procedure for the SNPN will be explained using Figure 13. In this chapter, the PDU session establishment procedure for the SNPN will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE that has performed the procedure in Chapter 9.1 one or more times and is in state 2, 4, 6, or 7 may perform this procedure via non-3GPP access. Specifically, a UE in any of these states may perform this procedure to establish a PDU session when it is registered to an SNPN.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (fourth PDU session), and may be in the second state, fourth state, sixth state, or seventh state. At this time, the UE may be in a state where it can receive SNPN services.

9.3. Registration Procedure for PLMN (via SNPN)
Next, the registration procedure for the PLMN performed via the SNPN will be described with reference to Figure 12. In this chapter, the registration procedure for the PLMN performed via the SNPN will also be referred to as this procedure. Since the registration procedure in Chapter 3 can be applied to this procedure, details of the procedure will be omitted here.

This procedure may be performed by a UE in the fourth state. Specifically, a UE in the fourth state may perform a PLMN selection procedure to select a PLMN, and then perform this procedure for the selected PLMN via 3GPP access. Here, the PLMN ID used to identify and select the PLMN may be, for example, one originally possessed by the UE, or may be one included in system information broadcast from a base station device or access point of the PLMN or SNPN.

In addition, the registration request message, registration acceptance message, registration rejection message, and registration completion message in this procedure are sent and received between the UE and core network devices such as AMF (AMF_212) via NF_262.

Furthermore, when this procedure is completed based on the sending and receiving of a registration acceptance message and/or a registration completion message, the UE may be registered not only with the SNPN but also with the PLMN, and may enter the fourth state. At this time, the UE may be in a state where it can receive PLMN services. In other words, the UE may be in a state where it can receive PLMN services via the SNPN.

9.4. PDU Session Establishment Procedures for PLMN (via SNPN)
Next, the PDU session establishment procedure for the PLMN, which is executed via the SNPN, will be described with reference to Figure 13. In this chapter, the PDU session establishment procedure for the PLMN, which is executed via the SNPN, will also be referred to as this procedure. Since this procedure can be applied to the PDU session establishment procedure in Chapter 4, details of the procedure will be omitted here.

Note that a UE in state 4 may perform this procedure via 3GPP access after performing the procedure in Chapter 9.3 one or more times. Specifically, a UE in state 4 may perform this procedure to establish a PDU session when it is registered with a PLMN and an SNPN.

In addition, the PDU session establishment request message, PDU session establishment acceptance message, and PDU session establishment rejection message in this procedure are sent and received between the UE and core network devices such as SMF (SMF_222) via NF_262.

Furthermore, when this procedure is completed based on the sending and receiving of a PDU session establishment acceptance message, the UE may be in a state where it can communicate with the DN using the established PDU session (fifth PDU session) and may be in the fourth state. At this time, the UE may be in a state where it can receive PLMN services. In other words, the UE may be in a state where it can receive PLMN services via the SNPN.

10. Variations
A program running on an apparatus according to one 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 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 another storage device system.

A program for realizing the functions of an embodiment relating 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. Furthermore, the term "computer-readable recording medium" may refer to a semiconductor recording medium, an optical recording medium, a magnetic recording medium, a medium that dynamically stores a program for a short period of time, or any other computer-readable recording medium.

Furthermore, each functional block or feature of the device used in the above-described embodiments may be implemented or performed by an electrical circuit, such as an integrated circuit or multiple integrated circuits. The electrical 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 electrical circuit may be composed of digital circuits or analog circuits. Furthermore, as advances in semiconductor technology emerge that provide alternative integrated circuit technologies to current integrated circuits, one or more aspects of the present invention may utilize new integrated circuits based on that technology.

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

Although the embodiments of the present invention have 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 are also included within the scope of the gist of the present invention. Furthermore, various modifications of one aspect of the present invention are possible 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. Furthermore, configurations in which elements described in the above embodiments are substituted with elements that achieve the same effect are also included.

Claims (1)

A UE (User Equipment) having a control unit,
When connecting to a Stand-alone Non-Public Network (SNPN) service using non-3GPP access via a Public Land Mobile Network (PLMN), the control unit:
does not operate in SNPN access mode for PLMNs,
For SNPN, it operates in SNPN access mode,
A UE characterized by: