KR20230073737A - Method and apparatus for provisioning credential information of terminal in wireless communication system - Google Patents

Abstract

The present disclosure relates to a 5G system for supporting a higher data rate after a 4G communication system such as LTE. In a wireless communication system, a first device performs an authentication operation with a terminal in a first network, receives a first message indicating that the authentication of the terminal has been completed, checks an identifier (ID) and an indicator of the terminal included in the first message, obtains the credential information of the terminal for using a service provided in the second network from a second device of the second network based on the ID of the terminal, and performs a terminal parameter update operation for providing the credential information of the terminal to the terminal if the indicator includes a first value, wherein the first value may indicate that a third device for storing and managing the data of the terminal in the first network is not used and the first device performs operations as the third device. Therefore, provided are a method and a device for enabling a terminal to receive a desired service from a subscription owner-standalone non-public network (SO-SNPN) even without the credential information of the SO-SNPN.

Description

Method and apparatus for provisioning credential information of a terminal in a wireless communication system

Various embodiments of the present disclosure relate to a method and apparatus for provisioning credential information of a terminal in a wireless communication system.

Efforts are being made to develop an improved 5th generation ( ^5G ) communication system or a pre-5G communication system in order to meet the growing demand for wireless data traffic after the commercialization of a 4th generation (4G ⁾ communication system. For this reason, the 5G communication system or the pre-5G communication system is called a Beyond 4G Network communication system or a post LTE system.

In order to achieve a high data rate, the 5G communication system is being considered for implementation in a mmWave band (eg, a 60 gigabyte (60 GHz) band). In order to mitigate the path loss of radio waves and increase the propagation distance of radio waves in the ultra-high frequency band, beamforming, massive MIMO, and Full Dimensional MIMO (FD-MIMO) are used in 5G communication systems. ), array antenna, analog beam-forming, and large scale antenna technologies are being discussed.

In addition, to improve the network of the system, in the 5G communication system, an evolved small cell, an advanced small cell, a cloud radio access network (cloud RAN), and an ultra-dense network , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation etc. are being developed.

In addition, in the 5G system, advanced coding modulation (Advanced Coding Modulation: ACM) methods FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), advanced access technologies FBMC (Filter Bank Multi Carrier), NOMA (non orthogonal multiple access), SCMA (sparse code multiple access), etc. are being developed.

Meanwhile, the Internet is evolving from a human-centered connection network in which humans generate and consume information to an Internet of Things (IoT) network in which information is exchanged between distributed components such as objects and processed. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connection with cloud servers, etc., is also emerging. In order to implement IoT, technical elements such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, sensor networks for connection between objects and machine to machine : M2M) and MTC (Machine Type Communication) technologies are being studied.

In the IoT environment, intelligent IT (Internet Technology) services that create new values in human life by collecting and analyzing data generated from connected objects can be provided. IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliances, advanced medical service, etc. can be applied to

Accordingly, various attempts are being made to apply the 5G communication system to the IoT network. For example, technologies such as sensor networks, M2M, and MTC are implemented by techniques such as beamforming, MIMO, and array antennas, which are 5G communication technologies. The application of the cloud radio access network (cloud RAN) as the big data processing technology described above can be said to be an example of convergence of 5G technology and IoT technology. As various services can be provided according to the above and the development of mobile communication systems, a method for effectively providing these services is required.

In the 5G system, support for various services is considered compared to the existing 4G system. For example, the most representative services are enhanced mobile broad band (eMBB), ultra-reliable and low latency communication (URLLC), and massive machine type communication service. communication: mMTC), evolved multimedia broadcast/multicast service (eMBMS), and the like. Also, a system providing the URLLC service may be referred to as a URLLC system, and a system providing the eMBB service may be referred to as an eMBB system. Also, the terms service and system may be used interchangeably.

Among them, the URLLC service is a service that is newly considered in the 5G system, unlike the existing 4G system, and has ultra-high reliability (eg, packet error rate of about 10 ^-5 ) and low latency (eg, About 0.5 msec) condition satisfaction is required. In order to satisfy these strict requirements, the URLLC service may require application of a shorter transmission time interval (TTI) than the eMBB service, and various operation methods using this are being considered.

Meanwhile, 3GPP, which is in charge of cellular mobile communication standards, names a new core network structure as 5G core (5GC) to seek evolution from the existing 4G LTE system to the 5G system, and standardization is in progress.

5GC supports the following differentiated functions compared to the evolved packet core (EPC), which is the network core for existing 4G.

First, in 5GC, a network slice function is introduced. As a requirement of 5G, 5GC must support various types of terminal types and services (e.g. eMBB, URLLC, or mMTC service). Different types of services have different requirements for the core network. For example, eMBB service requires high data rate and URLLC service requires high stability and low delay. One of the technologies proposed to satisfy these various service requirements is network slicing.

Network slicing is a method of creating multiple logical networks by virtualizing one physical network, and each network slice instance (NSI) may have different characteristics. Accordingly, each NSI can satisfy various service requirements by having a network function (NF) suitable for its characteristics. If an NSI suitable for the characteristics of the service requested by each terminal is allocated, various 5G services can be efficiently supported.

Second, 5GC can facilitate network virtualization paradigm support through separation of mobility management function and session management function. In 4G LTE, services could be provided through signaling exchange with a single core device called a mobility management entity (MME) responsible for registration, authentication, mobility management, and session management functions for all terminals. However, in 5G, as the number of terminals explodes and the mobility and traffic/session characteristics that must be supported according to the type of each terminal are subdivided, if all functions are supported in a single device such as the MME, it is necessary to add entities for each required function. Scalability is inevitable. Accordingly, various functions are being developed based on a structure in which a mobility management function and a session management function are separated in order to improve scalability in terms of function/implementation complexity and signaling load of a core device in charge of a control plane.

With the development of mobile communication systems, various services can be provided, and thus, a method for efficiently using a mobile communication system, in particular, a non-public network (NPN), is required. In consideration of this, in various embodiments of the present disclosure, even if the terminal does not have credential information (hereinafter referred to as 'credential') of the SO-SNPN (Subscription Owner-Standalone Non-Public Network) that the terminal wants to receive service, from the SO-SNPN To provide a method and apparatus for providing a desired service.

Various embodiments of the present disclosure provide a method and apparatus for providing credentials of a UE using a control plane from a provisioning server (PS) that manages credentials.

Various embodiments of the present disclosure provide a method and apparatus for enabling a UE to successfully complete access to an SO-SNPN to receive service based on credentials provided through a control plane.

According to various embodiments of the present disclosure, after successfully accessing the ON-SNPN, the UE may use the network entity of the ON-SNPN when receiving credentials of the SO-SNPN from the PS using the control plane. Since the UE uses the ON-SNPN having no subscriber information of the corresponding UE for provisioning, the UDM of the ON-SNPN may not be used. In such a case, DCS (Default Credential Server) or PS may take the place of UDM's existing role. Although subscriber information of the corresponding UE is not included in the UDM of the ON-SNPN, the UDM of the ON-SNPN may be used in order not to disturb the registration process of the existing 5G system and the UPU process using the control plane.

Various embodiments of the present disclosure present various embodiments according to when the PS provisions the SO-SNPN credential using the control plane, according to the entity requesting provisioning from the PS, and whether the UDM of the ON-SNPN is used. do. Information included in the message requesting provisioning may vary according to the various cases presented above.

A method according to an embodiment of the present disclosure; A method of a first device in a wireless communication system, comprising: performing an authentication operation with a terminal in a first network and receiving a first message indicating that authentication of the terminal has been completed; A process of checking an identifier (ID) and an indicator of a terminal, and qualification of the terminal to use a service provided in the second network from a second device of the second network based on the ID of the terminal obtaining credential information and, when the indicator includes a first value, performing a terminal parameter update operation for providing credential information of the terminal to the terminal, wherein the first The value may indicate that the third device that stores and manages data of the terminal in the first network is not used, and that the first device performs an operation as the third device.

An apparatus according to an embodiment of the present disclosure; A first device in a wireless communication system, including a transceiver and at least one processor, wherein the at least one processor performs an authentication operation with a terminal in a first network, and authentication of the terminal is performed through the transceiver A second device of a second network receives a first message indicating completion, checks an identifier (ID) and an indicator of the terminal included in the first message, and based on the ID of the terminal For obtaining credential information of the terminal for using a service provided in the second network from, and providing credential information of the terminal to the terminal when the indicator includes a first value. A terminal parameter update operation is performed, and the first value indicates that a third device that stores and manages data of the terminal in the first network is not used and that the first device performs an operation as the third device. can instruct

The technical problems to be achieved in the embodiments of the present disclosure are not limited to the above-mentioned technical problems, and other technical problems not mentioned are those of ordinary skill in the art to which the embodiments of the present disclosure belong from the description below. will be clearly understandable to you.

According to various embodiments of the present disclosure, even if a UE does not have SO-SNPN credentials in a wireless communication system, a desired service can be effectively provided from the SO-SNPN.

According to various embodiments of the present disclosure, communication with a provisioning server (PS) through an access and mobility management function (AMF) of ON-SNPN, an authentication server function (AUSF) of ON-SNPN, or a default credential server (DCS) Based on this, it is possible to perform an SO-SNPN credential provisioning procedure for the UE using the control plane.

