Patent Description:
Therefore, the <NUM> or pre-<NUM> communication system is also called a "Beyond <NUM> Network" or a "Post LTE System".

In the <NUM> system, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access(NOMA), and sparse code multiple access (SCMA) as an advanced access technology have also been developed.

A <NUM> communication system considers supporting of more various services compared to the conventional <NUM> communication system. For example, services supported by the <NUM> system may include a ultra wide band mobile communication service (enhanced mobile broad band (eMBB)), a ultra-reliable and low latency communication service (ultra-reliable and low latency communication (URLLC)), a massive device-to-device communication service (massive machine-type communication (mMTC)), and a next-generation broadcast service (evolved multimedia broadcast/multicast service (eMBMS)).

3GPP standard document<NPL>) is directed to Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System; Stage <NUM>. The <NUM> System provides data connectivity and services.

In a change request to <NPL>, UPF discovery using the NRF was discussed in general.

<CIT> relates to a communication method and system for converging a 5th-Generation (<NUM>) communication system for supporting higher data rates beyond a 4th-Generation (<NUM>) system with a technology for Internet of Things (IoT). The present disclosure may be applied to intelligent services based on the <NUM> conununication technology and the loT-related technology, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The present disclosure relates to a method for supporting a session continuity for a terminal in a <NUM> cellular wireless communication system.

<CIT> proposes a technology of, when a single data session based on communications between UPFs is controlled, reducing the number of signalings for data session control to reduce delays on the data session control, so that the requirements of a URLLS service supported in the SG technology can be satisfied and the performance of the service performance can be supported.

Based on the above background, the disclosure provides an apparatus and a method for processing service traffic in a wireless communication system.

In accordance with an aspect of the disclosure, a method of operating a network node is provided. The method includes: receiving, from at least one user plane function (UPF) instance, a registration request message including UPF profile information of the at least one UPF instance; storing the UPF profile information including UPF service support information for at least one UPF service supported by the at least one UPF instance and peer information about a connection relationship with another UPF instance capable of handling traffic by connecting the at least one UPF instance; receiving, from a session management function (SMF) node, a UPF discovery request message including UPF service information; discovering one or more UPF instance based on the UPF profile information and the UPF service information; and transmitting, to the SMF node, UPF instance information including the peer information for the one or more UPF instance.

In accordance with another aspect of the disclosure, a method of operating a Session Management Function (SMF) node in a wireless communication system is provided. The method includes: transmitting, to a network node, a user plane function (UPF) discovery request message including UPF service information; receiving, from the network node, UPF instance information for one or more UPF instance, wherein the UPF instance information includes peer information about a connection relationship with another UPF instance capable of handling traffic by connecting the one or more UPF instance; and determining a UPF network including at least one UPF instance for a traffic of a UPF service, wherein the UPF network is determined based on the peer information.

In accordance with another aspect of the disclosure, a network node in a wireless communication system is provided. The network node includes: at least one transceiver; and at least one processor, wherein the at least one processor is configured to receive, from at least one user plane function (UPF) instance, a registration request message including UPF profile information of the at least one UPF instance, store the UPF profile information including UPF service support information for at least one UPF service supported by the at least one UPF instance and peer information about a connection relationship with another UPF instance capable of handling traffic by connecting the at least one UPF instance, receive, from a session management function (SMF) node, a UPF discovery request message including UPF service information, discover one or more UPF instance based on the UPF profile information and the UPF service information, and transmit, to the SMF node, UPF instance information including the peer information for the one or more UPF instance.

In accordance with another aspect of the disclosure, a Session Management Function (SMF) node in a wireless communication system is provided. The SMF node includes: at least one transceiver; and at least one processor, wherein the at least one processor is configured to transmit, to a network node, a UPF discovery request message including UPF service information; receive, from the network node, UPF instance information for one or more UPF instance, wherein the UPF instance information includes peer information about a connection relationship with another UPF instance capable of handling traffic by connecting the one or more UPF instance; and determine a UPF network including at least one UPF instance for a traffic of a UPF service, wherein the UPF network is determined based on the peer information.

An apparatus and a method according to various embodiments can provide an apparatus and a method for processing of service traffic in a wireless communication system.

Effects obtainable from the disclosure may not be limited to the above mentioned effects, and other effects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art to which the disclosure pertains.

The terms used in the disclosure are only used to describe specific embodiments, and are not intended to limit the disclosure. A singular expression may include a plural expression unless they are definitely different in a context. Unless defined otherwise, all terms used herein, including technical and scientific terms, have the same meaning as those commonly understood by a person skilled in the art to which the disclosure pertains. Such terms as those defined in a generally used dictionary may be interpreted to have the meanings equal to the contextual meanings in the relevant field of art, and are not to be interpreted to have ideal or excessively formal meanings unless clearly defined in the disclosure. In some cases, even the term defined in the disclosure should not be interpreted to exclude embodiments of the disclosure.

Hereinafter, various embodiments of the disclosure will be described based on an approach of hardware. However, various embodiments of the disclosure include a technology that uses both hardware and software, and thus the various embodiments of the disclosure may not exclude the perspective of software.

Hereinafter, the disclosure relates to an apparatus and a method for processing traffic of a service in a wireless communication system.

Terms referring to a signal used in the following description, terms referring to a channel, terms referring to control information, terms referring to network entities, and terms referring to elements of a device are used only for convenience of description. Accordingly, the disclosure is not limited to those terms, and other terms having the same technical meanings may be used.

The terms for identifying an access node used in the following description, the term referring to an access node, the terms referring to a network entity or Network Functions (NFs), the terms referring to messages, the term referring to an interface between network entities, and the terms referring to various pieces of identification information are used for convenience of description. Therefore, the disclosure may not be limited by the terminologies provided below, and other terms that indicate subjects having equivalent technical meanings may be used.

Further, the disclosure describes various embodiments using the terms used in some communication standards (for example, <NUM>rd-Generation Partnership Project (3GPP)), but this is only an example. Various embodiments may be easily modified and applied to other communication systems.

<FIG> illustrates an example of an SBA-based <NUM> system structure in a wireless communication system according to various embodiments of the disclosure.

Referring to <FIG>, an Access and Mobility management Function (AMF) is a Network Function (NF) for managing radio access and mobility of a UE. A Session Management Function (SMF) is an NF for managing a session of the UE, and session information includes Quality of Service (QoS) information, charging information, and information on packet processing. A User Plane Function (UPF) is an NF for processing user plane traffic, that is, a packet transmitted and received by a customer through a communication network, and is controlled by the SMF. Although not illustrated in <FIG>, the <NUM> system may include an Unstructured Data Storage network Function (UDSF), and the UDSF is an NF for storing unstructured data and may store or retrieve any type of data according to a request from the NF.

Meanwhile, one of the structural characteristics of the communication network according to various embodiments is to separate a control plane NF for a <NUM> service such as the AMF and the SMF and a user plane for processing actual traffic. Particularly, processing of user traffic supported by the UPF, that is, packet processing may be divided into various detailed processing functions.

According to various embodiments, a Network Entity (NE)/Network Function (NF) (for example, a UPF or a Packet data network Gateway User Plane (PGW-UP)) for processing a user plane may simultaneously support all of the packet processing functions, modularize and separate detailed processing functions, and combine and operate the same. For example, traffic that does not need charging or multi-radio network access may be processed only by a packet processing function module that supports simply basic packet processing, and traffic of services that need charging may be processed further by a usage reporting function module. That is, one packet processing NE/NF having all packet processing functions makes optimal traffic processing suitable for various types of services difficult, makes ultra high-speed packet processing difficult, and deteriorates scalability according to a traffic increase/decrease. Accordingly, various embodiments propose a structure of separating a user plane packet processing function, allowing a capacity to increase/decrease for each module, and connecting processing modules suitable for a service characteristic to process a packet.

Hereinafter, in various embodiments, one packet processing function (module) is referred to as a UPF service, and the UPF service basically corresponds to each of various detailed packet processing functions described above. For example, a QoS enforcement function corresponds to a UPF QoS enforcement service. In addition to the various detailed packet processing functions described above, additional packet processing functions, for example, a Network Address Translation (NAT) function and a virtual LAN supporting function may be included.

One UPF instance may support one or more UPF services. If each UPF service is implemented in the form of an identifiable instance, the identifiable instance may be referred to as a UPF service instance. UPF service instances that provide the same service may be grouped as a UPF service set. UPF service instances belonging to one UPF service set may exchange or share context with each other and provide an equivalent service. Further, UPF instances that provide the same service may configure a UPF set, and UPF instances belonging to one UPF set may exchange or share context with each other and provide an equivalent service. Even when a UPF service or a UPF instance is changed according to movement of a UE or a change in a network state, UE service continuity (or IP address preservation) may be supported between UPF instances belonging to the same UPF service set or the same UPF set.

Meanwhile, the UPF instance is a UPF corresponding to an NF defined in the 3GPP standard which can be realized and identified. One UPF may support one or more UPF services, and UPF services may be separated and implemented as realized and identified UPF service instances. If the UPF is implemented as the UPF instance, the UPF service instance may be included in the UPF instance. Accordingly, in various embodiments, a UPF, a UPF instance, and a UPF service instance may be interchangeable with each other. For example, the term "UPF instance" may be interchangeable with the term "UPF service instance" in various embodiments.

<FIG> illustrates the configuration of a network entity in a wireless communication system according to various embodiments. The network entity according to the disclosure is a concept including a network function according to a system implementation. The term "~unit" or "~er" used hereinafter may refer to the unit for processing at least one function or operation and may be implemented in hardware, software, or a combination of hardware and software.

The network entity according to various embodiments may include a communication unit <NUM>, a storage unit <NUM>, and a controller <NUM> for controlling the overall operation of the network entity <NUM>.

The communication unit <NUM> transmits and receives signals to and from other network entities. Accordingly, all or part of the communication unit <NUM> may be referred to as a "transmitter <NUM>", a "receiver <NUM>", or a "transceiver <NUM>".

The storage unit <NUM> stores data such as a basic program, an application, and configuration information for the operation of the network entity <NUM>. The storage unit <NUM> may include volatile memory, nonvolatile memory, or a combination of volatile memory and nonvolatile memory. The storage unit <NUM> provides stored data in response to a request from the controller <NUM>.