According to various embodiments of the present disclosure, NAS security may be secured through ON-SNPN using a control plane, and security may be additionally applied using a UE parameters update (UPU) procedure.

According to various embodiments of the present disclosure, the UDM of PS, DCS, or ON-SNPN may perform the role of unified data management (UDM) required in the UPU procedure.

1 is a diagram illustrating a structure of a 5G mobile communication network according to various embodiments of the present disclosure.
2 is a diagram illustrating a structure of a network for provisioning credential information of a UE according to various embodiments of the present disclosure.
3 is a flowchart illustrating an example in which a UE accesses an ON-SNPN and performs mutual authentication with a DCS according to various embodiments of the present disclosure.
4A is a flowchart illustrating an example in which a UE accesses an ON-SNPN and performs mutual authentication with the ON-SNPN according to various embodiments of the present disclosure.
4B is a flowchart illustrating an additional authentication operation that may optionally be performed according to various embodiments of the present disclosure.
5A and 5B are flowcharts illustrating a provisioning process based on Option A of Case 1 according to various embodiments of the present disclosure.
6A and 6B are flowcharts illustrating a provisioning process based on Option B of Case 1 according to various embodiments of the present disclosure.
7A and 7B are flowcharts illustrating a provisioning process based on Option C of Case 1 according to various embodiments of the present disclosure.
8 is a flowchart illustrating a provisioning process based on Option D of Case 1 according to various embodiments of the present disclosure.
9 is a flowchart illustrating a provisioning process based on Option A of Case 2 according to various embodiments of the present disclosure.
10A and 10B are flowcharts illustrating a provisioning process based on Option B of Case 2 according to various embodiments of the present disclosure.
11 is a flowchart illustrating a provisioning process based on Option C of Case 2 according to various embodiments of the present disclosure.
12 is a flowchart illustrating a provisioning process based on Option D of Case 2 according to various embodiments of the present disclosure.
13A and 13B are flowcharts illustrating a provisioning process based on Option A of Case 3 according to various embodiments of the present disclosure.
14A and 14B are flowcharts illustrating a provisioning process based on Option B of Case 3 according to various embodiments of the present disclosure.
15A and 15B are flowcharts illustrating a provisioning process based on Option C of Case 3 according to various embodiments of the present disclosure.
16 is a flowchart illustrating a provisioning process based on Option D of Case 3 according to various embodiments of the present disclosure. FIG. 17 is a block diagram of a terminal according to various embodiments of the present disclosure.
18 is a block diagram of a network entity according to various embodiments of the present disclosure.

Hereinafter, various embodiments will be described in detail with accompanying drawings. In addition, in describing the embodiments of the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the embodiments, the detailed description will be omitted. In addition, terms to be described below are terms defined in consideration of functions in the embodiments, which may vary according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout this specification.

For the same reason, in the accompanying drawings, some components are exaggerated, omitted, or schematically illustrated. Also, the size of each component does not entirely reflect the actual size. In each figure, the same reference number is assigned to the same or corresponding component.

Advantages and features of the present disclosure, and methods for achieving them, will become clear with reference to embodiments described below in detail in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms, but only the present embodiments make the present disclosure complete, and those of ordinary skill in the art to which the present disclosure belongs It is provided to fully inform you of the scope of the disclosure, and the disclosure is only defined by the scope of the claims. Like reference numbers designate like elements throughout the specification.

At this time, it will be understood that each block of the process flow chart diagrams and combinations of the flow chart diagrams can be performed by computer program instructions. These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment are described in the flowchart block(s). Create means to perform functions. These computer program instructions may also be stored in a computer usable or computer readable memory that can be directed to a computer or other programmable data processing equipment to implement functionality in a particular way, such that the computer usable or computer readable memory The instructions stored in are also capable of producing an article of manufacture containing instruction means that perform the functions described in the flowchart block(s). The computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to generate computer or other programmable data processing equipment. Instructions for performing processing equipment may also provide steps for performing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is possible for the functions mentioned in the blocks to occur out of order. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in reverse order depending on their function.

At this time, the term '~unit' used in various embodiments of the present disclosure means software or a hardware component such as FPGA or ASIC, and '~unit' may perform certain roles. However, '~ part' is not limited to software or hardware. '~bu' may be configured to be in an addressable storage medium and may be configured to reproduce one or more processors. Therefore, as an example, '~unit' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Functions provided within components and '~units' may be combined into smaller numbers of components and '~units' or further separated into additional components and '~units'. In addition, components and '~units' may be implemented to play one or more CPUs in a device or a secure multimedia card.

Hereinafter, a base station is a subject that performs resource allocation of a terminal, and is an eNode B (eNB), Node B, base station (BS), radio access network (RAN), access network (AN), RAN node, NR NB, gNB, It may be at least one of a radio access unit, a base station controller, or a node on a network. A terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing communication functions. In various embodiments of the present disclosure, a case in which a terminal is a UE will be described as an example. In addition, although various embodiments of the present disclosure are described below using a system based on LTE, LTE-A, or NR as an example, various embodiments of the present disclosure may also be applied to other communication systems having a similar technical background or channel type. may be applied. In addition, various embodiments of the present disclosure can be applied to other communication systems through some modification within a range that does not greatly deviate from the scope at the discretion of a person with skilled technical knowledge.

Each function provided by the 5G network system may be performed in network function (NF) units. An example of the architecture of a 5G mobile communication network is shown in FIG. 1 .

1 is a diagram illustrating a structure of a 5G mobile communication network according to various embodiments of the present disclosure.

Referring to FIG. 1, a 5G mobile communication network includes an access and mobility management function (AMF) 120 that manages network access and mobility of a UE 110, and an SMF that performs functions related to a session for the UE 110 ( session management function) 130, a user plane function (UPF) 125 that is in charge of delivering user data and controlled by the SMF 130, and an application function (AF) that communicates with 5GC to provide application services. 180), a network exposure function (NEF) 170 supporting communication with the AF 180, a unified data management (UDM) 160 for data storage and management and a unified data repository (UDR) (not shown), policy It may include at least one of a policy and control function (PCF) 150 that manages the user data, or a data network (DN) 140 (eg, the Internet) through which user data is transmitted.

In addition to the above NFs, an operation, administration, and management (OAM) server (not shown), which is a system for managing the UE 110 and the 5G mobile communication network, may exist. And, in the 5G mobile communication network, at least one of a RAN (eg base station) 115, an authentication server function (AUSF) 165, a network slice selection function (NSSF) 175, or a network repository function (NRF) 155 may be further included.

2 is a diagram illustrating a structure of a network for provisioning credential information of a UE according to various embodiments of the present disclosure.

The network shown in FIG. 2 may be included in a wireless communication system (eg, ^5th generation system (5GS)), and is the same as at least one of components (eg, NFs) of the 5G mobile communication network shown in FIG. or contain similar components. For example, UE 210, NG-RAN 215, UPF 225, and DN 240 of FIG. 2 are UE 110, RAN 115, UPF 125, and DN 240 of FIG. DN 140. And, the AMF 220 and SMF 230 of FIG. 2 may be the AMF 120 and SMF 130 of FIG. 1 , respectively. In addition, the NSSF 270, UDM 275, NEF 280, NRF 285, and AUSF 290 of FIG. 2 are the NSSF 175, UDM 160, NEF 170, NRF (155), and AUSF (165).

According to an embodiment, UE 210, NG-RAN 215, UPF 225, DN 240, AMF 220, SMF 230, NSSF 270, UDM 275, NEF ( 280), NRF 285, and AUSF 290 may be included in ON-SNPN (Onboarding - Standalone Non-Public Network (SNPN)), PS (provisioning server) 260 SO-SNPN (Subscription Owner- SNPN) may be included.

According to various embodiments, based on the network structure shown in FIG. can be provisioned. In an embodiment, the UE 210 may receive SO-SNPN credentials from the PS 260 after performing an authentication operation. An authentication operation according to an embodiment includes an operation in which the UE 210 transmits a registration request to ON-SNPN and performs authentication with the DCS 250 using default credentials provisioned when the UE 210 is manufactured. can do. Alternatively, the authentication operation according to an embodiment may include an operation of selectively performing additional authentication with the DCS 250 after the UE 210 performs authentication with the ON-SNPN.

In this way, the UE 210 manufactured without SO-SNPN credentials makes a registration request to ON-SNPN in order to acquire the credentials of the SO-SNPN that it wants to receive service from, and then sends a DCS 250 based on the default credentials of the UE 210. ) or mutual authentication with ON-SNPN. The DCS 250 is a network or entity that authenticates the UE 210 and may exist inside or outside the ON-SNPN. The PS 260 is a network or entity having the SO-SNPN credential of the UE 260, and may be located inside or outside the ON-SNPN, and may exist in the same domain as the DCS 250 or a different domain.

Since the ON-SNPN does not have subscription information or subscription data of the UE 210, the UDM 275 of the ON-SNPN is used to authenticate the UE 210 or provision credentials. It may not be. Alternatively, the UDM 275 of the ON-SNPN may not exist in the ON-SNPN.

When an authentication operation is performed, if the DCS 250 is an authentication authorization accounting (AAA) server, a network slice-specific authentication and authorization function (NSSAAF) 295 is used for protocol conversion (SBI<->RADIUS). may be used When the authentication operation is successfully performed and access to the ON-SNPN is completed, the UE 210 may perform a provisioning process in which the SO-SNPN credential is provided from the PS 260 through the control plane. In the provisioning process, if the DCS 250 or PS 260 exists outside the ON-SNPN domain, the NEF 280 of the ON-SNPN may be used.