The controller <NUM> controls the overall operation of the network entity <NUM>. For example, the controller <NUM> transmits and receives a signal through the communication unit <NUM>. The controller <NUM> records data in the storage unit <NUM> and reads the same. The controller <NUM> may perform the functions of a protocol stack required by the communication standard. To this end, the controller <NUM> may include a circuit, an application-specific circuit, at least one processor, or a micro processor, or may be a part of the processor. Further, the part of the communication unit <NUM> or the controller <NUM> may be referred to as a Communications Processor (CP). The controller <NUM> may control the network entity <NUM> to perform one operation according to various embodiments.

The communication unit <NUM> and the controller <NUM> should be necessarily implemented as separate modules but may be implemented as one element such as a single chip or software block. The communication unit <NUM>, the storage unit <NUM>, and the controller <NUM> may be electrically connected. The operations of the network entity <NUM> may be implemented by including the storage unit <NUM> for storing the corresponding program code within the network entity <NUM>.

The network entity <NUM> may include a network node and may be one of base station (RAN), AMF, SMF, UPF, NF, NEF, NRF, CF, NSSF, UDM, AF, AUSF, SCP, UDSF, context storage, OAM, EMS, configuration server, and ID management server.

<FIG> illustrates an example of the connection configuration of a UPF in a wireless communication system.

Referring to <FIG>, the connection configuration of a User Plane Function (UPF) <NUM> includes a Network Generation Radio Access Network (NG-RAN) (BS) <NUM>, the UPF <NUM>, and a Data Network (DN) <NUM>.

The UPF <NUM> serves to transmit user traffic between the NG-RAN <NUM> and the DN <NUM>. In a general case, one UPF <NUM> operates between the NG-RAN <NUM> and the DN <NUM> through a link therebetween, and two UPFs <NUM> may selectively operate for a specific situation such as roaming. In such a configuration, the UPF <NUM> should include all of the functions (charging and QoS control) for processing packets required by the communication network.

<FIG> illustrates an example (network) of the connection between UPF services according to various embodiments.

In <FIG>, packet processing is supported through the connection (network) of UPF services having different functions rather than through one or two UFPs/GWs having the same function between a BS (RAN) <NUM> and a Data Network (DN) <NUM> unlike the connection of the user plane of <FIG>. For example, when charging, Deep Packet Inspection (DPI), and QoS control are needed for a specific service (IP flow), traffic belonging to the corresponding service is processed by passing through physically separated UPF instances that provide the corresponding processing function.

<FIG> illustrates a process of registering a UPF in a wireless communication system according to various embodiments.

Referring to <FIG>, according to various embodiments, at least one UPF instance <NUM> and <NUM> may register a UPF service supported by themselves and provide information, and thus allow another NF (for example, a Session Management Function (SMF) to call (request) the UPF service to process specific traffic. Although <FIG> illustrates the process of registering two UPF instances for convenience of description, the process may expand to two or more UPFs according to various embodiments.

In step <NUM>, a first UPF (UPF-<NUM>) instance <NUM> performs a UPF service registration process with a Network Repository Function/Service Communication Proxy (NRF/SCP) <NUM> and transmits its own NF profile through a registration request message. The NF (UPF) profile basically includes an identifier of the first UPF (UPF-<NUM>) instance <NUM>. According to various embodiments, the NF (UPF) profile may include information on one or more UPF services supported by the first UPF (UPF-<NUM>) instance <NUM>. The UPF service information may include an identifier of the UPF service, a version of each service, and capability of each service. Further, the NF (UPF) profile may include information on a connection relationship with another UFP instance to which the first UPF (UPF-<NUM>) instance <NUM> is connected to process traffic, that is, peer information. The information on the connection relationship with another UPF instance, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the first UPF (UPF-<NUM>) instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), an Internet Protocol (IP) address, and a port number, and may be configured for each UPF (set or instance) which can be linked. Further, the NF (UPF) profile may include an identifier of a UPF set to which the first UPF (UPF-<NUM>) instance <NUM> belongs, an IP address(es) of the first UPF (UPF-<NUM>) instance <NUM>, and a port number.

In step <NUM>, the NRF/SCP <NUM> stores information received from the first UPF (UPF-<NUM>) instance <NUM>, marks the first UPF (UPF-<NUM>) instance <NUM> with an available UPF, and uses the same for UPF service selection and discovery processes occurring later. In <FIG>, a response message which the NRF/SCP <NUM> transmits to the first UPF (UPF-<NUM>) instance <NUM> is omitted.

In step <NUM>, a second UPF (UPF-<NUM>) instance <NUM> performs a UPF service registration process with an NRF/SCP <NUM> and transmits its own NF profile through a registration request message. The NF (UPF) profile basically includes an identifier of the second UPF (UPF-<NUM>) instance <NUM>. According to various embodiments, the NF (UPF) profile may include information on one or more UPF services supported by the second UPF (UPF-<NUM>) instance <NUM>. Further, the NF (UPF) profile may include information on a connection relationship with another UFP instance to which the second UPF (UPF-<NUM>) instance <NUM> is connected to process traffic, that is, peer information. In addition, the NF (UPF) profile may include an identifier of a UPF set to which the second UPF (UPF-<NUM>) instance <NUM> belongs and an IP address(es) of the second UPF (UPF-<NUM>) instance <NUM>. The information on the connection relationship with another UPF instance, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the second UPF (UPF-<NUM>) instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), an IP address, and a port number, and may be configured for each UPF (set or instance) which can be linked.