Hereinafter, operations according to various embodiments performed in the network environment shown in FIG. 2 will be described with reference to FIGS. 3 to 16 . Components (eg, UE, DCS, AMF, or PS) described in FIGS. 3 to 16 may correspond to the components shown in FIG. 2 .

3 is a flowchart illustrating an example in which a UE accesses an ON-SNPN and performs mutual authentication with a DCS according to various embodiments of the present disclosure.

The authentication operation shown in FIG. 3 may include a mutual authentication operation performed by a UE without SO-SNPN credentials with a DCS using default credentials. Various embodiments may be implemented by including at least one of the steps described below.

For the procedure shown in FIG. 3 , one or more of the following settings may be performed in advance.

(A1) 1st preset

The UE manufacturer can provision the UE with credentials to be used for mutual authentication with the DCS when manufacturing the UE.

(A2) 2nd preset

For the purpose of onboarding, UE manufacturers can provision DCS with credentials to be used for mutual authentication with UEs accessing ON-SNPN. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with the address of the PS that can provision the SO-SNPN's credentials to the UE. The address of the PS may be used when the DCS searches for the PS to trigger provisioning on the PS when provisioning is performed using the control plane. When AMF or AUSF triggers provisioning in the PS, the DCS may deliver it to the AUSF after authentication is completed between the UE and the DCS.

Referring to FIG. 3 , in step 301, first presetting A1 and second presetting A2 may be performed. The first presetting and the second presetting may be performed simultaneously, the first presetting may be performed prior to the second presetting, or the second presetting may be performed prior to the first presetting. The first preset and/or the second preset include a process necessary for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without the UE's subscription information, and later the UE It may include the process necessary to successfully receive SO-SNPN credentials from the PS.

In step 302, the NG-RAN may broadcast broadcast system information. Broadcast system information may be received by the UE. The broadcast system information may include one or more public land mobile network (PLMN) identifiers (ID), a network ID per PLMN ID, and an onboarding enabled indication. A combination of a PLMN ID and a Network ID may indicate a Non-Public Network (NPN).

In step 303, the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a Registration Request message to AMF/SEAF. Transmission of the registration request message may be triggered, for example, when a power-on event occurs in the UE or there is a user's input. The registration request message may include a registration type and an onboarding subscription concealed identifier (SUCI). The registration type may include "SNPN Onboarding" indicating that the UE does not have subscription information for the corresponding NPN. Onboarding SUCIs can have the format "username@realm". Here, the realm part may represent DCS.

In step 304, the AMF/SEAF may receive a registration request message from the UE and check the Onboarding SUCI included in the received registration request message. In addition, the AMF/SEAF may identify the DCS based on the realm part of the onboarding SUCI and transmit a first authentication request message to the AUSF capable of communicating with the identified DCS.

In step 305, AUSF may transmit a second authentication request message to the DCS based on the first authentication request message. The second authentication request message may include information included in the first authentication request message received by the AUSF in step 304, that is, the Onboarding SUCI. If the DCS is an AAA server, AUSF may transmit a second authentication request message to the DCS through NSSAAF for protocol conversion. ON-SNPN and DCS may have a contractual relationship. In addition, when the DCS exists outside the domain of the ON-SNPN, message exchange between the ON-SNPN and the DCS may be performed through NEF.

In step 306, the UE and the DCS may perform extensible authentication protocol (EAP) authentication (eg, EAP-transport layer security (TLS)).

In step 307, the DCS may transmit a first EAP response message to AUSF. The first EAP response message includes an authentication success message, an onboarding subscriber permanent identifier (SUPI) indicating the UE, and keying material for generating a key to be used for communication with the UE in ON-SNPN. can do. In addition, the first EAP response message may optionally include a PS address when AMF or AUSF triggers provisioning in the PS.

In step 308, AUSF may generate K_ausf based on the key material in the first EAP response message received in step 307.

In step 309, AUSF may transmit a second EAP response message to AMF/SEAF. The second EAP response message may include an authentication success message, K_seaf generated from K_ausf, and Onboarding SUPI. And, the second EAP response message may optionally include a PS address when the AMF/SEAF triggers provisioning in the PS.

In step 310, the AMF/SEAF may transmit a third EAP response message to the UE. The third EAP response message may include an authentication success message, a 5G key set identifier (ngKSI) indicating a key, and an ABBA parameter.

In step 311, the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 308.

In step 312, the UE and AMF/SEAF may perform a NAS (non access stratum) SMC (security mode command) process to activate the generated key. AMF/SEAF can know that the UE is capable of secure communication for ON-SNPN based on the NAS SMC process.

4A is a flowchart illustrating an example in which a UE accesses an ON-SNPN and performs mutual authentication with the ON-SNPN according to various embodiments of the present disclosure.

The authentication operation shown in FIG. 4A may include a mutual authentication operation performed with ON-SNPN using default credentials in order for a UE without SO-SNPN credentials to access ON-SNPN. Various embodiments may be implemented including at least one of the steps described below.

For the procedure shown in FIG. 4A , one or more of the following settings may be performed in advance.

(B1) 1st preset

The UE manufacturer can provision the UE with credentials to be used for mutual authentication with ON-SNPN when manufacturing the UE. Optionally, when additional authentication (hereinafter referred to as 'secondary authentication') is required, credentials to be used for mutual authentication between the UE and the DCS may be provisioned to the UE.

(B2) 2nd preset

The UE manufacturer may provision ON-SNPN with credentials to be used for mutual authentication with UEs accessing ON-SNPN for the purpose of onboarding. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the ON-SNPN with the address of the PS that can provision the UE with the credentials of the SO-SNPN. The address of the PS can be used when provisioning using the control plane is performed, when AMF or AUSF triggers provisioning on the PS, or when AMF or AUSF finds the PS. If a secondary authentication process is required between the UE and the DCS and the DCS can deliver the PS address to the ON-SNPN during that process, the process of provisioning the PS address to the ON-SNPN may not be performed.

(B3) 3rd Preset

When secondary authentication is required between the UE and the DCS, the UE manufacturer can provision the DCS with credentials to be used for mutual authentication with the UE. After the UE is sold to the SO-SNPN owner, the UE manufacturer can provision the DCS with the address of the PS that can provision the SO-SNPN's credentials to the UE. The address of the PS can be used when AMF, AUSF, or DCS finds the PS to trigger provisioning on the PS when provisioning is performed using the control plane.

Referring to FIG. 4A , in step 401, first presetting (B1), second presetting (B2), and third presetting (B3) may be performed. At least one of the first to third presets includes a process of provisioning information necessary for authentication in order for the UE to normally use the ON-SNPN when the UE accesses an ON-SNPN without subscription information of the UE; Later, in order for the UE to successfully receive SO-SNPN credentials from the PS, a process of receiving the PS address may be included.

In step 402, the NG-RAN may broadcast broadcast system information. Broadcast system information may be received by the UE. The broadcast system information may include one or more PLMN IDs, a network ID per PLMN ID, and an onboarding capability indication. A combination of PLMN ID and Network ID may represent NPN.

In step 403, the UE may select an ON-SNPN based on the broadcasting system information received from the NG-RAN and transmit a registration request message to AMF/SEAF. Transmission of the registration request message may be triggered, for example, when a power-on event occurs in the UE or there is a user's input. The registration request message may include registration type and onboarding SUCI. The registration type may include "SNPN Onboarding" indicating that the UE does not have subscription information for the corresponding NPN.

In step 404, the AMF/SEAF may select an AUSF based on the registration request message and transmit an authentication request to the AUSF. For example, the AMF/SEAF may identify a DCS based on the onboarding SUCI included in the registration request message and transmit an authentication request message to the AUSF capable of communicating with the identified DCS.

In step 405, the UE and AUSF may perform EAP authentication (eg, EAP-TLS).

In step 406, AUSF may generate K_ausf after authentication is completed.

In step 407, AUSF may transmit a first EAP response message to AMF/SEAF. The first EAP response message may include an authentication success message, K_seaf generated from K_ausf, and Onboarding SUPI. In addition, the first EAP response message may optionally include a PS address when the AMF/SEAF triggers provisioning in the PS.

In step 408, the AMF/SEAF may transmit a second EAP response message to the UE. The second EAP response message may include an authentication success message, ngKSI indicating a key, and an ABBA parameter.

In step 409, the UE may generate K_ausf using a method corresponding to the method in which AUSF generated K_ausf in step 406.

In step 410, the UE and AMF/SEAF may perform a NAS SMC process to activate the generated key. AMF/SEAF can know that the UE is capable of secure communication for ON-SNPN based on the NAS SMC process.

Following FIG. 4A, the authentication operation shown in FIG. 4B may be selectively performed.

4B is a flowchart illustrating an additional authentication operation that may optionally be performed according to various embodiments of the present disclosure.

The authentication operation shown in FIG. 4B may include secondary authentication between the UE and the DCS, and may be selectively performed following step 410 of FIG. 4A. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 4B, in step 411, the UE requests establishment of a protocol data unit (PDU) session through the SMF, and the SMF recognizes that secondary authentication is required during the PDU session establishment process and performs the corresponding process. You may.