In step <NUM>, the NRF/SCP <NUM> stores information received from the second UPF (UPF-<NUM>) instance <NUM>, marks the second UPF (UPF-<NUM>) instance <NUM> with an available UPF, and uses the same for UPF service selection and discovery processes occurring later. In <FIG>, a response message which the NRF/SCP <NUM> transmits to the second UPF (UPF-<NUM>) instance <NUM> is omitted.

Hereinafter, embodiments of <FIG> and <FIG> may be selectively performed after the embodiment of <FIG> or <FIG> is performed. That is, after the UPF service registration is performed through the embodiment of <FIG>, the UPF instance for providing traffic processing of a specific session may be selected and linked through the embodiment of <FIG> or <FIG>. Alternatively, after information on the UPF service is received and stored through the embodiment of <FIG>, the UPF instance for providing traffic processing of a specific session may be selected and linked through the embodiment of <FIG> or <FIG>.

<FIG> illustrates a process of selecting and linking a UPF instance for providing traffic processing of a specific session in a wireless communication system according to various embodiments.

Although <FIG> illustrates a process of selecting one UPF instance for convenience of description, the processes of <FIG> may be repeated for each UPF instance when two or more UPF instances should be linked to process traffic as illustrated in the embodiment of <FIG>.

In step <NUM>, a consumer NF (for example, an SMF <NUM>) performs a process of discovering and selecting a UPF instance with an NRF/SCP <NUM> to receive a user plane packet processing service. That is, the consumer NF <NUM> transmits a UPF discovery request message including UPF service(s) and slide information to the NRF/SCP <NUM>.

Specifically, the consumer NF <NUM> transmits a discovery request message including a UPF service name required by the consumer NF, an expected NF type (a UPF in this embodiment), and an NF type of the consumer NF (for example, an SMF) to the NRF/SCP <NUM>. If the consumer NF <NUM> has the information when making the request, the corresponding request message may additionally include an identifier of a UPF set and an identifier of a UPF service set. Further, if the requested UPF instance should be connected to the already selected UPF instance, the request message may include information on the UPF instance to be connected (an identifier of the UPF instance and the use of connection relationship information, that is, peer information).

In the embodiment of <FIG>, the NRF/SCP <NUM> receives connection relationship information, that is, peer information during the UPF service registration process of <FIG>. Accordingly, the NRF/SCP <NUM> may determine a UPF instance, that is, a peer to be connected to each instance and service and provide information.

In step <NUM>, the NRF/SCP <NUM> discovers a UPF instance that may support discovery-requested UPF service(s). That is, the NRF/SCP <NUM> discovers a UPF network including at least one UPF instance that may support requested UPF service(s).

In step <NUM>, the NRF/SCP <NUM> transfers information on the UPF instance that may support requested UPF service(s) to the consumer NF <NUM>. That is, the NRF/SCP <NUM> transmits a UPF discovery response message including UPF service network information and a list of NF profiles to the consumer NF <NUM>.

When two or more UPF instances supporting the corresponding UPF service(s) are configured to be linked to each other unlike discovery between general control plane NFs, information corresponding to a response of the NRF/SCP <NUM> may include both information on two or more UPF instances and link information between two or more UPF instances. The link information may include information on the connection (IP network or link) between two or more UPF instances, a direction in which a packet is exchanged between two or more UPF instances, and a sequence in a transmission path between two or more UPF instances, and connection relationship information, that is, peer information received during the UPF service registration process may be used or information received through separate Operations and Management (OAM) may be used for the link between the UPF instance and discovery of the configuration of an optimal UPF instance.

<FIG> illustrates a process of selecting and linking a UPF instance that may provide traffic processing of a specific session in a wireless communication system according to various embodiments.

Although <FIG> illustrates the process of selecting one UPF instance for convenience of description, the processes of <FIG> may be repeated for each UPF instance when two or more UPF instances should be linked to process traffic as illustrated in the embodiment of <FIG>.

Specifically, the consumer NF <NUM> transmits a discovery request message including a UPF service name required by the consumer NF, an expected NF type (a UPF in this embodiment), and an NF type of the consumer NF (for example, an SMF) to the NRF/SCP <NUM>. If the consumer NF <NUM> has the information when making the request, the corresponding request message may additionally include an identifier of a UPF set and an identifier of a UPF service set. Further, if the requested UPF instance should be connected to the already selected UPF instance, the request message may include information on the UPF instance to be connected (the use of connection relationship information, that is, peer information).

In the embodiment of <FIG>, the NRF/SCP <NUM> may not receive connection relationship information, that is, peer information during the UPF service registration process of <FIG> or has a difficulty in determining and providing a UPF instance, that is, a peer to be connected to each UPF instance and service. In the embodiment of <FIG>, the determination of the link between UPF instances should be performed by an SMF <NUM>.

In step <NUM>, the NRF/SCP <NUM> discovers a UPF instance that may support discovery-requested UPF service(s). That is, the NRF/SCP <NUM> discovers a combination of UPFs or a UPF network including at least one UPF instance that may support requested UPF service(s).

In step <NUM>, the NRF/SCP <NUM> transfers information on the UPF instance that may support requested UPF service(s) to the consumer NF <NUM>. That is, the NRF/SCP <NUM> transmits a UPF discovery response message including a list of NF profiles to the consumer NF <NUM>.

When two or more UPF instances supporting the corresponding UPF service(s) are configured to be linked to each other unlike discovery between general control plane NFs, information corresponding to a response of the NRF/SCP <NUM> may include all of the information on two or more UPF instances. In order to make the link between the UPF instances and discover the optimal UPF instance configuration, the connection relationship information, that is, the peer information received during the UPF service registration process may be used or information received through separate Operations and Management (OAM) may be used.

Steps <NUM> and <NUM> may be described for one UPF instance and may be repeatedly performed if a plurality of UPF instances is needed.

In step <NUM>, the consumer NF (for example, an SMF) <NUM> transmits a request for generating N4 (interface between the SMF and the UPF) (Packet Forwarding Control Protocol (PFCP) association) association to the UPF instance <NUM> through a discovery response received from the NRF/SCP <NUM>. The N4 (PFCP) association setup request message transmitted by the consumer NF <NUM> may include capability supported by the consumer NF <NUM>, an identifier of the consumer NF <NUM>, and peer information of another UPF which should be linked. That is, the consumer NF <NUM> transmits the N4 association setup request message including an SMF to the UPF instance <NUM>.

In step <NUM>, the UPF instance <NUM> transmits again an N4 association setup response message to the consumer NF <NUM>. The N4 association setup response message may include UPF services supported by the consumer NF <NUM>, capability of the UPF instance, and connection relationship information, peer information of another UPF instance which can be linked to the UPF instance <NUM>. The connection relationship information, that is, peer information of another UPF instance which can be linked may specifically include information on the connection (IP network or link) with another UPF instance, a direction in which a packet is exchanged with another UPF instance, and a sequence in a transmission path between UPF instances, and for information on another UPF instance, information received from the consumer NF <NUM> may be used, connection relationship information, that is, peer information requested and received from the NRF/SCP <NUM> may be used, or information received through separate Operations and Management (OAM) may be used. That is, the UPF instance <NUM> transmits the NR association setup response message including the UPF and the peer information to the consumer NF <NUM>.

In step <NUM>, the consumer NF <NUM> determines UPF instances for processing traffic on the basis of information received through the UPF instance <NUM>. That is, the consumer NF <NUM> determines a UPF network including at least one UPF instance for processing traffic of requested UPF service(s).

Although the embodiment of <FIG> has been described on the basis of exchange of information during the N4 association process for management at a node level between the consumer NF (for example, the SMF) <NUM> and the UPF instance, exchanging of the same information may be performed during a process of establishing a session for actual traffic transmission, for example, an N4 session establishment process or through separate N4 message exchange.

The embodiment of <FIG> below may be selectively performed along with the embodiments of <FIG> or the embodiments of <FIG> and <FIG>. That is, a UPF instance for providing traffic processing of a specific session may be selected and linked through the embodiment of <FIG>. When the embodiment of <FIG> is combined with the embodiments of <FIG> or the embodiments of <FIG> and <FIG>, the embodiment of <FIG> may be used to acquire detailed information of the UPF (NF profile and peer information of the UPF) or link to the UPF instance in order to perform actual traffic processing.

Although <FIG> illustrates two UPF instances for convenience of description, this embodiment may be equally applied to three or more UPF instances.

In step <NUM>, a first UPF (UPF-<NUM>) instance <NUM> performs a process of generating N4 (PFCP) association with an SMF <NUM> which can be linked to the first UPF (UPF-<NUM>) instance <NUM>. Step <NUM> may be performed when the UPF-<NUM> instance <NUM> is initialized, or when status information of the UPF-<NUM> instance <NUM> is changed or configured by an operator. In step <NUM>, specifically, the UPF-<NUM> instance <NUM> may include an identifier of the UPF-<NUM> instance <NUM>, an IP address supported by the UPF-<NUM> instance <NUM>, a set of Fully qualified Tunnel Endpoint Identifiers (F-TEIDs) which can be supported by the UPF-<NUM> instance <NUM>, capability supported by the UPF-<NUM> instance <NUM>, UPF services supported by the UPF-<NUM> instance <NUM>, and information on a peer UPF which can be linked to the UPF-<NUM> instance <NUM> in the N4 association setup request message transmitted to the SMF <NUM>. The connection relationship information, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the UPF-<NUM> instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), and an IP address, and may be configured for each UPF (set or instance) which can be linked. Further, an identifier of the UPF set to which the UPF instance belongs and IP address(es) of UPF instance(s) may be included. That is, the UPF-<NUM> instance <NUM> transmits the N4 association request message including a node ID, an IP address, an F-TEID pool, a supported function, and peer information to the SMF <NUM>.