In step 412, the SMF may transmit an EAP-Request/Identity request to the UE, and in step 413, the UE transmits a DN-specific identity (DN-specific identity) to the SMF in the form of a network access identifier (NAI) EAP-Request. It can be transmitted by including it in Response/Identity. The DN-specific identity transmitted by the UE to the SMF in step 413 may be the same as the onboarding SUCI provided by the UE to the AMF/SEAF in step 403 of FIG. 4A or the onboarding SUPI before protecting the onboarding SUCI.

In step 414, the SMF may transmit the EAP-Response/Identity received in step 413 to the DCS through UPF, and in step 415, the DCS and the UE may perform an EAP authentication process through transmission and reception of EAP request and response messages.

In step 416, if the EAP authentication is successful, the DCS may transmit an EAP success message together with the address of the PS to the SMF through the UPF. In step 416, the PS address may not be transmitted when the DCS triggers the provisioning process.

In step 417, the SMF may send the EAP success message (or the EAP success message and PS address) received in step 416 to the AMF.

In step 418, the AMF may transmit an EAP success message to the UE along with a PDU Session Establishment Accept message.

According to various embodiments, after the onboarding process or the mutual authentication process shown in FIG. 3 or 4 is performed, provisioning for obtaining credentials of the UE from the PS may be performed. According to various embodiments, provisioning by PS may be performed using a control plane. According to various embodiments, provisioning by PS may be triggered based on the following three cases.

- Case 1: DCS directly delivers Authentication Notification message to PS to trigger provisioning

- Case 2: AMF triggers provisioning by directly delivering an authentication notification message to PS

- Case 3: AUSF directly delivers authentication notification message to PS to trigger provisioning

Each of the three cases described above may include the following four options.

- Option A: UDM of ON-SNPN is determined not to be used, and DCS or PS plays the role of UDM in the UPU process

- Option B : UDM of ON-SNPN is determined to be used, and DCS or PS delivers credentials to UDM of ON-SNPN for UPU process

- Option C: It is decided that the UDM of ON-SNPN will not be used, and the UPU process is optimized to minimize communication between entities in different domains.

- Option D: When one of Option A, B, and C cannot be determined, and the ON-SNPN operator can decide which one to use among Option A, B, and C.

That is, according to various embodiments, processes for each case as shown in Table 1 below may be performed.

Hereinafter, the processes for each case will be described with reference to FIGS. 5A to 16. First, Case 1 (case in which the DCS directly delivers an authentication notification message to the PS to trigger provisioning) with reference to FIGS. 5A to 8 The processes that can be performed for will be described.

< Case 1 >

5A and 5B are flowcharts illustrating a provisioning process based on Option A of Case 1 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 5A and 5B is an operation in which the DCS directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN When it is determined that UDM is not used, the DCS acts as the UDM of the UPU process, and the UE successfully accessing the ON-SNPN receives SO-SNPN credentials from the PS using the control plane. there is. Various embodiments may be implemented by including at least one of the steps described below.

For the procedure shown in FIG. 5 , one or more of the following settings may be performed in advance.

(C1) First presetting

For mutual authentication between the UE and the ON-SNPN or between the UE and the DCS, the first and second presets of FIG. 3 or the first to third presets of FIG. 4 may be performed.

(C2) Second Preset

The UE manufacturer may provide the PS with the ID (eg, onboarding SUPI, international mobile equipment identity (IMEI), etc.) of the UE sold to the SO-SNPN owner. The PS stores the UE ID and can later use it to find the SO-SNPN credentials to be provided to the UE with the corresponding UE ID.

Referring to FIG. 5 , in step 501, first presetting C1 and second presetting C2 may be performed. The first presetting (C1) may include a process required for successful authentication with the help of a DCS capable of authenticating the UE when the UE accesses an ON-SNPN without subscription information of the UE. The first presetting (C1) and the second presetting (C2) may include a process of provisioning the DCS and the PS with information necessary for the UE to successfully receive SO-SNPN credentials from the PS later.

In step 502, the UE may perform mutual authentication with the ON-SNPN or DCS using the information provided by the first preset (C1). In step 502, the onboarding process shown in FIG. 3 or 4 may be performed. Communication between the DCS and the NFs of the ON-SNPN in a later step may be performed through the NEF of the ON-SNPN.

In step 503, the AMF/SEAF may determine to notify of a successful message if the UE successfully completes the onboarding process in step 502. AMF/SEAF may make a corresponding decision based on NAS SMC when the onboarding process based on FIG. 3 is performed, and NAS SMC or PDU Session Establishment Acceptance (PDU Session Establishment) when onboarding process based on FIG. 4 is performed. Accept) message to make that decision.

In step 504, the AMF/SEAF may transmit a first authentication notification message for providing the result of step 502 to AUSF. The first authentication notification message may include information indicating that the UE has successfully completed the onboarding process and/or an ID of the UE that has successfully completed the onboarding process. The UE ID may be, for example, Onboarding SUPI, IMEI, or other ID that the PS can identify.

In step 505, AUSF may transmit a second authentication notification message to DCS. The second authentication notification message may include a UE ID and an AUSF address and an AMF address required for the DCS to perform the UPU process. In addition, the second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 506, the DCS may find a UE ID and a matching PS address based on the second authentication notification message received in step 505. Here, the PS address may be a PS address stored through the first presetting in step 501 . The DCS may store the AUSF address and AMF address included in the second authentication notification message.

In step 507, the DCS may transmit a third authentication notification message to the PS as an authentication completion message using the PS address found in step 506. The third authentication notification message may include the UE ID.

In step 508, the PS may compare the UE ID included in the third authentication notification message received in step 507 with the UE ID provided from the UE manufacturer through the second preset in step 501. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the third authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 501, the PS may search for SO-SNPN credentials to be provided to the UE.

Step 509 of FIG. 5B may be performed following step 508 of FIG. 5A .

Referring to FIG. 5B, in step 509, the PS may transmit a provisioning request message to the DCS. The provisioning request message may include the credentials of the SO-SNPN found in step 508 of FIG. 5A and the UE ID.

In step 510, the DCS may determine to perform the UDM role in the UPU process based on "determination that the DCS will act as the UDM in the UPU process for the provisioning process", and may perform a UPU process described later.

In step 511, the DCS may start the UPU process by finding an AUSF based on the AUSF address stored in step 506 of FIG. 5A. The DCS may send the Nausf_UPUPProtection message to the AUSF corresponding to the stored AUSF address. The Nausf_UPUPProtection message may include Onboarding SUPI and UPU data (SO-SNPN credentials). The DCS may add an ACK indication to the Nausf_UPUProtection message to check whether the UE has successfully received UPU data.

In step 512, AUSF may transmit a Nausf_UPUProtection Response message to the DCS in response to the Nausf_UPUProtection message. The Nausf_UPUProtection Response message may include UPU-MAC-I_ausf, which is a MAC value of UPU data provided by DCS, calculated by AUSF using K_ausf, and Counter_upu, which is a Counter value. Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.

The Nausf_UPUProtection Response message may include UPU-XMAC-I_ue when the ACK indication is included in the Nausf_UPUProtection message.

In step 513, the DCS may search for an AMF based on the AMF address stored in step 506 and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may include UPU data, UPU-MAC-I_ausf received from AUSF in step 512, and Counter_upu. According to various embodiments, a new service may be defined instead of the Nudm_SDM_Notification service in order for the DCS to perform the UDM role of the UPU process.

In step 514, AMF may transmit DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 515, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value in the method calculated by AUSF in step 512 using the UPU data and Counter_upu, and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 516, if the ACK indication is provided in step 511 and if it is successfully confirmed that the UPU data is not modulated in step 515, the UE can transmit a UL NAS Transport message including the calculated UPU-MAC-I_ue to AMF. there is. UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 517, the AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to the DCS through the Nudm_SDM_Info message.

In step 518, the DCS compares the UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 512, and based on the comparison result, it can be confirmed that the UE has successfully received UPU data. In step 517, a new service may be defined instead of the Nudm_SDM_Info service for the DCS performing the UDM role of the UPU process.

6A and 6B are flowcharts illustrating a provisioning process based on Option B of Case 1 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 6A and 6B is an operation in which the DCS directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN An operation in which UDM is used when it is determined that UDM is used, and an operation in which a UE successfully accessing ON-SNPN receives SO-SNPN credentials from a PS using a control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 6A , steps 601 and 602 of FIG. 6A correspond to steps 501 and 502 of FIG. 5A , so detailed description thereof will be omitted. However, during mutual authentication between the UE and the ON-SNPN or DCS in step 602 of FIG. 6A, or after successful completion, the UDM of the ON-SNPN is the UE's ID (eg, Onboarding SUPI, IMEI, etc.), the corresponding UE The AMF ID serving the UE, the AUSF ID serving the corresponding UE, and the like may be stored. Communication between the DCS and NFs of the ON-SNPN in a later step may be performed through the NEF of the ON-SNPN.

In step 603, the AMF/SEAF may determine to notify of a successful message if the UE successfully completes the onboarding process in step 602. AMF/SEAF may make a corresponding decision based on NAS SMC when the onboarding process based on FIG. 3 is performed, and NAS SMC or PDU Session Establishment Acceptance (PDU Session Establishment) when onboarding process based on FIG. 4 is performed. Accept) message to make that decision.