In step <NUM>, the SMF <NUM> processes the N4 association setup request received from the UPF-<NUM> instance <NUM> and transmits an N4 association setup response message. In step <NUM>, the SMF <NUM> stores the information received from the UPF-<NUM> instance <NUM>. The N4 association setup response message is an N4 (PFCP) association setup response. The N4 association setup response message may include information on the SMF <NUM>, for example, an identifier of the SMF <NUM>, an IP address of the SMF <NUM>, a set of Fully qualified Tunnel Endpoint Identifiers (F-TEIDs) which can be supported by the SMF <NUM>, and capability supported by the SMF <NUM>. That is, the SMF <NUM> transmits the N4 association response message including a node ID, an IP address, an F-TEID pool, and a supported function to the UPF-<NUM> instance <NUM>. Further, the SMF <NUM> stores information on the UPF-<NUM> instance <NUM>.

In step <NUM>, the second UPF (UPF-<NUM>) instance <NUM> performs a process of generating N4 (PFCP) association with the SMF <NUM> which can be linked to the second UPF (UPF-<NUM>) instance <NUM>. Step <NUM> may be performed when the UPF-<NUM> instance <NUM> is initialized, or when status information of the UPF-<NUM> instance <NUM> is changed or configured by an operator. In step <NUM>, specifically, the UPF-<NUM> instance <NUM> may include an identifier of the UPF-<NUM> instance <NUM>, an IP address supported by the UPF-<NUM> instance <NUM>, a set of Fully qualified Tunnel Endpoint Identifiers (F-TEIDs) which can be supported by the UPF-<NUM> instance <NUM>, capability supported by the UPF-<NUM> instance <NUM>, UPF services supported by the UPF-<NUM> instance <NUM>, and information on a peer UPF which can be linked to the UPF-<NUM> instance <NUM> in the N4 association setup request message transmitted to the SMF <NUM>. The connection relationship information, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the UPF-<NUM> instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), and an IP address, and may be configured for each UPF (set or instance) which can be linked. Further, an identifier of the UPF set to which the UPF instance belongs and IP address(es) of UPF instance(s) may be included. That is, the UPF-<NUM> instance <NUM> transmits the N4 association request message including a node ID, an IP address, an F-TEID pool, a supported function, and peer information to the SMF <NUM>.

An embodiment of <FIG> below may be performed after the embodiments of <FIG>, the embodiments of <FIG> and <FIG>, or the embodiment of <FIG> described above are performed. That is, after the UPF instance for providing traffic processing of a specific session is selected and linked through the embodiments <FIG>, the embodiments of <FIG> and <FIG>, or the embodiment of <FIG>, an N4 session corresponding to establishment or modification of a PDU session may be established through the embodiment of <FIG>.

<FIG> illustrates a process of establishing an N4 session corresponding to establishment or modification of a PDU session in a wireless communication system according to various embodiments.

In step <NUM>, an SMF <NUM> receives a PDU session establishment/modification request message. The UE may need to establish a new PDU session or an addition/modification of a UPF instance may be needed during modification of a PDU session. Step <NUM> may be performed by reception of a message indicating the generation of a request or modification for a new session from an AMF by the SMF <NUM>, by information received from a PCF/UDM by the SMF <NUM>, or by triggering according to a state of the SMF <NUM>.

In step <NUM>, the SMF <NUM> performs a process of selecting UPF instances for establishing/modifying a PDU session and establishing a session on the basis of information on UFP instances received in the previous step. That is, the SMF <NUM> determines a UPF network including at least one UPF instance which may support the PDU session of which establishment/modification is requested and determines N4 rules.

The embodiment of <FIG> is described on the basis of the use of a UPF service supported by a UPF-<NUM> instance <NUM> and a UPF-<NUM> instance <NUM> for the corresponding UE and session.

Although not illustrated in <FIG>, three or more UPF instances, for example, the UPF-<NUM> instance <NUM>, the UPF-<NUM> instance <NUM>, and a UPF-<NUM> instance which is not illustrated may perform service registration in the SMF <NUM>. In this case, the SMF <NUM> may select the UFP-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM> to establish/modify the PDU session among from the UFP-<NUM> instance <NUM>, the UPF-<NUM> instance <NUM>, and the UFP-<NUM> instance in step <NUM>.

In step <NUM>, the SMF <NUM> generates an N4 rule to use the UPF service of the UPF-<NUM> instance <NUM> selected in step <NUM> and transfers the same to the UPF-<NUM> instance <NUM>. The N4 rule may contain information and rules required for a specific UPF service, and may include a packet detection rule for detecting a packet (or IP flow) as a target, a rule for an action for each UPF service (for example, in the case of QoS enforcement, a detailed parameter for QoS enforcement), and a rule for transferring a packet to another node (a linked UPF, a data network, or a RAN). Further, basic context of the corresponding session is included. Upon receiving the N4 rule, the UPF-<NUM> instance <NUM> stores the received N4 rule, transmits the response message to the SMF <NUM> again, and performs a traffic processing operation using the received N4 rule and context. That is, the UPF-<NUM> instance <NUM> and the SMF <NUM> exchanges the N4 session establishment request message/response message including Session Management (SM) context and a set of N4 rules.

When a specific packet is processed, the packet should sequentially pass through the UFP-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM>, N4 rules which the SMF <NUM> transmits to the UPF-<NUM> instance <NUM> in step <NUM> may include not only a rule for an operation of processing a packet which should be processed by the UPF-<NUM> instance <NUM> but also a transmission rule indicating that the packet should be transmitted to the UPF-<NUM> instance <NUM>. According to various embodiments, when one UPF instance performs the operation of processing two or more packets, N4 rules which the SMF <NUM> generates and transmits to the UPF instance may include a value for identifying sequences (or priorities) of the N4 rules.

When packet transmission/reception and information exchange for General Packet Radio System (GPRS) Tunneling Protocol-User plane (GTP-U) between two UPF instances <NUM> and <NUM> are needed after steps <NUM> and <NUM>, additional signaling and information exchange between the two UPF instances <NUM> and <NUM> may be generated.

<FIG> illustrates a process using a combination of one or more packet processing functions required for a specific traffic packet in a wireless communication system according to various embodiments.

The embodiment of <FIG> may prevent complexity for management in the network from becoming high when the number of combinations of various packet processing functions provided by UPF instances is too great. At this time, a representative combination of packet processing functions may be standardized in consideration of a characteristic of traffic generally frequently generated and equally applied in various environments, and some combinations may be used according to settings of a service provider. A specific packet processing category (or group) includes an index of the category and one or more packet processing functions belonging to the corresponding category. The category is divided into a standardized category and a category that may be configured by settings of a service provider, and the standardized category uses some ranges of indexes (for example, indexes <NUM> to <NUM>).

For example, a packet processing category to be standardized may be configured as shown in [Table <NUM>] below.

In step <NUM>, a first UPF (UPF-<NUM>) instance <NUM> performs a UPF service registration process with an NRF/SCP <NUM> and transmits an NF (UPF) profile of the first UPF (UPF-<NUM>) instance <NUM> through a registration request message. The NF (UPF) profile may basically include an identifier of the first UPF (UPF-<NUM>) instance <NUM>, and may further include one or more pieces of UPF service information supported by the first UPF (UPF-<NUM>) instance <NUM> according to various embodiments. If the first UPF (UPF-<NUM>) instance <NUM> supports packet processing belonging to a specific category, an index of the category for which packet processing is supported by the first UPF (UPF-<NUM>) instance <NUM> is included. If service provider-specific category packet processing is supported, an index of the service provider-specific category may be included, and a packet processing function belonging to the corresponding category may be specified. Further, the NF (UPF) profile may include information on a connection relationship with another UFP instance to which the first UPF (UPF-<NUM>) instance <NUM> is connected to process traffic, that is, peer information. The connection relationship information, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the first UPF (UPF-<NUM>) instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), and an IP address, and may be configured for each UPF (set or instance) which can be linked. Further, an identifier of the UPF set to which the UPF instance belongs and IP address(es) of UPF instance(s) may be included.

In step <NUM>, the second UFP (UPF-<NUM>) instance <NUM> may perform a UPF service registration process with the NRF/SCP <NUM>, and the NF (UPF) profile may basically include an identifier of the second UPF (UPF-<NUM>) instance <NUM> and may further include one or more pieces of UPF service information supported by the second UPF (UPF-<NUM>) instance <NUM> according to various embodiments. If the second UPF (UPF-<NUM>) instance <NUM> supports packet processing belonging to a specific category, an index of the category for which packet processing is supported by the second UPF (UPF-<NUM>) instance <NUM> is included. If service provider-specific category packet processing is supported, an index of the service provider-specific category may be included, and a packet processing function belonging to the corresponding category may be specified. Further, the NF (UPF) profile may include information on a connection relationship with another UFP instance to which the second UPF (UPF-<NUM>) instance <NUM> is connected to process traffic, that is, peer information. In addition, an identifier of the UPF set to which the UPF instance belongs and IP address(es) of UPF instance(s) may be included. The connection relationship information, that is, peer information may specifically include one or more of an identifier of a UPF set which can be connected to the second UPF (UPF-<NUM>) instance <NUM>, an identifier of the UPF instance, a relationship (transmission/reception/bi-direction), and an IP address, and may be configured for each UPF (set or instance) which can be linked.

In step <NUM>, the NRF/SCP <NUM> stores information received from the UPF instances <NUM> and <NUM>, marks an available UPF, and uses the same for UPF service selection and discovery processes occurring later. In <FIG>, a response message which the NRF/SCP <NUM> transmits to first UPF (UPF-<NUM>) instance <NUM> and the second UPF (UPF-<NUM>) instance <NUM> is omitted.

In step <NUM>, a consumer NF <NUM> (for example, an SMF) performs a process of discovering and selecting a UPF instance with the NRF/SCP <NUM> to receive a user plane packet processing service. Such a process may be triggered to establish a PDU session for a specific UE or triggered to acquire in advance information required for the corresponding process. In the embodiment of <FIG>, the consumer NF <NUM> (for example, the SMF) transmits a discovery request message including an index of a packet processing category required by the consumer NF to the NRF/SCP <NUM>. Further, a Data Network Name (DNN) or a slice to be a target may be specified, and if the consumer NF has the information when making the request, the corresponding request message may additionally include an identifier of a UPF set and an identifier of a UPF service set. In addition, if the requested UPF instance should be connected to the already selected UPF instance, the request message may include information on the UPF instance to be connected (the use of the connection relationship information, that is, peer information).