In step 604, the AMF/SEAF may transmit a first authentication notification message for providing the result of step 603 to AUSF. The first authentication notification message may include information indicating that the UE has successfully completed the onboarding process and/or an ID of the UE that has successfully completed the onboarding process. The UE ID may be, for example, Onboarding SUPI, IMEI, or other ID that the PS can identify.

In step 605, AUSF may transmit a second authentication notification message to DCS. The second authentication notification message may include a UE ID and a UDM address necessary for the DCS to request a UPU process to the UDM of the ON-SNPN. In addition, the second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 606, the DCS may find a UE ID and a PS address matching thereto based on the second authentication notification message received in step 605. Here, the PS address may be a PS address stored through the first presetting in step 601 . The DCS may store the UDM address included in the second authentication notification message.

In step 607, the DCS may transmit a third authentication notification message to the PS as an authentication completion message using the PS address found in step 606. The third authentication notification message may include the UE ID.

In step 608, the PS may compare the UE ID included in the third authentication notification message received in step 607 with the UE ID provided from the UE manufacturer through the second preset setting in step 601. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the third authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 601, the PS may find the SO-SNPN credential to be provided to the UE.

Step 609 of FIG. 6B may be performed following step 608 of FIG. 6A .

Referring to FIG. 6B , in step 609, the PS may transmit a provisioning request message to the DCS. The provisioning request message may include the credentials of the SO-SNPN found in step 608 of FIG. 6A and the UE ID.

In step 610, the DCS may determine that the DCS should transfer the information received in step 609 to the UDM for the UPU process based on "determination that the UDM of the ON-SNPN will be used for the provisioning process". The UPU process described below may be performed by the UDM.

In step 611, the DCS may search for a UDM based on the UDM address stored in step 606 and transmit a provisioning request message to the corresponding UDM. The provisioning request message may include UE ID and SO-SNPN credentials.

In step 612, the UDM may start the UPU process by finding an AUSF serving the UE. The UDM may send a Nausf_UPUPProtection message to AUSF. The Nausf_UPUPProtection message may include Onboarding SUPI and UPU data (SO-SNPN credentials). UDM may add an ACK indication to the Nausf_UPUProtection message to check whether the UE has successfully received UPU data.

In step 613, AUSF may transmit a Nausf_UPUProtection Response message to the UDM in response to the Nausf_UPUProtection message. The Nausf_UPUProtection Response message may include UPU-MAC-I_ausf, which is a MAC value of UPU data provided by UDM calculated by AUSF using K_ausf, and Counter_upu, which is a Counter value. Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.

The Nausf_UPUProtection Response message may include UPU-XMAC-I_ue when the ACK indication is included in the Nausf_UPUProtection message.

In step 614, the UDM may search for an AMF serving the UE and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may include UPU data, UPU-MAC-I_ausf received from AUSF in step 613, and Counter_upu.

In step 615, AMF may send a DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 616, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value in the method calculated by AUSF in step 613 using the UPU data and Counter_upu, and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 617, if the ACK indication is provided in step 612 and if it is successfully confirmed that the UPU data is not modulated in step 616, the UE can transmit a UL NAS Transport message including the UPU-MAC-I_ue calculated in AMF. there is. UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 618, AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to UDM through a Nudm_SDM_Info message.

In step 619, the UDM compares the UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 613, and based on the comparison result, it can be confirmed that the UE has successfully received UPU data.

7A and 7B are flowcharts illustrating a provisioning process based on Option C of Case 1 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 7A and 7B is an operation in which the DCS directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN Operation when it is determined that UDM is not used, operation when it is determined to perform an optimized UPU process to minimize communication between entities in different domains, and a UE successfully accessing ON-SNPN receives SO-SNPN from PS It may include an operation of receiving the credential of using the control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 7A , steps 701 to 704 of FIG. 7A correspond to steps 501 to 504 of FIG. 5A and thus detailed description thereof will be omitted.

In step 705, AUSF may transmit a second authentication notification message to DCS. The second authentication notification message may include a UE ID and an AUSF address necessary for the DCS to perform the UPU process. In addition, the second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 706, the DCS may find a UE ID and a PS address matching thereto based on the second authentication notification message received in step 705. Here, the PS address may be a PS address stored through the first presetting in step 501 . The DCS may store the AUSF address included in the second authentication notification message.

In step 707, the DCS may transmit a third authentication notification message as an authentication completion message to the PS using the PS address found in step 706. The third authentication notification message may include the UE ID.

In step 708, the PS may compare the UE ID included in the third authentication notification message received in step 707 with the UE ID provided from the UE manufacturer through the second preset in step 701. Based on the comparison result, the PS may check whether the UE may receive the SO-SNPN credential. For example, if the UE ID included in the third authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 501, the PS may search for SO-SNPN credentials to be provided to the UE.

Step 709 of FIG. 7B may be performed following step 708 of FIG. 7A .

Referring to FIG. 7B , in step 709, the PS may transmit a provisioning request message to the DCS. The provisioning request message may include the credentials of the SO-SNPN found in step 708 of FIG. 7A and the UE ID.

In step 710, the DCS may request the AUSF for a UPU process based on "decision to proceed with an optimized UPU process to minimize communication between entities in different domains". Accordingly, the UPU process described later may be performed by AUSF.

In step 711, the DCS may search for an AUSF based on the AUSF address stored in step 706 of FIG. 7A and request a UPU process. The DCS may send the Nausf_UPUPProtection message to the AUSF corresponding to the stored AUSF address. The Nausf_UPUPProtection message may include Onboarding SUPI and UPU data (SO-SNPN credentials). The DCS may add an ACK indication to the Nausf_UPUProtection message to check whether the UE has successfully received UPU data.

In step 712, AUSF may transmit a Nausf_UPUProtection Response message to the DCS in response to the Nausf_UPUProtection message. When AUSF receives the Nausf_UPUProtection message including the ACK indication in step 711, it may transmit a Nausf_UPUPProtection Response message including UPU-XMAC-I_ue to the DCS.

In step 713, AUSF may find an AMF and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may deliver UPU data, UPU-MAC-I_ausf calculated based on K_ausf using the UPU data received in step 711, and Counter_upu. Counter_upu can start at 0x00 0x00 and increment each time UPU-MAC-I_ausf is calculated, preventing replay attacks. A new service may be defined instead of the Nudm_SDM_Notification service to perform the optimized UPU process.

In step 714, AMF may transmit DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 715, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value by the method calculated by AUSF after step 711 using the UPU data and Counter_upu, and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 716, if the ACK indication is provided in step 711 and if it is successfully confirmed that the UPU data is not modulated in step 715, the UE can transmit a UL NAS Transport message including the calculated UPU-MAC-I_ue to AMF. there is. UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 717, AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to AUSF through a Nudm_SDM_Info message.

In step 718, the AUSF may transmit the Nudm_SDM_Info message received in step 717 to the DCS.

In step 719, the DCS compares the UPU-MAC-I_ue and UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 712, and based on the comparison result, indicates that the UE has successfully received UPU data. You can check.

8 is a flowchart illustrating a provisioning process based on Option D of Case 1 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIG. 8 is an operation in which the DCS directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, use of the UDM of ON-SNPN Depending on whether or not to use UDM is determined by the operator of ON-SNPN or whether an optimized UPU process is to be used, AUSF provides an indicator to DCS to use the control plane. It may include an operation for which the UPU process is determined. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 8 , steps 801 to 804 of FIG. 8 correspond to steps 501 to 504 of FIG. 5A , so detailed description thereof will be omitted.

In step 805, AUSF may transmit a second authentication notification message to DCS. The second authentication notification message may include a UE ID, an indicator for selecting a UPU process followed by a DCS, and an NF address (s) necessary for the UPU process. In addition, the second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

An indicator included in the second authentication notification message may indicate one of set values. For example, the indicator may indicate a value indicating one of Option A, Option B, and Option C of Case 1.

If the operator of ON-SNPN does not want to provide the use of UDM in the onboarding and provisioning process or if it is determined that the UDM of ON-SNPN will not be used in the process, the indicator is a value indicating Option A of Case 1 ( Example: "1"). When the indicator indicates "1", "UDM of ON-SNPN is not used, DCS plays the UDM role of UPU process" of FIGS. 5A and 5B and AUSF can provide DCS with AUSF address and AMF address. there is.

If the operator of ON-SNPN allows the use of UDM or it is determined that the UDM of ON-SNPN is used in the corresponding process, the indicator may indicate a value indicating Option B of Case 1 (eg, “2”). If the indicator indicates “2”, “the UDM of ON-SNPN is used and the UDM of ON-SNPN plays the role of the UDM in the UPU process” of FIGS. 6A and 6B, and AUSF may provide the UDM address to the DCS.

When it is determined to proceed with the optimized UPU process, the indicator may indicate a value indicating Option C of Case 1 (eg, "3"). If the indicator indicates "3", "ON-SNPN's UDM is not used and an optimized UPU process is performed" of FIGS. 7A and 7B , and AUSF may provide the AUSF address to the DCS.

In step 806, the DCS may find a UE ID and a PS address matching thereto based on the second authentication notification message received in step 805. Here, the PS address may be a PS address stored through the first presetting in step 801 . The DCS may store an indicator included in the second authentication notification message received from AUSF in step 805 and NF address(es) according to the indicator.

In step 807, the DCS may transmit a third authentication notification message to the PS as an authentication completion message using the PS address found in step 806. The third authentication notification message may include the UE ID.

In step 808, the PS may compare the UE ID included in the third authentication notification message received in step 807 with the UE ID provided from the UE manufacturer through the second preset in step 801. Based on the comparison result, the PS may check whether the UE may receive the SO-SNPN credential. For example, if the UE ID included in the third authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 501, the PS may search for SO-SNPN credentials to be provided to the UE.

In step 809, the PS may transmit a provisioning request message to the DCS. The provisioning request message may include the credentials of the SO-SNPN found in step 808 and the UE ID.

In step 810, the DCS may perform steps 510 to 518 of FIG. 5B when the indicator stored in step 806 indicates “1”. In addition, the DCS may perform steps 610 to 619 of FIG. 6B when the indicator stored in step 806 indicates "2". In addition, the DCS may perform steps 710 to 719 of FIG. 7B and end the UPU process when the indicator stored in step 806 indicates "3".

Next, processes that can be performed for Case 2 (case in which AMF triggers provisioning by directly delivering an authentication notification message to PS) will be described with reference to FIGS. 9 to 12 .

< Case 2 >

9 is a flowchart illustrating a provisioning process based on Option A of Case 2 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIG. 9 is an operation in which the AMF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing the UPU process in provisioning using the control plane, the UDM of ON-SNPN is used. It may include an operation when it does not work, and an operation in which the UE successfully accessing the ON-SNPN receives SO-SNPN credentials from the PS using the control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 9 , since steps 901 to 903 of FIG. 9 correspond to steps 501 to 503 of FIG. 5A , detailed description thereof will be omitted.

In step 904, when the result of step 902 is successful, the AMF/SEAF searches for a PS based on the PS address obtained in step 902 and can transmit an authentication notification message to the corresponding PS. The authentication notification message may include the UE ID and the AUSF address and AMF address required for the PS to perform the UPU process. The authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 905, the PS may compare the UE ID included in the authentication notification message received in step 904 with the UE ID provided from the UE manufacturer through the second preset setting in step 901. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 901, the PS may find the credentials of the SO-SNPN to be provided to the UE. If it is determined that the UDM of the ON-SNPN is not used in the provisioning process using the control plane, the PS may confirm that the PS should perform the role of the UDM in the UPU process based on the determination.

In step 906, the PS searches for an AUSF using the address of the AUSF received in step 904, and may transmit a Nausf_UPUPProtection message to the AUSF corresponding to the received AUSF address. The Nausf_UPUPProtection message may include the credentials of the SO-SNPN found by the PS in step 905 and the UE ID.

The PS may add an ACK indication to the Nausf_UPUProtection message to check whether the UE has successfully received UPU data.

In step 907, AUSF may transmit a Nausf_UPUPProtection Response message to the PS in response to the Nausf_UPUProtection message. The Nausf_UPUProtection Response message may include UPU-MAC-I_ausf, which is the MAC value of the UPU Data provided by the PS calculated by AUSF using K_ausf, and Counter_upu, which is the Counter value. Counter_upu is a value that starts from 0x00 0x00 and increases each time UPU-MAC-I_ausf is calculated, and can prevent replay attacks.

The Nausf_UPUProtection Response message may include UPU-XMAC-I_ue when the ACK indication is included in the Nausf_UPUProtection message.

In step 908, the PS may search for an AMF based on the AMF address received in step 904 and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may include UPU data, UPU-MAC-I_ausf received from AUSF in step 907, and Counter_upu. According to various embodiments, a new service may be defined instead of the Nudm_SDM_Notification service in order for the PS to perform the UDM role of the UPU process.

In step 909, AMF may transmit DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 910, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value in the method calculated by AUSF in step 907 using the UPU data and Counter_upu and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 911, if the ACK indication is provided in step 906 and if it is successfully confirmed that the UPU data is not modulated in step 910, the UE can transmit a UL NAS Transport message including the calculated UPU-MAC-I_ue to AMF. there is. UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 912, the AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to the PS through the Nudm_SDM_Info message.

In step 913, the PS compares the UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 907, and based on the comparison result, it can be confirmed that the UE has successfully received UPU data.

10A and 10B are flowcharts illustrating a provisioning process based on Option B of Case 2 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 10A and 10B is an operation in which the AMF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN An operation in which UDM is used when it is determined that UDM is used, and an operation in which a UE successfully accessing ON-SNPN receives SO-SNPN credentials from a PS using a control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 10A, steps 1001 to 1003 of FIG. 10A correspond to steps 501 to 503 of FIG. 5A, so detailed description thereof will be omitted.

In step 1004, when the result of step 1002 is successful, the AMF/SEAF searches for a PS based on the PS address acquired in step 1002 and transmits an authentication notification message to the corresponding PS. The authentication notification message may include the UE ID and the address of the UDM required for the PS to request the UDM of the ON-SNPN for the UPU procedure. The authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1005, the PS may compare the UE ID included in the authentication notification message received in step 1004 with the UE ID provided from the UE manufacturer through the second preset setting in step 1001. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 1001, the PS may find the SO-SNPN credentials to be provided to the UE. If it is determined that the UDM of the ON-SNPN is used in the provisioning process using the control plane, the PS may confirm that the PS needs to request provisioning from the UDM of the ON-SNPN based on the decision.

Step 1006 of FIG. 10B may be performed following step 1005 of FIG. 10A. Referring to FIG. 10B, in step 1006, the PS searches for a UDM using the address of the UDM received in step 1004, and requests provisioning to the corresponding UDM ( Provisioning Request) message can be transmitted. The provisioning request message may include the UE ID and credentials of the SO-SNPN found in step 1005.

In step 1007, the UDM may perform a UPU process based on the UE ID and SO-SNPN credentials received in step 1006. The UDM may find an AUSF serving the UE and send a Nausf_UPUPProtection message to the AUSF. The Nausf_UPUPProtection message may include Onboarding SUPI and UPU data (SO-SNPN credentials). UDM may add an ACK indication to the Nausf_UPUProtection message in order to check whether the UE has successfully received UPU data.

In step 1008, AUSF may transmit a Nausf_UPUPProtection Response message to the UDM in response to the Nausf_UPUPProtection message. The Nausf_UPUProtection Response message may include UPU-MAC-I_ausf, which is the MAC value of the UPU Data provided by the UDM calculated by AUSF using K_ausf, and Counter_upu, which is the Counter value. Counter_upu starts at 0x00 0x00 and increments each time UPU-MAC-I_ausf is calculated, which can prevent replay attacks.

The Nausf_UPUProtection Response message may include UPU-XMAC-I_ue when the ACK indication is included in the Nausf_UPUProtection message.

In step 1009, the UDM may search for an AMF serving the UE and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may include UPU data, UPU-MAC-I_ausf and Counter_upu received from AUSF in step 1008 .

In step 1010, AMF may transmit DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 1011, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value in the manner calculated by AUSF in step 1008 using the UPU data and Counter_upu, and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 1012, if the ACK indication is provided in step 1007 and if it is successfully confirmed that the UPU data is not modulated in step 1011, the UE can transmit a UL NAS Transport message including the calculated UPU-MAC-I_ue to AMF. there is. UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 1013, the AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to the DCS through the Nudm_SDM_Info message.

In step 1014, the UDM compares the UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 1008, and based on the comparison result, it can be confirmed that the UE has successfully received UPU data.

11 is a flowchart illustrating a provisioning process based on Option C of Case 2 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIG. 11 is an operation in which the AMF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing the UPU process in provisioning using the control plane, the UDM of the ON-SNPN is used. operation when it is determined not to, operation when it is determined to perform an optimized UPU process to minimize communication between entities in different domains, and a UE successfully accessing ON-SNPN obtains SO-SNPN credentials from the PS. It may include an operation provided using the control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 11 , steps 1101 to 1103 of FIG. 11 correspond to steps 501 to 503 of FIG. 5A , so detailed description thereof will be omitted.

In step 1104, when the result of step 1102 is successful, the AMF/SEAF searches for a PS based on the PS address acquired in step 1102 and transmits an authentication notification message to the corresponding PS. The authentication notification message may include a UE ID and an AUSF address required for the PS to perform the UPU process. The authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1105, the PS may compare the UE ID included in the authentication notification message received in step 1104 with the UE ID provided from the UE manufacturer through the second preset setting in step 1101. Based on the comparison result, the PS can check whether the corresponding UE is provided even if it receives the SO-SNPN credential. For example, if the UE ID included in the authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 1001, the PS may find the SO-SNPN credentials to be provided to the UE. The PS may request the UPU process from the AUSF based on "decision to proceed with the UPU process optimized to minimize communication between entities in different domains". Accordingly, the UPU process described later may be performed by AUSF.

In step 1106, the PS may search for AUSF using the AUSF address received in step 1104 and transmit a Nausf_UPUPProtection message to AUSF. The Nausf_UPUPProtection message may include the credentials of the SO-SNPN found in step 1105 and the UE ID. The PS may add an ACK indication to the Nausf_UPUProtection message in order to check whether the UE has successfully received UPU data.

In step 1107, AUSF may transmit a Nausf_UPUProtection Response message to the PS in response to the Nausf_UPUProtection message. The Nausf_UPUProtection Response message may include UPU-XMAC-I_ue when the ACK indication is included in the Nausf_UPUProtection message.