In step <NUM>, the NRF/SCP <NUM> discovers a UPF network including at least one UPF instance for supporting UPF service(s) belonging to a category requested to be discovered. That is, the NRF/SCP <NUM> determines a UPF network including at least one UPF instance that may support the UPF service requested to be discovered. This embodiment assumes that the NRF/SCP <NUM> selects the UPF-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM> and determines a UPF network including the UPF-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM>. Additionally, although not illustrated, it may be assumed that the NRF/SCP <NUM> does not select a UPF-<NUM> instance even though the UPF-<NUM> instance that stores UPF information exists.

In step <NUM>, the NRF/SCP <NUM> transfers information on the UPF service network determined in step <NUM> to the consumer NF <NUM>. When two or more UPF instances supporting corresponding UPF service(s) are linked to each other unlike the discovery between general control plane NFs, information corresponding to a response of the NRF/SCP may include all of the information on the UPF instances and link information therebetween. The link information may include information on the connection (IP network or link) between UPF instances, a direction in which a packet is exchanged between UPF instances, and a sequence in a transmission path between UPF instances, and connection relationship information, that is, peer information received during the UPF service registration process may be used or information received through separate Operations and Management (OAM) may be used for the link between the UPF instance and discovery of the configuration of an optimal UPF instance.

In step <NUM>, the SMF <NUM> generates an N4 rule to use the UPF service of the selected UPF-<NUM> instance <NUM>.

That is, the SMF <NUM> determines at least one UPF instance that may support the UPF service requested to be discovered. This embodiment assumes that the SMF <NUM> determines the UPF-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM> as at least one UPF instance that may support the UPF service. Additionally, although not illustrated, it may be assumed that the SMF <NUM> does not determine a UPF-<NUM> instance as at least one UPF instance that may support the UPF service even though the UPF-<NUM> instance that stores UPF information exits.

In step <NUM>, the SMF <NUM> transfers the generated N4 rule to the UPF-<NUM> instance <NUM>. The N4 rule may contain information and rules required for a specific UPF service, and may include a packet detection rule for detecting a packet (or IP flow) as a target, a rule for an action for each UPF service (for example, in the case of QoS enforcement, a detailed parameter for QoS enforcement), and a rule for transferring a packet to another node (a linked UPF, a data network, or a RAN). Further, basic context of the corresponding session is included. Upon receiving the N4 rule, the UPF-<NUM> instance <NUM> stores the received N4 rule, transmits the response message to the SMF <NUM> again, and performs a traffic processing operation using the received N4 rule and context. That is, the UPF-<NUM> instance <NUM> and the SMF <NUM> exchange an N4 (PFCP) session establishment request message/response message including rule(s) for the UPF service and a Forwarding Action Rule (FAR)/Packet Detection Rule (PDR).

That is, the SMF <NUM> determines at least one UPF instance that may support the UPF service requested to be discovered. This embodiment assumes that the SMF <NUM> determines the UPF-<NUM> instance <NUM> and the UPF-<NUM> instance <NUM> as at least one UPF instance that may support the SUP service. Additionally, although not illustrated, it may be assumed that the SMF <NUM> does not determine a UPF-<NUM> instance as at least one UPF instance that may support the UPF service even though the UPF-<NUM> instance that stores UPF information exits.

Thereafter, when packet transmission/reception and information exchange for GTP-U tunneling or management between two UPF instances <NUM> and <NUM> are needed, additional signaling and information exchange between the two UPF instances <NUM> and <NUM> may be generated.

Meanwhile, <FIG> has described the process of registering information on the UPF instances <NUM> and <NUM> through the NRF/SCP <NUM> and discovering and selecting the UPF instances <NUM> and <NUM> by the consumer NF <NUM>, and the use of a category for the UPF service during the process.

However, the use of the category for the UPF service may expand to the use of category information even in the process of exchanging UPF instance information during an N4 association process between the UPF instance and the SMF in <FIG> or <FIG> among various embodiments. That is, the UPF instance may transfer information on the category supported by the UPF instance during the process of establishing N4 association with the SMF to the SMF, and the SMF may discover the UPF instance that supports the category for processing traffic of a specific service on the basis of the information.

Claim 1:
A method performed by a network repository function, NRF, node (<NUM>) in a wireless communication system, the method comprising:
receiving (<NUM>), from at least one user plane function, UPF, instance (<NUM>), a registration request message including UPF profile information of the at least one UPF instance;
storing (<NUM>) the UPF profile information, wherein the UPF profile information includes UPF service support information for at least one UPF service supported by the at least one UPF instance and peer information about a connection relationship with another UPF instance capable of handling traffic by connecting the at least one UPF instance;
receiving (<NUM>), from a session management function, SMF, node (<NUM>), a UPF discovery request message including UPF service information;
discovering (<NUM>) one or more UPF instance based on the UPF profile information and the UPF service information; and
transmitting (<NUM>), to the SMF node, UPF instance information including the peer information for the one or more UPF instance.