In step 1108, AUSF may find an AMF and transmit a Nudm_SDM_Notification message to the corresponding AMF. The Nudm_SDM_Notification message may include UPU data, UPU-MAC-I_ausf calculated with K_ausf using the UPU data received in step 1106, and Counter_upu. Counter_upu starts at 0x00 0x00 and increments each time UPU-MAC-I_ausf is calculated, which can prevent replay attacks. According to various embodiments, a new service may be defined instead of the Nudm_SDM_Notification service to perform an optimized UPU process.

In step 1109, AMF may transmit DL NAS Transport to the UE. The DL NAS Transport message may include UPU data, UPU-MAC-I_ausf, and Counter_upu.

In step 1110, the UE may perform an operation to verify UPU-MAC-I_ausf. For example, the UE may calculate the MAC value in the manner calculated by AUSF after step 1107 using the UPU data and Counter_upu and compare it with UPU-MAC-I_ausf. And, the UE can confirm that the UPU data is not modulated based on the comparison result.

In step 1111, if the ACK indication is provided in step 1106 and if it is successfully confirmed that the UPU data is not modulated in step 1110, the UE can transmit a UL NAS Transport message including the calculated UPU-MAC-I_ue to AMF. Yes UPU-MAC-I_ue can be calculated by the UE using K_ausf based on Counter_upu and UPU Acknowledgement. For example, the UE may be calculated by the UE using K_ausf and a result of using Counter_upu and UPU Acknowledgement as input values of a configured function (eg, Key Derivation Function (Counter_upu, UPU Acknowledgement, ...)). there is.

In step 1112, the AMF may transmit UPU-MAC-I_ue included in the UL NAS Transport message to the PS through the Nudm_SDM_Info message.

In step 1113, the PS compares the UPU-MAC-I_ue included in the Nudm_SDM_Info message with the UPU-XMAC-I_ue received in step 1107, and based on the comparison result, it can be confirmed that the UE has successfully received UPU data.

12 is a flowchart illustrating a provisioning process based on Option D of Case 2 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIG. 12 is an operation in which the AMF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, use of the UDM of ON-SNPN Depending on the operation when it is not decided, whether to use UDM is determined by the operator of ON-SNPN or whether the optimized UPU process is to be used, AMF provides an indicator to the DCS to perform the UPU process using the control plane. Actions to be determined may be included. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 12 , since steps 1201 to 1203 of FIG. 12 correspond to steps 501 to 503 of FIG. 5A , detailed description thereof will be omitted.

In step 1204, when the result of step 1202 is successful, the AMF may search for a PS using the PS address received in step 1202 and transmit an authentication notification message to the corresponding PS. The authentication notification message may deliver the UE ID, an indicator for selecting a UPU process to be followed by the PS, and the address (s) of the NF required for the UPU process to the PS. The UE ID may be an Onboarding SUPI, IMEI, or other ID that the PS can identify. The authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

An indicator included in the authentication notification message may indicate one of set values. For example, the indicator may indicate a value indicating one of Option A, Option B, and Option C of Case 2.

If the operator of ON-SNPN does not want to provide the use of UDM in the onboarding and provisioning process or if it is determined that the UDM of ON-SNPN will not be used in that process, the indicator is a value indicating Option A of Case 2 ( Example: "1"). If the indicator indicates "1", "the UDM of ON-SNPN is not used, the PS plays the UDM role of the UPU process" of FIG. 9 and the AMF may provide the AUSF address and the AMF address to the PS.

If the operator of ON-SNPN allows the use of UDM or it is determined that the UDM of ON-SNPN is used in the corresponding process, the indicator may indicate a value indicating Option B of Case 2 (eg, “2”). If the indicator indicates "2", "the UDM of ON-SNPN is used, and the UDM of ON-SNPN plays the role of the UDM in the UPU process" of FIGS. 10A and 10B, and the AMF may provide the UDM address to the PS. .

When it is determined to proceed with the optimized UPU process, the indicator may indicate a value indicating Option C of Case 2 (eg, "3"). When the indicator indicates “3”, “ON-SNPN UDM is not used and an optimized UPU process is performed” in FIG. 11 and the AMF may provide the AUSF address to the DCS.

In step 1205, the PS may perform steps 905 to 913 of FIG. 9 when the indicator received in step 1204 indicates “1”. And, when the indicator received in step 1204 indicates "2", the PS may perform steps 1005 to 1014 of FIGS. 10A and 10B. In addition, when the indicator received in step 1204 indicates "3", the PS may perform steps 1105 to 1113 of FIG. 11 and end the UPU process.

Next, with reference to FIGS. 13A to 16 , processes that can be performed for Case 3 (case in which AUSF directly delivers an authentication notification message to PS to trigger provisioning) will be described.

< Case 3 >

13A and 13B are flowcharts illustrating a provisioning process based on Option A of Case 3 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 13A and 13B is an operation in which the AUSF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN It may include an operation when UDM is not used, and an operation in which a UE successfully accessing ON-SNPN receives SO-SNPN credentials from a PS using a control plane. It can be implemented including at least one.

Referring to FIG. 13A, steps 1301 to 1303 of FIG. 13A correspond to steps 501 to 503 of FIG. 5A, so detailed descriptions thereof will be omitted.

In step 1304, AMF may transmit a first authentication notification message to AUSF. The first authentication notification message may include the UE ID. In addition, the first authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1305, AUSF may search for a PS using the PS address obtained in step 1302 and transmit a second authentication notification message to the corresponding PS. The second authentication notification message may include the UE ID received in step 1304 and the AUSF address and AMF address required for the PS to perform the UPU process. The second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1306, the PS may compare the UE ID included in the second authentication notification message received in step 1305 with the UE ID provided from the UE manufacturer through the second preset setting in step 1301. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the second authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 1301, the PS may search for SO-SNPN credentials to be provided to the UE. If it is determined that the UDM of the ON-SNPN is not used in the provisioning process using the control plane, the PS may confirm that the PS should perform the role of the UDM in the UPU process based on the determination.

Step 1307 of FIG. 13B may be performed following step 1306 of FIG. 13A. Steps 1307 to 1314 of FIG. 13B correspond to steps 906 to 913 of FIG. 9, so detailed description thereof will be omitted.

14A and 14B are flowcharts illustrating a provisioning process based on Option B of Case 3 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 14a and 14b includes an operation in which the AUSF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN An operation in which UDM is used when it is determined that UDM is used, and an operation in which a UE successfully accessing ON-SNPN receives SO-SNPN credentials from a PS using a control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 14A, steps 1401 to 1403 of FIG. 14A correspond to steps 501 to 503 of FIG. 5A, and thus detailed description thereof will be omitted.

In step 1404, AMF/SEAF may transmit a first authentication notification message to AUSF. The first authentication notification message may include the UE ID. In addition, the first authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1405, AUSF may search for a PS using the PS address obtained in step 1402 and transmit a second authentication notification message to the corresponding PS. The second authentication notification message may include the UE ID received in step 1404 and the UDM address required for the PS to perform the UPU process. The second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1406, the PS may compare the UE ID included in the second authentication notification message received in step 1405 with the UE ID provided from the UE manufacturer through the second preset setting in step 1401. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the second authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 1401, the PS may find the SO-SNPN credential to be provided to the UE. If it is determined that the UDM of the ON-SNPN is used in a provisioning process using the control plane, the PS may confirm that the PS needs to request provisioning from the UDM of the ON-SNPN based on the determination.

Step 1407 of FIG. 14B may be performed following step 1406 of FIG. 14A. Steps 1407 to 1415 of FIG. 14B correspond to steps 1006 to 1014 of FIG. 10B, so detailed description thereof will be omitted.

15A and 15B are flowcharts illustrating a provisioning process based on Option C of Case 3 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIGS. 15A and 15B includes an operation in which the AUSF directly delivers an authentication notification message to the PS to trigger provisioning, and when performing a UPU process in provisioning using the control plane, ON-SNPN Operation when it is determined that UDM is not used, operation when it is determined to perform an optimized UPU process to minimize communication between entities in different domains, and a UE successfully accessing ON-SNPN receives SO-SNPN from PS It may include an operation of receiving the credential of using the control plane. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 15A, steps 1501 to 1503 of FIG. 15A correspond to steps 501 to 503 of FIG. 5A, so detailed description thereof will be omitted.

In step 1504, AMF may transmit a first authentication notification message to AUSF. The first authentication notification message may include the UE ID. In addition, the first authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1505, AUSF may search for a PS using the PS address received in step 1502 and transmit a second authentication notification message to the corresponding PS. The second authentication notification message may include the UE ID received in step 1504 and an AUSF address required for the PS to perform the UPU process. The second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1506, the PS may compare the UE ID included in the second authentication notification message received in step 1505 with the UE ID wprhd received from the UE manufacturer through the second preset in step 1501. Based on the comparison result, the PS can check whether the corresponding UE can receive the SO-SNPN credential. For example, if the UE ID included in the second authentication notification message corresponds to the UE ID provided from the UE manufacturer in step 1501, the PS may find the SO-SNPN credential to be provided to the UE. The PS may request the UPU process from the AUSF based on "decision to proceed with the UPU process optimized to minimize communication between entities in different domains". The UPU process described below may be performed by AUSF.

Step 1507 of FIG. 15B may be performed following step 1306 of FIG. 15A. Steps 1507 to 1512 and 1515 of FIG. 15B may correspond to steps 1106 to 1111 and 1113 of FIG. 11 . However, in step 1112 of FIG. 11, the AMF may directly transmit the Nudm_SDM_Info message including UPU-MAC-I_ue to the PS, but in step 1513 of FIG. 15B, the AMF sends the Nudm_SDM_Info message including UPU-MAC-I_ue through AUSF. It can be sent to PS. 16 is a flowchart illustrating a provisioning process based on Option D of Case 3 according to various embodiments of the present disclosure.

According to various embodiments, the process shown in FIG. 16 is an operation in which AUSF directly delivers an authentication notification message to a PS to trigger provisioning, and when performing a UPU process in provisioning using a control plane, use of UDM of ON-SNPN Depending on the operation when it is not decided, whether to use UDM is determined by the operator of ON-SNPN or whether the optimized UPU process is to be used, AMF provides an indicator to the DCS to perform the UPU process using the control plane. Actions to be determined may be included. Various embodiments may be implemented by including at least one of the steps described below.

Referring to FIG. 16 , since steps 1601 to 1603 of FIG. 16 correspond to steps 501 to 503 of FIG. 5A , detailed description thereof will be omitted.

In step 1604, AMF may transmit a first authentication notification message to AUSF. The first authentication notification message may include the UE ID. In addition, the first authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

In step 1605, AUSF may search for a PS using the PS address received in step 1502 and transmit a second authentication notification message to the corresponding PS. The second authentication notification message may include a UE ID, an indicator for selecting a UPU process followed by a PS, and an NF address (s) necessary for the UPU process. The UE ID may be an Onboarding SUPI, IMEI, or other ID that the PS can identify. The second authentication notification message may further include information indicating that the UE has successfully completed the onboarding process.

An indicator included in the second authentication notification message may indicate one of set values. For example, the indicator may indicate a value indicating one of Option A, Option B, and Option C of Case 3.

If the operator of ON-SNPN does not want to provide the use of UDM in the onboarding and provisioning process or if it is determined that the UDM of ON-SNPN will not be used in that process, the indicator is a value indicating Option A of Case 2 ( Example: "1"). When the indicator indicates “1”, “the UDM of ON-SNPN is not used, and the PS serves as the UDM of the UPU process” in FIGS. 13A and 13B, and the AMF can provide the AUSF address and the AMF address to the PS. there is.

If the operator of ON-SNPN allows the use of UDM or if it is determined that the UDM of ON-SNPN is used in the process as one option, the indicator is a value indicating Option B of Case 2 (eg "2"). can indicate If the indicator indicates "2", "the UDM of ON-SNPN is used, and the UDM of ON-SNPN performs the UDM role of the UPU process" of FIGS. 14a and 14b, and the AMF may provide the UDM address to the PS .

When it is determined to proceed with the optimized UPU process, the indicator may indicate a value indicating Option C of Case 2 (eg, "3"). When the indicator indicates "3", "ON-SNPN's UDM is not used and an optimized UPU process is performed" in FIGS. 15A and 15B and AMF may provide the AUSF address to the DCS.

In step 1606, when the indicator received in step 1605 indicates "1", the PS may perform steps 1306 to 1314 of FIGS. 13A and 13B. And, when the indicator received in step 1605 indicates "2", the PS may perform steps 1406 to 1415 of FIGS. 14A and 14B. In addition, when the indicator received in step 1605 indicates "3", the PS may complete the UPU process by performing steps 1506 to 1515 of FIGS. 15A and 15B.

17 is a block configuration diagram of a terminal according to various embodiments of the present disclosure.

Referring to FIG. 17 , a terminal may include a transmission/reception unit 1720 and a control unit 1710 that controls overall operations of the terminal. The transmission/reception unit 1720 may include a transmission unit 1725 and a reception unit 1723.

The transceiver 1720 may transmit and receive signals with other network entities (eg, an initial AMF or a base station).

The controller 1710 may control the terminal to perform any one operation among the various embodiments described above. The control unit 1710 and the transmission/reception unit 1720 do not necessarily have to be implemented as separate modules, but can be implemented as a single component in the form of a single chip. The controller 1710 and the transceiver 1720 may be electrically connected. In one embodiment, the controller 1710 may be a circuit, an application-specific circuit, or at least one processor. In addition, operations of the terminal may be realized by including a memory device storing corresponding program codes in a configuration unit (eg, a controller 1710 and/or other components not shown) in the terminal.

18 is a block diagram of a network entity according to various embodiments of the present disclosure. The network entity shown in FIG. 18 may include at least one NF (eg, base station, initial AMF, target AMF, existing AMF, NSSF, NRF, or UDM) according to system implementation.

Referring to FIG. 18 , a network entity may include a transceiver 1820 and a control unit 1810 that controls overall operations of the network entity. The transmission/reception unit 1820 may include a transmission unit 1825 and a reception unit 1823.

The transmitting/receiving unit 1820 may transmit/receive a signal to/from a terminal or other network entities.

The controller 1810 may control a network entity to perform any one operation of the above-described embodiments. The control unit 1810 and the transmission/reception unit 1820 do not necessarily have to be implemented as separate modules, but can be implemented as a single component in the form of a single chip. The controller 1810 and the transceiver 1820 may be electrically connected. In one embodiment, the controller 1810 may be a circuit, an application-specific circuit, or at least one processor. Also, operations of the network entity may be realized by including a memory device storing corresponding program codes in a configuration unit (eg, the controller 1810 and/or other components not shown) in the network entity.

It should be noted that the configuration diagrams illustrated in FIGS. 1 to 18 , exemplary diagrams of a control/data signal transmission/reception method, and operational procedure diagrams are not intended to limit the scope of rights of the embodiments of the present disclosure. That is, all components, entities, or operation steps described in FIGS. 1 to 18 should not be interpreted as being essential components for the implementation of the disclosure, and even if only some components are included, within the scope of not harming the essence of the disclosure. can be implemented in

The operations of the above-described embodiments may be realized by including a memory device storing a corresponding program code in an arbitrary component of a device. That is, the controller in the device may execute the above-described operations by reading and executing program codes stored in the memory device by a processor or a central processing unit (CPU).

Entities described in this specification, or various components, modules, etc. of a terminal device may include a hardware circuit, for example, a complementary metal oxide semiconductor-based logic circuit, firmware, and the like. , software and/or a combination of hardware and firmware and/or software embedded in a machine readable medium. As an example, various electrical structures and methods may be implemented using electrical circuits such as transistors, logic gates, and application specific semiconductors.

Meanwhile, in the detailed description of the present disclosure, specific embodiments have been described, but various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments and should not be defined, but should be defined by not only the scope of the claims to be described later, but also those equivalent to the scope of these claims.

Claims (8)

In a method of a first device in a wireless communication system,
Performing an authentication operation with a terminal in a first network and receiving a first message indicating that authentication of the terminal has been completed;
Checking an identifier (ID) and an indicator of the terminal included in the first message;
Acquiring credential information of the terminal for using a service provided in the second network from a second device of the second network based on the ID of the terminal;
When the indicator includes a first value, performing a terminal parameter update operation for providing credential information of the terminal to the terminal,
The first value indicates that a third device that stores and manages data of the terminal in the first network is not used, and that the first device performs an operation as the third device.
According to claim 1,
When the indicator includes a second value, further comprising transmitting credential information of the terminal necessary for the terminal parameter update operation to the third device,
Wherein the second value indicates that the third device is used in the first network.
According to claim 1,
When the indicator includes a third value, further comprising transmitting credential information of the terminal necessary for the terminal parameter update operation to a fourth device used for an authentication operation in the first network,
The third value indicates that the third device is not used in the first network and that the fourth device performs an operation as the third device.
According to claim 1,
The process of acquiring the credential information of the terminal,
identifying the address of the second device based on the ID of the terminal;
Transmitting a second message including an ID of the terminal to the second device based on the identified address;
and acquiring credential information of the terminal from the second device in response to the second message.
In a first device in a wireless communication system,
transceiver and
includes at least one processor;
The at least one processor,
Performing an authentication operation with a terminal in a first network, and receiving a first message indicating that authentication of the terminal has been completed through the transceiver,
Checking an identifier (ID) and an indicator of the terminal included in the first message,
Acquiring credential information of the terminal for using a service provided in the second network from a second device of the second network based on the ID of the terminal,
When the indicator includes a first value, performing a terminal parameter update operation for providing credential information of the terminal to the terminal;
The first value indicates that a third device that stores and manages data of the terminal in the first network is not used, and that the first device performs an operation as the third device. Device.
According to claim 4,
The at least one processor controls the transceiver to transmit credential information of the terminal necessary for the terminal parameter update operation to the third device when the indicator includes a second value,
The second value indicates that the third device is used in the first network.
According to claim 4,
When the indicator includes a third value, the at least one processor transmits credential information of the terminal required for the terminal parameter update operation to a fourth device used for an authentication operation in the first network. control the transceiver,
The third value indicates that the third device is not used in the first network and that the fourth device performs an operation as the third device.
According to claim 1,
The at least one processor,
Identifying the address of the second device based on the ID of the terminal;
Based on the identified address, controlling the transceiver to transmit a second message including an ID of the terminal to the second device;
In response to the second message, the first device, characterized in that to obtain credential information of the terminal from the second device.

Images