Method and apparatus for offloading network function in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for providing higher data transfer rates than 4G communication systems, such as LTE. According to various embodiments of the present disclosure, a method performed by a network entity in a wireless communication system may comprise the steps of: receiving, from one or more hardware apparatuses, information about pipelines respectively corresponding to the one or more hardware apparatuses; separating, on the basis of the information about the pipelines, a pipeline for processing a data packet into a first pipeline and a second pipeline; configuring the first pipeline to a first apparatus among the one or more hardware apparatuses; configuring the second pipeline to a second apparatus among the one or more hardware apparatuses; configuring a table for a first bridge to the first apparatus; and configuring a table for a second bridge to the second apparatus, wherein the first bridge and the second bridge may be used for processing the data packet on the basis of the first pipeline and the second pipeline.

Description

Method and device for offloading network functions in a wireless communication system

[0001] The present disclosure relates to a device and method for distributing network functions for efficient processing of data packets. More specifically, the present disclosure relates to a device and method for offloading network functions by separating the pipeline for processing data packets.

[0002] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of the 5G (5th Generation) communication system, an explosive increase in connected devices is expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction equipment, and factory equipment. Mobile devices are also expected to evolve into diverse form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6G (6th Generation) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "beyond 5G."

[0003] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes (i.e., 1,000 gigabits) per second (bps) and a wireless latency of 100 microseconds (μsec). In other words, compared to 5G, the transmission speed in a 6G communication system will be 50 times faster and the wireless latency will be reduced to one-tenth.

[0004] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz (THz) band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to have more severe path loss and atmospheric absorption, making it more important to develop technologies that can guarantee signal reach, or coverage. Key technologies to ensure coverage include Radio Frequency (RF) components, antennas, new waveforms that offer better coverage than Orthogonal Frequency Division Multiplexing (OFDM), beamforming, and multiple antenna transmission technologies such as massive Multiple-Input and Multiple-Output (MIMO), Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS) are being discussed to improve the coverage of terahertz band signals.

[0005] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources at the same time for uplink and downlink; network technology that integrates satellites and HAPS (High-Altitude Platform Stations); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes AI (Artificial Intelligence) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (Mobile Edge Computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe use of data, and the development of technologies for maintaining privacy.

[0006] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable services such as truly immersive eXtended Reality (XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems through enhanced security and reliability, will be applied in diverse fields such as industry, medicine, automobiles, and home appliances.

[0007] In wireless communication systems, entities responsible for user data transmission can receive rules or commands from entities in the control plane and, accordingly, perform operations related to user packet processing. In 5G wireless communication, the session management function (SMF) located in the control plane can control the user plane function (UPF) using the packet forwarding control protocol (PFCP). Meanwhile, the traffic processing volume required in wireless communication systems increases every year, and these requirements become even more stringent as communication technology generations change.

[0008] As described above, it appears that a growing number of terminals will require the generation and transmission of greater amounts of data to perform various applications. Therefore, the present disclosure can provide a method for efficiently installing, updating, or deleting packet processing rules for processing each traffic stream, to efficiently transmit data generated by terminals and applications.

[0009] The technical problems to be achieved in this document are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0010] According to various embodiments of the present disclosure, in a wireless communication system, a method performed by a network entity may include the steps of: receiving, from one or more hardware devices, information about a pipeline corresponding to each of the one or more hardware devices; separating a pipeline for processing a data packet into a first pipeline and a second pipeline based on the information about the pipeline; setting the first pipeline to a first device among the one or more hardware devices; setting the second pipeline to a second device among the one or more hardware devices; setting a table for a first bridge to the first device; and setting a table for a second bridge to the second device, wherein the first bridge and the second bridge may be used for processing the data packet based on the first pipeline and the second pipeline.

[0011] According to various embodiments of the present disclosure, in a wireless communication system, a method performed by a programmable first hardware device may include the steps of transmitting, to a network entity, information about a pipeline corresponding to the first hardware device; setting a pipeline for processing a data packet in the hardware device based on the information about the pipeline, wherein the pipeline is separated from the pipeline for processing the data packet; receiving, from the network entity, a table for a bridge; receiving a data packet; processing a portion of the data packet corresponding to the pipeline set in the first hardware device; and transmitting, to a second hardware device, the data packet using a header including a pipeline identifier (ID) and a pipeline header vector (PHV) based on the table for the bridge.

[0012] The present disclosure provides an electronic device and method capable of effectively providing a service in a wireless communication system.

[0013] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0014] FIG. 1A illustrates a communication network including core network entities in a wireless communication system according to various embodiments of the present disclosure.

[0015] FIG. 1b illustrates a wireless environment including a core network in a wireless communication system according to various embodiments of the present disclosure.

[0016] FIG. 2A illustrates an example of a functional structure of a hardware device according to embodiments of the present disclosure.

[0017] FIG. 2b illustrates an example of a functional structure of a network entity according to embodiments of the present disclosure.

[0018] FIG. 3A illustrates an example of offloading of network functions according to embodiments of the present disclosure.

[0019] FIG. 3b illustrates an example for decomposing or reconstructing packet forwarding control protocol (PFCP) rules according to embodiments of the present disclosure.

[0020] FIG. 4 illustrates an example of a pipeline of network functions according to embodiments of the present disclosure.

[0021] FIGS. 5A and 5B illustrate an example of a pipeline of network functions through multiple devices according to embodiments of the present disclosure.

[0022] FIGS. 6A and 6B illustrate examples of headers for a bridge of a pipeline according to embodiments of the present disclosure.

[0023] FIG. 7 illustrates a signal flow for distributing network functions to multiple devices according to embodiments of the present disclosure.

[0024] FIG. 8 illustrates an operational flow for distributing network functions to multiple devices according to embodiments of the present disclosure.

[0025] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. It should be noted that, where possible, identical components are represented by identical reference numerals throughout the drawings. Furthermore, detailed descriptions of well-known functions and configurations that may obscure the gist of the present invention will be omitted.

[0026] In describing the embodiments herein, descriptions of technical details that are well-known in the technical field to which the present invention pertains and are not directly related to the present invention will be omitted. This is to avoid obscuring the gist of the present invention by omitting unnecessary explanations and to convey the gist more clearly.

[0027] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0028] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0029] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a 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 create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0030] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0031] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (field programmable gate array) or ASIC (application specific integrated circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to play one or more central processing units (CPUs) within the device or secure multimedia card.

[0032] The embodiments of the present disclosure described below may also be applied to other communication systems with similar technical backgrounds or channel types. Furthermore, the embodiments of the present disclosure may be applied to other communication systems with some modifications, as determined by a person skilled in the art, without significantly departing from the scope of the present disclosure.

[0033] In the following description, terms used to identify connection nodes, terms referring to network entities or network functions (NFs), terms referring to messages, terms referring to interfaces between network objects, terms referring to various identification information, etc. are examples provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0034] For convenience of explanation, some terms and names defined in the 3rd generation partnership project long-term evolution (3GPP) standards may be used. However, the present invention is not limited to the terms and names described herein, and can be equally applied to systems conforming to other standards. In particular, the present disclosure can be applied to the 3GPP 5th generation mobile communication standards (e.g., 5GS and NR).

[0035] FIG. 1A illustrates a communication network including core network entities in a wireless communication system according to various embodiments of the present disclosure. The 5G mobile communication network may be configured to include a 5G user equipment (UE) (110), a 5G radio access network (RAN) (120), and a 5G core network.

[0036] The 5G core network may be configured to include network functions such as an access and mobility management function (AMF) (150) that provides a mobility management function of UE, a session management function (SMF) (160) that provides a session management function, a user plane function (UPF) (170) that performs a data transfer role, a policy control function (PCF) (180) that provides a policy control function, a unified data management (UDM) (153) that provides a data management function such as subscriber data and policy control data, or a unified data repository (UDR) that stores data of various network functions.

[0037] Referring to FIG. 1A, a user equipment (UE) (110) may communicate with a base station (e.g., an eNB, a gNB) via a wireless channel, i.e., an access network. In some embodiments, the UE (110) may be a device used by a user and configured to provide a user interface (UI). As an example, the UE (110) may be a terminal mounted (equipment) on a vehicle for driving. In some other embodiments, the UE (110) may be a device that performs machine type communication (MTC) that operates without user intervention, or may be an autonomous vehicle. UE may be referred to as a 'terminal', 'vehicle terminal', 'user equipment (UE)', 'mobile station', 'subscriber station', 'remote terminal', 'wireless terminal', or 'user device' or other terms having equivalent technical meanings, other than electronic devices. As the terminal, in addition to the UE, a customer-premises equipment (CPE) or a dongle-type terminal may be used. The CPE, while connected to the NG-RAN node like the UE, may also provide a network to other communication devices (e.g., a laptop).

[0038] Referring to FIG. 1A, the AMF (150) provides a function for connection and mobility management for each terminal (110), and basically, one AMF (150) can be connected to one terminal (110). For example, the AMF (150) may be a network function that manages the mobility of the terminal. Specifically, the AMF (150) may perform at least one of signaling between core network nodes for mobility between 3GPP access networks, an interface (N2 interface) between wireless access networks (e.g., 5G RAN) (120), NAS signaling with the terminal (110), identification of the SMF (160), and provisioning of transmission of session management (SM) messages between the terminal (110) and the SMF (160). Some or all of the functions of the AMF (150) may be supported within a single instance of one AMF (150).

[0039] Referring to FIG. 1A, the SMF (160) provides a session management function, and when a terminal (110) has multiple sessions, each session may be managed by a different SMF (160). For example, the SMF (160) may be a network function that manages a packet data network (PDN) connection provided to the terminal. The PDN connection may be referred to as a protocol data unit (PDU) session. Specifically, the SMF (160) may perform at least one of the following functions: session management (e.g., session establishment, modification, and teardown, including maintaining tunnels between the UPF (170) and access network nodes), selection and control of user plane (UP) functions, traffic steering setup to route traffic to appropriate destinations in the UPF (170), termination of the SM portion of NAS messages, downlink data notification (DDN), and initiation of AN-specific SM information (e.g., forwarding it to the access network via the N2 interface via the AMF (150)). Some or all of the functions of the SMF (160) may be supported within a single instance of one SMF (160).

[0040] Referring to FIG. 1A, the PCF (180) may be a network function that applies a mobile communication service provider's service policy, charging policy, and policy for PDU Session to a terminal. According to one embodiment, the UDM (153) may be a network function that stores information about a subscriber. According to one embodiment, the UPF (170) may be a function that acts as a gateway that transfers user data (e.g., PDU) to a data network (DN). According to one embodiment, the network repository function (NRF) (159) may perform a function of identifying a NF. According to one embodiment, the authentication server function (AUSF) (151) may perform terminal authentication in a 3GPP access network and a non-3GPP access network. According to one embodiment, the network slice selection function (NSSF) (190) may perform a function of selecting a network slice instance provided to a terminal. According to one embodiment, DN (140) may be a data network through which a terminal transmits and receives data in order to use a network operator's service or a third-party service.

[0041] In the 3GPP system, conceptual links connecting NFs within a 5G system may be referred to as reference points. Reference points may also be referred to as interfaces. The following exemplifies reference points (hereinafter, interchangeably referred to as interfaces) included in the 5G system architecture represented across various embodiments of the present disclosure.

[0042] - N1: Reference point between UE (110) and AMF (150)

[0043] - N2: Reference point between (R)AN(120) and AMF(150)

[0044] - N3: Reference point between (R)AN(120) and UPF(170)

[0045] - N4: Reference point between SMF (160) and UPF (170)

[0046] - N5: Reference point between PCF (180) and AF (130)

[0047] - N6: Reference point between UPF (170) and DN (140)

[0048] - N7: Reference point between SMF (160) and PCF (180)

[0049] - N8: Reference point between UDM (153) and AMF (150)

[0050] - N9: Reference point between two core UPFs (170)

[0051] - N10: Reference point between UDM (153) and SMF (160)

[0052] - N11: Reference point between AMF (150) and SMF (160)

[0053] - N12: Reference point between AMF (150) and Authentication Server Function (AUSF) (151)

[0054] - N13: Reference point between UDM (153) and authentication server function (151)

[0055] - N14: Reference point between two AMFs (150)

[0056] - N15: For non-roaming scenarios, reference point between PCF (180) and AMF (150), for roaming scenarios, reference point between PCF (180) and AMF (150) within the visited network.

[0057] Furthermore, while the embodiments of the present disclosure are described below using a 5G system as an example, the embodiments of the present disclosure can also be applied to other communication systems with similar technical backgrounds. Furthermore, the embodiments of the present disclosure can be applied to other communication systems with some modifications, as determined by a person skilled in the art, without significantly departing from the scope of the present disclosure.

[0058] According to various embodiments of the present disclosure, 5GC may include NFs as illustrated in FIG. 1A. Of course, the present invention is not limited to the example of FIG. 1A, and 5GC may include more or fewer NFs than the NFs illustrated in FIG. 1A.

[0059] FIG. 1B illustrates a wireless environment including a core network in a wireless communication system according to various embodiments of the present disclosure. Referring to FIG. 1B, the wireless communication system includes a radio access network (RAN) (120) and a core network (CN).

[0060] The wireless access network (120) is a network that is directly connected to a user device, for example, a terminal (110), and is an infrastructure that provides wireless access to the terminal (110). The wireless access network (120) includes a set of multiple base stations including a base station (125), and the multiple base stations can communicate through interfaces formed between each other. At least some of the interfaces between the multiple base stations can be wired or wireless. The base station (125) can have a structure separated into a central unit (CU) and a distributed unit (DU). In this case, one CU can control multiple DUs. In addition to the base station, the base station (125) can also include an 'access point (AP)', a 'next generation node B (gNB)', and a '5G node (5G)'. th The terminal (110) may be referred to as a 'generation node', a 'wireless point', a 'transmission / reception point (TRP)', or other terms having an equivalent technical meaning thereto. The terminal (110) connects to a wireless access network (120) and communicates with a base station (125) through a wireless channel. The terminal (110) may be referred to as a 'user equipment (UE)', a 'mobile station', a 'subscriber station', a 'remote terminal', a 'wireless terminal', a 'user device', or other terms having an equivalent technical meaning thereto.

[0061] The core network is a network that manages the entire system, controls the wireless access network (120), and processes data and control signals for terminals (110) transmitted and received through the wireless access network (120). The core network performs various functions, such as controlling the user plane and the control plane, processing mobility, managing subscriber information, billing, and interworking with other types of systems (e.g., long term evolution (LTE) system). In order to perform the various functions described above, the core network may include a number of functionally separated entities with different NFs. For example, the core network (200) may include an AMF (150), an SMF (160), an UPF (170), a PCF (180), an NRF (159), a UDM (153), an NEF (155), and a UDR (157).

[0062] The terminal (110) is connected to the wireless access network (120) and accesses the AMF (150) that performs the mobility management function of the core network. The AMF (150) is a function or device that is in charge of both the connection to the wireless access network (120) and the mobility management of the terminal (110). The SMF (160) is an NF that manages sessions. The AMF (150) is connected to the SMF (160), and the AMF (150) routes session-related messages for the terminal (110) to the SMF (160). The SMF (160) is connected to the UPF (170) to allocate user plane resources to be provided to the terminal (110), and establishes a tunnel for transmitting data between the base station (125) and the UPF (170). PCF (180) controls information related to policy and charging for the session used by the terminal (110).

[0063] The NRF (159) stores information about NFs installed in a mobile communication operator network and performs the function of notifying the stored information. The NRF (159) can be connected to all NFs. When each NF starts operating in the operator network, it registers with the NRF (159) to notify the NRF (159) that the NF is operating within the network. The UDM (153) is an NF that performs a role similar to the HSS (home subscriber server) of a 4G network, and stores the subscription information of the terminal (110) or the context used by the terminal (110) within the network.

[0064] NEF(155) is a third party (3 rd The NEF (155) plays a role in connecting the NF within the 5G mobile communication system and the server. For example, the NEF (155) may have a function of providing information about the terminal to a server outside the 5G network. In addition, the NEF (155) may provide a function of providing information necessary for service to the 5G network and storing it in the UDR. The NEF (155) plays a role in providing or updating data to the UDR (157), or acquiring data. The UDR (157) may store subscription information of the terminal 120, store policy information, store data exposed to the outside, or store data for use by a third-party application (3). rd It performs the function of storing information required for a party application. In addition, UDR (157) also performs the role of providing stored data to other NFs.

[0065] FIG. 2A illustrates an example of the functional structure of a hardware device according to embodiments of the present disclosure. Terms such as "part," "unit," etc., used hereinafter, refer to a unit that processes at least one function or operation, which may be implemented using hardware, software, or a combination of hardware and software.

[0066] Referring to FIG. 2a, the hardware device includes a communication unit (210), a storage unit (230), and a control unit (220).

[0067] The communication unit (210) performs functions for transmitting and receiving signals or data via a wireless channel. However, the communication unit (210) is not limited thereto, and it goes without saying that the communication unit (210) can perform functions for transmitting and receiving signals or data via a wired channel.

[0068] The communication unit (210) transmits and receives signals as described above. For example, the communication unit (210) converts a bit string transmitted from a network entity to another device into a physical signal, and converts a physical signal received from another device into a bit string. According to one embodiment, the communication unit (210) may transmit and receive information between a hardware device and a network entity for the purpose of deploying network functions. Accordingly, all or part of the communication unit (210) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In addition, in the following description, transmission and reception performed through a wireless or wired channel are used to mean that the communication unit (210) performs the processing described above.

[0069] The storage unit (230) stores data such as basic programs, application programs, and setting information for the operation of the hardware device. The storage unit (230) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (230) provides stored data upon request from the control unit (220).

[0070] The control unit (220) controls the overall operations of the hardware device. For example, the control unit (220) transmits and receives signals through the communication unit (210). In addition, the control unit (220) records and reads data in the storage unit (230). To this end, the control unit (220) may include at least one processor (or controller) or microprocessor, or may be a part of a processor. According to various embodiments, the control unit (220) may control to request or distribute offloading of various network functions. For example, the control unit (220) may control the hardware device to perform operations according to various embodiments described below.

[0071] According to various embodiments, the hardware device illustrated in FIG. 2A may include a programmable hardware device. For example, the hardware device may include at least one of various programmable circuit devices (such as an application specific integrated circuit (ASIC), a network interface controller (NIC), an intelligence processing unit (IPU), a data processing unit (DPU), a CPU, etc.). According to various embodiments of the present disclosure, the hardware device is merely an example, and the hardware device or devices described below including FIG. 2A may include a device capable of pipeline programming or a device capable of programming a packet processing method, and the like, but are not limited thereto, may include equivalent and various devices (e.g., hardware or software) such as a virtualized switch.

[0072] In one embodiment, the programmable hardware device may allow users to program network applications using various languages, optimize the design of packet pipelines, or be protocol independent. In one embodiment, a NIC, IPU, DPU, etc. are a type of network interface card that provides programming functions instead of a CPU, and may be used to accelerate networking, storage, and security functions. In one embodiment, the programmable hardware device may offload a subset of a host virtual network function (VNF), such as a UPF, enable independent programming regardless of a specific protocol or operator, and may have the characteristics of higher throughput and lower latency than data processing by a conventional CPU. Hereinafter, according to various embodiments of the present disclosure, the hardware device may be replaced with various expressions having substantially the same meaning, such as a first device, a second device, a device, a programmable hardware device, etc.

[0073] FIG. 2B illustrates an example of a functional structure of a network entity according to embodiments of the present disclosure. The configuration illustrated in FIG. 2B can be understood as a configuration of a device having the function of at least one of the network entities, including the UPF (170) of FIG. 1 or a central control unit included in the UPF (170). Terms such as “… unit” and “… unit” used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0074] Referring to the above drawing 2b, the network entity is configured to include a communication unit (240), a storage unit (260), and a control unit (250).

[0075] The communication unit (240) provides an interface for a network entity to communicate with other devices within the network. For example, the communication unit (240) converts a bit string transmitted from the network entity to another device into a physical signal, and converts a physical signal received from another device into a bit string. For example, the communication unit (240) can transmit and receive signals. According to one embodiment, the communication unit (240) can transmit and receive information between a hardware device and a network entity for the purpose of deploying network functions. Accordingly, all or part of the communication unit (240) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit (240) enables the core network entity to communicate with other devices or systems via a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or via the network. Additionally, in the following description, transmission and reception performed through a wireless or wired channel are used to mean that processing as described above is performed by the communication unit (240).

[0076] The storage unit (260) stores data such as basic programs, application programs, and configuration information for the operation of the network entity. The storage unit (260) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, the storage unit (260) provides stored data upon request from the control unit (250).

[0077] The control unit (250) controls the overall operations of the network entity. For example, the control unit (250) transmits and receives signals through the communication unit (240). In addition, the control unit (250) records and reads data in the storage unit (260). To this end, the control unit (250) may include at least one processor (or controller) or microprocessor, or may be a part of a processor. According to various embodiments, the control unit (250) may control to request or distribute offloading of various network functions. For example, the control unit (250) may control a hardware device to perform operations according to various embodiments described below.

[0078] According to various embodiments, a network entity may include a NF or a unit contained within an NF. For example, a network entity may include a central control unit that analyzes or identifies pipelines within the UPF and installs them on each hardware device accordingly. It should be understood that, according to various embodiments of the present disclosure, the network entity may be replaced with various expressions having substantially the same meaning, such as a central control unit, a central control entity, or a controller.

[0079] In wireless communication systems, a device or object responsible for transmitting user data can receive rules or commands from a device or object in the control plane and, accordingly, perform operations related to user packet processing. Based on 5G wireless communications, the SMF located in the control plane can control the UPF based on the Packet Forwarding Control Protocol (PFCP). Meanwhile, the traffic processing volume required in wireless communication networks is increasing every year, and these requirements are further heightened as communication technology generations change.

[0080] For example, in 6th generation wireless communications, a greater number of terminals may require the generation and transmission of greater amounts of data to utilize various applications. To efficiently transmit data generated by terminals and applications, the installation, updating, or deletion of efficient packet processing rules for handling each traffic is required. Furthermore, as described above, methods for offloading specific rules to hardware devices are being considered to accelerate the packet processing capacity of the data plane. The present disclosure proposes a method for effectively processing the aforementioned packet processing rules in such cases, thereby providing a method for modifying packet processing rules without wasting resources or degrading performance.

[0081] For example, a typical network device may only perform network forwarding or switching functions, not network functions, or may only support single-device offloading, which may cause problems of redundant operations among multiple devices. Various embodiments of the present disclosure propose a rule distribution procedure for interworking among multiple devices, and an API (Application Programming Interface) or protocol for interworking with other control units, based on a new device topology structure resulting from the introduction of a central control unit (or controller). Accordingly, multiple different programmable devices can be interlocked to perform operations, thereby improving offloading efficiency and enhancing the freedom of rule arrangement. Furthermore, according to various embodiments, a rule arrangement algorithm that dynamically reflects the characteristics of each device or network conditions is introduced, thereby preventing redundant operations among multiple devices.

[0082] In one embodiment, offloading may mean, for example, an operation of installing a network function (including, for example, a logical function or a virtual function) into a software or hardware device, and may be replaced with various expressions having substantially the same meaning, such as setting, transferring, embedding, or provisioning.

[0083] Based on the existing 5G system, the definition of operations between the SMF, which executes control commands, and the UPF, which forwards packets based on these commands, can be performed according to procedures defined in 3GPP. For example, procedures can be defined for the SMF to communicate to the UPF how packets should be processed, such as how to transfer (e.g., forward) specific packets, and how packets should be processed, such as the QoS (quality of service) level of the specific packet.

[0084] Meanwhile, software switches and network services responsible for UPF or data processing can be softwareized, enabling them to perform a variety of operations in cloud environments such as virtual machines and containers. Typically, packet processing software in these environments utilizes general-purpose resources like CPUs and memory to process packets. However, due to the high cost and slow processing speed of general-purpose resources, methods have been considered for accelerating packet processing by offloading portions of the process to hardware.

[0085] Here, the hardware to which packet processing is offloaded typically operates as a black box or fixed function, with specific functions pre-programmed. However, with the recent introduction of FPGAs and programmable ASICs, methods for dynamically offloading generalized network programs to hardware are emerging. However, the capacity of this hardware is typically smaller than the overall cloud infrastructure capacity, requiring methods to enhance its efficiency.

[0086] According to various embodiments, a network packet processing device implemented as a UPF or software may include a pipeline, which is a series of processes for processing packets. A pipeline may include both logical processes and physical tunnels, and may refer to a path through which various network function operations are serially performed. However, this is merely an example, and the term "pipeline" described below may include any alternative term having substantially the same meaning.

[0087] Pipelines can be further subdivided into pipeline modules that perform specific functions. Typically, the modules that make up a pipeline can be connected serially, and packets being processed can be processed sequentially according to the defined modules.

[0088] At this time, a match and action structure can be generally used to define the rules processed by each module. Here, a match can include packet criteria for performing a specific action on the packet. The packet criteria can be defined or generated as internal metadata, such as information directly extractable from the packet header, such as the header type, the sender / receiver address, and port information, as well as specific processing results, such as hash values ​​generated through internal processes and regular expression matching, and thus can be utilized for the match.

[0089] Packets identified as meeting the aforementioned match conditions can perform actions dependent on the match (binding or containing). At this time, according to various embodiments of the present disclosure, the processing structure of the match table and each pipeline module may not correspond one-to-one. For example, a single match table may be divided into multiple stages, i.e., distributed into hardware-processable units, and performed on an actual hardware device.

[0090] Referring to the hardware device structure described above, the availability of specific operations or processing, or the absolute / relative performance, may vary depending on the hardware type. However, most current hardware-based offloading technologies offload a pipeline capable of executing the entire match-and-action table provided by a network service or function, in a one-to-one correspondence to each device. Therefore, problems may arise where operations or processing performed on previous devices (e.g., previous modules) are repetitively performed, or where certain operations are forced to be performed due to the nature of the pipeline structure, even if the absolute or relative performance of the operation is low or requires a high cost. Therefore, these problems can naturally reduce the resource efficiency of the network between the sender and receiver of the service. Furthermore, the lack of detailed procedures, rules, and data structures for offloading in current technologies may prevent interoperability between multiple offloading devices. Furthermore, duplication of processing or unsupported operations, such as header parsing, may occur between devices.

[0091] Before describing various embodiments of the present disclosure, an example of packet processing acceleration and UPF offloading is described with reference to FIG. 3A.

[0092] FIG. 3A illustrates an example of network function offloading according to embodiments of the present disclosure. Specifically, prior to describing various embodiments of the present disclosure, an example of packet processing acceleration and UPF offloading is described with reference to FIG. 3A.

[0093] Packet processing can be accelerated through offloading of packet processing (e.g., including header matching, action rules, etc.) according to various embodiments of the architecture. In one embodiment, offloading of UPF functions for packet processing (e.g., offloading based on PDR or FAR controlled by PFCP) can result in different offloading throughputs depending on various devices or architectures.

[0094] Referring to FIG. 3A, a logical structure (310) of a general computing architecture may include a host device (311) including a general-purpose processor (e.g., CPU) (312). The logical structure (310) of the computing architecture may further include a network (313) connected to the host device (311) by a peripheral component interconnect express (PCIe), and the network (313) may include an entity (314) for accelerating a data plane and an entity (316) for parsing or classifying packets, and may transmit and receive packets with other networks. In one embodiment, the network (313) may include a programmable device such as a DPU, an IPU, or an ASIC, and a smart network.

[0095] Referring to FIG. 3A, in addition to the above, a UPF function separation (320) structure may be further considered. According to the UPF function separation (320), the network (323) can detect the acquired packet and, accordingly, determine whether there is a match (326). Thereafter, if rapid processing is required, action (324) can be performed, or if rapid processing is not necessary, action (322) can be performed by falling back to the host (321). In this case, if the host (321) performs action (322), there may be an advantage of increased packet processing flexibility, and conversely, if the network (323) processes action (324), performance improvement can be expected. According to one embodiment, in order to utilize the above-described UPF function separation (320) structure, the UPF may utilize various rules, such as a rule for traffic forwarding (FAR (forwarding action rule)), a rule for steering or routing (MAR (multi-access rule)), a rule for usage reporting (URR (usage reporting rule)), or a rule for buffering (BAR (buffer action rule)). According to one embodiment, as described above, based on an edge gateway according to the UPF function separation, the load of the UPF may be distributed, an extended network such as a virtual extension local area network (VxLAN) may be supported, and chaining of various services may be performed.

[0096] Against this backdrop, various embodiments of the present disclosure propose a method for increasing overall resource efficiency by separating the hardware or software pipelines for processing network packets and allowing them to operate in different locations. As described above, multiple heterogeneous hardware or virtualized packet processing devices may have different performance or structures, and thus may have advantages and disadvantages in processing specific operations or tasks. In this case, various embodiments can position the pipeline functions based on the smallest unit of packet processing (e.g., network functions for each module) so that each processing can be performed on an efficient device, thereby increasing the resource efficiency of the overall packet processing device system. Furthermore, since tasks appropriate for increased throughput can be performed on corresponding hardware devices, an increase in throughput and a decrease in processing time can be expected. Ultimately, the advantages of various embodiments of the present disclosure will improve the quality of network services provided by wireless communication devices or packet processing devices.

[0097] Before describing various embodiments of the present disclosure, an example of rule reconstruction for matching and action of UPF is described with reference to FIG. 3b.

[0098] FIG. 3b illustrates an example for decomposing or reconstructing packet forwarding control protocol (PFCP) rules according to embodiments of the present disclosure.

[0099] Referring to FIG. 3b, the SMF (330) can control the UPF-CP (control plane) (340) based on the PFCP. In addition, the UPF (e.g., UPF-CP) (340) can offload network functions to programmable devices (350) during the process of processing or transmitting acquired packets. The programmable devices (350) can include at least one of a programmable switch (352), a NIC (354), or a CPU (356).

[0100] In one embodiment, a process (345) for performing match and action operations according to PFCP by the UPF (or including a separate central control unit, hereinafter referred to as UPF for convenience) is described in more detail, wherein the UPF can be controlled from the SMF based on PFCP. In one embodiment, the rules or operations (e.g., match and action) available to each user plane device may vary from device to device. In addition, the control messages (e.g., PFCP messages) delivered in the control plane and the rules offloaded to the devices may also vary.

[0101] In one embodiment, the UPF can identify traffic to be forwarded based on the packet data record (PDR) acquired for each PFCP session context. The PDR contains information for matching data packets with specific processing rules, and can apply rules such as FAR, BER, URR, QER (Quality of Service enforcement rule), or MAR for matching. The PDR can also include rules for packet detection, duplication, or other matters. The UPF can encapsulate the identified traffic and use the FAR to forward it.

[0102] In one embodiment, UPF can decompose (or split) (346) a PDR based on a PFCP message into smaller operations. For example, UPF can identify a match and a list of actions based on the match. For example, UPF can extract matching fields, such as an IP address or a tunnel endpoint identifier (TEID), based on the PDR, and redefine FAR, BAR, or QER as actions.

[0103] In one embodiment, the UPF can reconstruct (347) the decomposed operation, at which time a new action, a bridge (or connection) action, can be defined that connects different pipeline devices.

[0104] In one embodiment, the UPF (or control unit, offloading entity) may partition some of the reconstructed rules to be offloaded to specific devices based on information about the offloadable devices. To this end, the UPF may preemptively collect information about the offloadable devices and define methods for providing such information. More specifically, the UPF may insert tags (e.g., bridge, pipeline ID) into specific devices, determine the gain (e.g., split gain) of the parsing operation compared to performing duplicate matching on a single device, and determine the point of functional separation so that a specific operation can be operated on the optimal device. At this time, considering the characteristics of the pipeline, it goes without saying that the path must be configured so that each rule can be processed serially.

[0105] According to one embodiment, the UPF may assign (348) each operation to each device as described above. For example, the UPF may assign or install which operation to perform at each separation point (e.g., DIV) by considering the point of functional separation. Of course, in this case, the bridge action defined above may be considered. According to one embodiment, the information that the UPF considers for assignment may include the type, capability and performance of the device, or current usage rate. The capability of the device may include the size of the register, the number of stages, the number of parallel pipelines, support for match tables (e.g., IP matching, offset value matching, Ethernet matching, etc.), operation speed, the number of ports, or the number / speed of the arithmetic logic unit (ALU), and the current usage rate may include the usage rate of static random access memory (SRAM), dynamic random access memory (DRAM), or computing resources.

[0106] Below, operations for more specific network function separation according to various embodiments of the present disclosure are described.

[0107] As described above, specific embodiments of the present invention propose operations that can be performed by utilizing a packet processing pipeline using multiple devices. Modifying or dividing portions of this packet processing structure is not feasible with conventional hardware devices. Therefore, the present disclosure can provide efficient resource utilization by allowing packet processing to take into account the characteristics and capacity of each device. To achieve this enhanced efficiency, the packet processing pipeline can be configured to maintain high resource utilization. Accordingly, if a device optimized for a specific operation exists, the operation can be configured to be processed by that device, thereby improving the overall quality of network services.

[0108] More specifically, according to various embodiments of the present disclosure, a plurality of programmable network devices and a controller (e.g., a central control unit) for controlling the network devices may be operated. The programmable network devices may install or operate a pipeline for user-defined packet processing.

[0109] The above-described device may be connected to additional network devices in addition to the data plane, and may further be connected to multiple general switches or routers that forward user packets. In addition, some of the programmable network devices can communicate with general-purpose hosts using CPUs, and can transmit and receive data. Some of the hosts may include the above-described network device controller. For example, referring to FIG. 3B, a structure (350) for offloading some functions of the UPF to multiple heterogeneous programmable network devices is illustrated. In this case, multiple switches or CPUs may be configured sequentially. In one embodiment, a NIC (e.g., a smartNIC) is typically located singly on the final host, virtual machine, or container in the packet forwarding path, but multiple NICs may be used depending on the user's configuration. For example, if packets can be transmitted between NICs through device-to-device communication that excludes the CPU, such as P2PDMA (peer-peer DMA (direct memory access)), multiple NICs may be used.

[0110] FIG. 4 illustrates an example of a pipeline of network functions according to embodiments of the present disclosure.

[0111] Referring to Fig. 4, according to the general pipeline structure (410) of the UPF, the operations of the UPF can be expressed as a series of modular structures. Accordingly, the offloading of network functions by the UPF can generally mean offloading the entire UPF pipeline to another hardware device. Accordingly, the entire packet processing can be handled by the rules offloaded to the device without the intervention of the CPU.

[0112] Referring to FIG. 4, the structure (420) of a device to which a generalized network function is offloaded is illustrated as described above. The device to which a network function corresponding to the entire pipeline is offloaded may serially include a PDR table, a FAR table, a QER table, and a URR table, and may sequentially process and transmit received packets. According to the above structure (420), a single device processes all operations that must be performed in the UPF, and the UPF must be implemented to be able to perform various operations such as PDR, FAR, QER, BAR, or URR together, and may additionally require the performance of various functions such as header modification operations such as GTP encapsulation / decapsulation, and packet payload detection such as DPI (deep packet inspection). In this case, offloading a network function that supports a large number of users such as the UPF using a single hardware device may generally be limited due to memory constraints, limitations in supported commands, etc.

[0113] To be more specific, a pipeline of a network device for general packet processing may be configured as a pipeline structure (410) in which modules of multiple stages sequentially process specific tasks. For example, when a packet is received, a process of checking whether the packet has an error, a process of checking whether the packet is processed by the device, a process of searching for a rule to which the packet corresponds, a process of determining how to manage (e.g., forward) the packet after it is matched, and a process of performing preprocessing for packet transmission may be sequentially performed. For example, a UPF that performs user packet forwarding of a general 5G wireless communication network may sequentially perform a series of processes such as packet reception, inspection, rule search, and rule application, as in the pipeline structure (410) of FIG. 4.

[0114] Typically, network devices are hardware devices, making dynamic programming after delivery nearly impossible. Therefore, they may be pre-designed to perform most packet processing functions. Therefore, a structure where a user performs some packet-related modules on another device and then continuously processes packets output from a specific device can be extremely difficult to implement on network devices that do not support general programming. For example, if a user splits a pipeline, the split point can vary depending on the user's usage method. Therefore, reprogramming the network device to perform the protocol or operation that reconnects the split pipeline pieces can be extremely challenging.

[0115] However, according to various embodiments of the present disclosure, some of the above-described problems can be solved based on the emergence of the software defined network (SDN) paradigm and the introduction of programmable devices. According to one embodiment, based on the programmable devices, a user can define a pipeline by himself, and can also divide the entire pipeline into multiple pipelines. Accordingly, various embodiments can configure a hardware device so that each module operates on a different hardware device. At this time, the pipeline module written in each module can use a high-level language such as C, a hardware operation description language such as HDL (hardware description language), and a new network programming language such as P4 (programming protocol-independent packet processors).

[0116] Configuring the entire pipeline to be processed by a single network device can have the advantage of simplifying management and maintenance tasks, as it only requires managing the topology through the configuration of specific devices. Furthermore, rather than performing a series of tasks entirely on a single host or device, adaptively and dynamically offloading tasks to multiple devices based on operational characteristics (e.g., resource availability) can be more efficient. For example, traffic or network functions for processing can be adaptively offloaded to multiple devices based on criteria such as encryption-related operations, memory-intensive operations considering the characteristics and state of network traffic, regular expression matching, or wildcard matching. The multiple devices can include devices of the same type or different types.

[0117] Accordingly, according to various embodiments of the present disclosure, it may be efficient to distinguish between effective devices for performing the individual functions described above, and to divide a single pipeline so that each device can perform an operation individually, thereby configuring a module group unit according to a plurality of devices.

[0118] Figures 5a and 5b illustrate an example of a network function pipeline across multiple devices according to embodiments of the present disclosure. Specifically, Figures 5a and 5b illustrate an example of dividing a UPF pipeline using multiple programmable devices and offloading it to each device.

[0119] Referring to FIG. 5A, according to one embodiment, a plurality of programmable network devices may have different packet processing characteristics or resource amounts. For example, a programmable switch device may include a ternary content-addressable memory (TCAM) that is not included in a NIC or a host, and thus may perform wildcard matching at a much faster speed than other devices. In addition, unlike other devices, the NIC has the characteristic of being able to perform operations such as URL (uniform resource locator) extraction based on DPI technology such as regular expressions. Various embodiments disclose a technique for dividing and embedding a packet processing pipeline into a plurality of hardware devices so that processing can be performed on the most optimal device for each of the various operations described above. In this process, a control unit (510) capable of managing or setting multiple devices by connecting them through a centralized unit is required, and the control unit (510) can embed a portion of the pipeline in each device (520, 530) through a command in a form that can be executed by each device (520, 530). In one embodiment, each device (520, 530) can include or process multiple pipelines in parallel. In this case, there may be a separate algorithm that calculates that the gain that can be obtained through dividing a single pipeline into multiple pipelines is higher than when using a single pipeline. Even in cases where a specific device capable of a specific operation is essential, the above-described placement optimization algorithm can be utilized to calculate which module should be efficiently embedded in which device.

[0120] Referring to FIG. 5A, the central control unit (510) may offload some of the network functions (e.g., PDR table, FAR table) to the first device (520) and the remaining some (e.g., QER table, URR table) to the second device (530) based on the characteristics of the programmable devices (520, 530). More specifically, the central control unit (510) or the host (e.g., the offloading subject host) may know in advance all the rules for the overall operation of the network functions, and each device may create, change, or remove rules for offloading the network functions by a specific control unit (510) or host. Accordingly, the central control unit (510) may divide one PDR or FAR into multiple operations when configuring the rules, and the divided operations may be identical to the entry structure or entry components of the match action table (MAT). In one embodiment, multiple devices (520, 530) can independently perform MAT-related operations, and the central control unit (510) can adaptively arrange the partitioned rules so that each device can perform optimized operations. For example, when wildcard matching is required, a rule is set for a device with a TCAM; when URL matching is required, a rule is set for a NIC device; or when exact or longest prefix matching is required, a device with available resources can be preferentially selected and set.

[0121] Referring to FIG. 5B, when configuring a pipeline using multiple devices, a configuration that allows for reconnection of the segmented pipelines is essential. Accordingly, the central control unit (510) can embed the segmented pipelines in each of the multiple devices (520, 530) through the aforementioned processes and optimized module layout. In this case, the segmented devices (520, 530) need to reconnect their respective pipelines, and thus, a bridge (or connection) table (540, 550) and a (bridge) action can be used. More specifically, to prevent duplication of operations performed in each pipeline, a tag (e.g., a pipeline ID (identifier)) for each pipeline can be used. The tag is intended to indicate whether a packet belongs to a logical pipeline, and can indicate that a portion of the match has already been performed. Accordingly, a bridge table (540, 550) for processing tags is located at the ingress portion of each device (520, 530), thereby preventing it from being processed in the same manner as other general traffic.

[0122] According to various embodiments of the present disclosure, with reference to more specific examples, FIGS. 5A and 5B illustrate examples in which the pipeline is divided based on FAR and QER when processing of rules such as PDR, FAR, QER or URR is required in UPF.

[0123] In one embodiment, after forwarding-related information of a specific packet is processed through FAR in the first device (520), the URR may be processed in the second device (530) for QoS and usage-related reporting. The second device (530) needs to identify that packets processed through FAR in some pipelines of the first device (520) should be sequentially processed in other pipelines of the second device (530). For this purpose, a pipeline ID may be transmitted from the first device (520) to the second device (530).

[0124] In one embodiment, additional information required for processing the operation of the second device (530) may also be transmitted together. Here, the additional information may include the processing result of a specific module such as FAR (e.g., an output port number determined by FAR), information parsed from the header, etc. In one embodiment, the structure storing the above-described additional information may be referred to as a packet header vector (PHV). In one embodiment, the PHV may include a value used for a match extracted from the packet header, and may be maintained throughout the entire process in which the packet is transmitted from the logical inlet to the output (egress) port. For example, the PHV may include part or all of the parsing information of the packet, intermediate values ​​of module processing, etc.

[0125] As described above, a bridge table (e.g., including a bridge Tx table or a bridge Rx table) (540, 550) and a bridge action (e.g., including a bridge Tx action or a bridge Rx action) can be defined as a method for connecting pipelines.

[0126] In one embodiment, the bridge table may refer to a table for distinguishing multiple pipelines. The bridge Tx table may be located at the end of a packet processing device and may be used to match actions that need to be performed when forwarding a packet to the next device. The bridge Rx table may be located at the front of a packet processing device and may be used to forward packets received from a device located at the front of the pipeline to the pipeline module requesting processing.

[0127] In one embodiment, a bridge action may refer to an action required to connect two partial pipelines into one. The bridge Tx action may insert an ID or tag that can distinguish the pipeline, and may perform a serialization action to transmit an intermediate result value of a processing operation. The bridge Rx action may be used to forward a received packet to a module following a previously processed pipeline, and may perform a de-serialization action to transmit an intermediate result value.

[0128] Below, the bridge table and the information used to transmit actions and PHVs are described in more detail.

[0129] Figures 6a and 6b illustrate examples of headers for a pipeline bridge according to embodiments of the present disclosure. More specifically, Figures 6a and 6b illustrate an information structure for conveying a pipeline ID and PHV for distributed match action table (MAT) chaining.

[0130] According to various embodiments of the present disclosure, a bridge table and a bridge action may refer to a MAT generated with a lightweight structure. For convenience of explanation, the portion corresponding to the front end of the pipeline, based on the split point, is referred to as Tx, and the portion corresponding to the back end is referred to as Rx.

[0131] In one embodiment, the Tx table may be used to perform an action to insert the ID of the pipeline currently being processed. In this case, there may be cases where the subsequent pipelines are processed in multiple ways or need to branch to other modules. Therefore, a table and multiple table entries may exist so that an action corresponding to the factor that serves as the basis can be searched. A packet containing a specific pipeline identifier and a portion of a PHV may be passed to a device processing the next part of the split pipeline via the Tx table and action, and the Rx device that receives the packet may parse the information inserted by the Tx device, restore the packet modified for bridging in the Tx, and ultimately pass it to the corresponding pipeline.

[0132] Referring to FIG. 6A, the identifier of the pipeline in which the packet is being processed and a portion of the PHV to be transmitted through the performance of the bridge action may include different information depending on the type of pipeline and the protocol used to process the packet. Various embodiments of the present disclosure may include a method of modifying and using the existing GTU-U (GPRS (general packet radio service) tunneling protocol-user plane) protocol or an extended method of using the IP protocol, etc. for this purpose.

[0133] According to various embodiments of the present disclosure, a method of transmitting the above-described information by extending a GTP-U packet header (610) and an IP packet header (620) is illustrated with reference to FIG. 6A. As described above, information included in the packet header may include a pipeline identifier (pipeline ID) and a portion of PHV data. In this case, a fixed memory length may be used for the pipeline ID so that the length is constant. However, since the PHV may continuously change depending on the type or number of data to be transmitted, information regarding the type or length of the data may be additionally included in the packet header. According to one embodiment, in this case, a pipeline that receives and processes a packet may restore the header of the changed packet and delete the packet header information that was temporarily used.

[0134] More specifically, for the GTP-U packet header (610), unused spare bits may be used to insert information for pipeline bridging. For example, a pipeline ID and PHV may be inserted into an extension header of a GTP tunnel. According to one embodiment, for an uplink (UL) using GTP, a rule positioned before information for GTP header decapsulation may be processed according to information for pipeline bridging. According to one embodiment, for a downlink (DL) using GTP, a rule positioned before information for GTP header encapsulation may be processed according to information for pipeline bridging. According to one embodiment, therefore, designing so that encapsulation / decapsulation can be performed at the end of the pipeline may be advantageous for PHV transmission.

[0135] Referring to a transmission without GTP that includes an IP packet header (620), if it is IPv4 or IPv6, information for pipeline bridging can be inserted by extending the protocol type. For example, in the case of VxLAN, a header extension method can be applied, and it can be inserted as a replacement for the Ethernet header or as a dedicated header before or after Eth.

[0136] According to various embodiments of the present disclosure, with reference to FIG. 6B, in addition to a structure that extends / modifies an existing packet to transmit data required for connecting a pipeline, a new header may be inserted into a specific section of the packet, and a new protocol for processing the same may be defined. With reference to FIG. 6B, the new structure may include an Ethernet header (602), a bridge header (608), an IP header (604), and data (606). According to one embodiment, data for the bridge may be inserted after the Ethernet header (602), which is commonly included in packets transmitted in an Ethernet network. The newly added header (608) may include a pipeline identifier, some data of a PHV (e.g., an intermediate value or metadata). More specifically, the main transmission data of the new header (608) may support a flexible information element (IE) to transmit the ID and PHV of the pipeline, where the pipeline ID may vary depending on the number of pipelines supported. The new header (608) can be expressed in the form of TLV (type, length, value) and can be generated to convey the type of each field, and can include information about, for example, the total length, the number of data, the first data length, the first data, the second data length, or the second data, in addition to the pipeline ID.

[0137] In one embodiment, the new header (608) may install or utilize a parser predefined in the pipeline Rx table. For example, the predefined Rx table may be configured as a two-step operation, including a process of obtaining a pipeline ID through the parser and an action for restoring a PHV. In this case, the delivery of the PHV may be determined by the central control unit, and if there is a table that has not been branched, the PHV may be determined not to be delivered.

[0138] In one embodiment, the pipeline ID may use a fixed memory length so that the length is constant, but the PHV may continuously change depending on the type and quantity of data to be transmitted, and thus the type and length of data may be additionally included in the packet header. In this case, the device corresponding to Rx in the pipeline division may operate to delete the added packet header information after receiving the packet, thereby preventing leakage of internal information and allowing normal packet processing to be performed in other devices.

[0139] FIG. 7 illustrates a signal flow for distributing network functions to multiple devices according to embodiments of the present disclosure. Referring to FIG. 7, specific procedures for performing operations according to various embodiments of the present disclosure are illustrated. Hereinafter, the control unit may include at least one of a central control unit, a controller, a UPF, a network entity, or a network control entity, and the device may include at least one of a software-implemented entity, a hardware device, or a programmable device.

[0140] In step (710), the control unit may receive device information from the first device or the second device. More specifically, the control unit may receive information about the first device from the first device and register the first device, or may receive information about the second device from the second device and register the second device. For example, a programmable network device may register information indicating that it is a programmable device or information about support functions related to packet processing with the control unit. This process may be performed separately from packet processing during the startup process of each device. According to one embodiment, the device information may include information about at least one of the device capacity corresponding to each device, the maximum number of pipelines, the performance of each pipeline, the size of the pipeline buffer, the capacity size of the rule for processing each pipeline, or additional information specifically described in FIGS. 4 to 5B. According to various embodiments, the process of the control unit receiving information about the devices from each device and registering the same is specifically described in FIGS. 4 to 5B.

[0141] At step (720), the control unit may receive a request for a pipeline for packet processing. In one embodiment, to transmit data (e.g., including both UL and DL) to an entity associated with the control unit, an external entity (e.g., including a user) may request the control unit to define a pipeline for processing a specific packet and configure (or install) it. In this process, the pipeline may receive a configuration request for a single pipeline capable of processing the entire network function.

[0142] In step (730), the control unit can identify a pipeline for processing data packets and divide it into multiple pipelines. More specifically, the control unit can analyze the pipeline for which installation is requested, and thereby obtain information on the type or capacity of required resources. Based on this, the control unit can determine whether the pipeline can be divided. In one embodiment, the control unit can determine whether the pipeline can be divided based on information identified about the pipeline (e.g., information about the pipeline for processing data packets, the type of matching for data packets, or the presence or absence of a processing engine for processing data packets, etc.) or device information received from each device. In addition, the control unit can determine whether to divide a single pipeline based on a specific module, or whether each divided pipeline should be set (or inserted) to a specific device. According to various embodiments, the process of the control unit receiving information about devices from each device and determining whether to divide the pipeline based on this is specifically described in FIGS. 4 to 5B.

[0143] In steps (740a) and (740b), the control unit can set each pipeline for which separation has been determined to its respective corresponding device. For example, the control unit can offload or set a first pipeline corresponding to a first device to the first device, and can offload or set a second pipeline corresponding to a second device to the second device. In one embodiment, steps (740a) and (740b) include a process for separating a single pipeline and installing it on each device, wherein the installation order of each device does not necessarily have to be the same as that illustrated in FIG. 7. In one embodiment, FIG. 7 includes an example of splitting a single pipeline into two, but is not limited thereto, and the same method can be applied even when the pipeline is split into two or more multiple parts. Through steps (740a) and (740b), a portion of each pipeline can be installed on a corresponding device so that the split module can be performed on each device. According to various embodiments, the process by which the control unit sets up a pipeline corresponding to each device is specifically described in FIGS. 4 to 5b.

[0144] In steps (750a) and (750b), the control unit may set a bridge table for each device. For example, the control unit may additionally set a table and actions for each device to connect separate pipelines. More specifically, the control unit may set a bridge Tx table for a device corresponding to the first half of the pipeline or a bridge Rx table for a device corresponding to the second half of the pipeline. In one embodiment, when the pipeline is divided into multiple parts, a device corresponding to the middle of the pipeline may of course be set with a bridge Rx table and a bridge Tx table. In one embodiment, the bridge-related table and actions set by the control unit may be performed simultaneously in steps (740a) and (740b) as part of a table installed together. In one embodiment, the bridge table set by the control unit for each device may be set using a header including information about a pipeline identifier or PHV. According to various embodiments, the header containing information about the pipeline identifier or PHV and the process of setting the same by the control unit are specifically described in FIGS. 4 to 6b.

[0145] At step (760), each device may receive a data packet requiring processing. For example, the data packet may be transmitted to the first device corresponding to the first half of the pipeline.

[0146] In step (770), the first device corresponding to the first half of the pipeline can process the first part of the packet corresponding to the pipeline included in the first device and insert a header for the bridge related thereto. In other words, since the pipeline for processing the packet is installed separately in the first device and the second device, the first half of the data packet can be processed by the first device, and thus the partially processed packet can be transmitted to the second device. According to various embodiments, the process of processing a portion of the packet and inserting a bridge-related header is specifically described in FIGS. 4 to 6B.

[0147] In step (780), the first device may transmit packet information containing data related to some processed packets or bridges to the second device. For example, since the first device has only performed a portion of the packet processing pipeline, it may insert an identifier of the current pipeline containing information about this and a portion of the PHV that must be transmitted into the packet and transmit it to the second device.

[0148] At step (790), the second device may receive the packet, remove the bridge-related header, and process the second portion of the packet corresponding to the pipeline included in the packet. More specifically, the second device that received the packet may obtain an identifier of a later pipeline to be processed subsequently or transmitted data from the packet, and may perform an operation to revert the existing packet to its original format. In one embodiment, the operation to revert the packet to its original format may be performed in batches during the process of manipulating the packet in the last module of the pipeline. In various embodiments, the process of processing the header-related portion of the packet and processing the remaining portion of the packet accordingly is specifically described in FIGS. 4 to 6B.

[0149] Through the above-described process, various embodiments of the present disclosure can improve the efficiency of packet processing by adaptively distributing network functions to each device, and each device can prevent the performance of redundant packet processing processes, thereby resulting in an increase in processing volume and a decrease in delay.

[0150] FIG. 8 illustrates an operational flow for distributing network functions to multiple devices according to embodiments of the present disclosure. Specific procedures for performing operations of a network entity (e.g., a control unit) according to various embodiments of the present disclosure are illustrated. Hereinafter, the network entity may include at least one of a control unit, a central control unit, a controller, a UPF, or a network control entity, and the device may include at least one of a software-implemented entity, a hardware device, or a programmable device.

[0151] In step (810), the network entity may receive information about a pipeline corresponding to each device. The network entity may receive device information from the first device or the second device. More specifically, the control unit may receive information about the first device from the first device and register the first device, or may receive information about the second device from the second device and register the second device. In one embodiment, step (810) may correspond to step (710) of FIG. 7. In various embodiments, the process of the network entity receiving information about the devices from each device and registering the information is specifically described in FIGS. 4 to 5B.

[0152] In step (820), the network entity may divide the pipeline for processing data packets into multiple pipelines. More specifically, the network entity may analyze the pipeline for which installation has been requested and, accordingly, obtain information on the type or capacity of required resources. Based on this, the network entity may determine whether the pipeline can be divided. In one embodiment, the network entity may determine whether the pipeline can be divided based on information identified about the pipeline (e.g., information about the pipeline for processing data packets, the type of matching for data packets, or the presence or absence of a processing engine for processing data packets, etc.) or device information received from each device. In one embodiment, although not illustrated in FIG. 8 , the network entity may receive a request for a pipeline for processing data packets from an external entity prior to the above-described operation. In one embodiment, step (820) may correspond to step (720) or step (730) of FIG. 7 . According to various embodiments, the process by which a network entity receives information about devices from each device and determines the separation of the pipeline based thereon is specifically described in FIGS. 4 to 5b.

[0153] In step (830), the network entity may configure portions of the pipeline corresponding to each device for each device. More specifically, the network entity may offload or configure a first pipeline corresponding to a first device to the first device, and may offload or configure a second pipeline corresponding to a second device to the second device. In one embodiment, step (830) may correspond to steps (740a) and (740b) of FIG. 7 . In various embodiments, the process of the network entity configuring pipelines corresponding to each device is specifically described in FIGS. 4 to 5B .

[0154] In step (840), the network entity may set information about the bridge corresponding to each device for each device. More specifically, the network entity may set a bridge Tx table for a device corresponding to the first half of the pipeline or a bridge Rx table for a device corresponding to the second half of the pipeline. In one embodiment, step (840) may correspond to steps (750a) and (750b) of FIG. 7 . In various embodiments, the header including information about the pipeline identifier or PHV and the process of setting the header are specifically described in FIGS. 4 to 6B .

[0155] According to various embodiments of the present disclosure, the above-described operational flow is merely exemplary and may not be limited thereto. For example, each step may not be individually considered an essential component, and, depending on one embodiment, the desired technical effect may be achieved by at least one of all, some, or a combination of the operations.

[0156] It should be noted that the aforementioned configuration diagrams, examples of control / data signal transmission methods, examples of operational procedures, and configuration diagrams are not intended to limit the scope of the present disclosure. For example, not all components, entities, or operational steps described in the embodiments of the present disclosure should be construed as essential components for implementing the disclosure, and implementations may be made without detracting from the essence of the disclosure even if only some components are included. Furthermore, each embodiment may be combined and operated as needed. For example, parts of the methods proposed in the present disclosure may be combined to operate network entities and terminals.

[0157] The operations of the base station or terminal described above can be realized by providing a memory device storing the corresponding program code in any component within the base station or terminal device. For example, the control unit of the base station or terminal device can execute the operations described above by reading and executing the program code stored in the memory device using a processor or CPU (Central Processing Unit).

[0158] The various components and modules of the entity, base station or terminal device described in this specification may be operated using hardware circuits, such as logic circuits based on complementary metal oxide semiconductors, firmware, software and / or hardware and firmware and / or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using electrical circuits such as transistors, logic gates and application-specific semiconductors.

[0159] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure.

[0160] These programs (software modules, software) may be stored in a non-volatile memory including random access memory, flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc ROMs (CD-ROMs), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0161] Additionally, the program may be stored in an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device performing an embodiment of the present disclosure.

[0162] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0163] While the detailed description of the present disclosure has described specific embodiments, it should be understood that 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, but should be determined not only by the scope of the claims described below but also by equivalents thereof. In other words, it will be apparent to those skilled in the art that other modifications based on the technical idea of ​​the present disclosure are possible. In addition, the above-described embodiments can be combined and operated with each other as needed. For example, parts of the methods proposed in the present disclosure can be combined with each other to operate a base station and a terminal. In addition, although the above-described embodiments have been presented based on a 5G, NR system, other modifications based on the technical idea of ​​the above-described embodiments can be implemented with other systems such as LTE, LTE-A, and LTE-A-Pro systems.

[0164] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

Claims

1. In a wireless communication system, a method performed by a network entity, A step of receiving, from one or more hardware devices, information about a pipeline corresponding to each of the one or more hardware devices; A step of separating the pipeline for processing data packets into a first pipeline and a second pipeline based on information about the above pipeline; A step of setting up a first pipeline to a first device among said one or more hardware devices; A step of setting up a second pipeline to a second device among said one or more hardware devices; a step of setting a table for a first bridge to the first device; and Including, for the second device, a step of setting a table for the second bridge, A method in which the first bridge and the second bridge are used for processing the data packet based on the first pipeline and the second pipeline.

2. In claim 1, the method comprises: A method further comprising the step of receiving a message requesting creation of a pipeline for processing said data packet.

3. In claim 1, the step of separating the first pipeline and the second pipeline comprises: A method comprising the step of separating the first pipeline and the second pipeline based on at least one of information about a pipeline for processing the data packet, a type of matching for the data packet, the presence or absence of a processing engine for processing the data packet, or a resource capacity of one or more devices.

4. In claim 1, information about a pipeline corresponding to each of the one or more hardware devices is: Each of said one or more hardware devices: A method comprising at least one of device capacity, maximum number of available pipelines, performance per available pipeline, buffer size of available pipelines, or capacity of processing rules per available pipeline.

5. In claim 1, A method wherein said one or more hardware devices include programmable devices.

6. In claim 1, A method in which a table for the first bridge or a table for the second bridge is set using a header including a pipeline identifier (ID) and a pipeline header vector (PHV).

7. In claim 6, The above header is included in the header of the GTP-U (GPRS (general packet radio service) tunneling protocol-user plane) protocol or the header of the IP (internet protocol) protocol.

8. In a wireless communication system, a method performed by a programmable first hardware device, A step of transmitting, to a network entity, information about a pipeline corresponding to the first hardware device, wherein a pipeline separated from a pipeline for processing data packets is set to the hardware device based on the information about the pipeline; A step of receiving a table for a bridge from the above network entity; Step of receiving a data packet; A step of processing a portion of the data packet corresponding to the pipeline set for the first hardware device; and A method comprising the step of transmitting, to a second hardware device, the data packet using a header including a pipeline identifier (ID) and a pipeline header vector (PHV), based on a table for the bridge.

9. In claim 1, information about a pipeline corresponding to the first hardware device is: Of the above first hardware device: A method comprising at least one of device capacity, maximum number of available pipelines, performance per available pipeline, buffer size of available pipelines, or capacity of processing rules per available pipeline.

10. In claim 8, The above header is included in the header of the GTP-U (GPRS (general packet radio service) tunneling protocol-user plane) protocol or the header of the IP (internet protocol) protocol.

11. In a wireless communication system, a network entity is: Transceiver; and Including a controller coupled with the above transceiver, The above controller, Receive information about a pipeline corresponding to each of said one or more hardware devices from one or more hardware devices, Based on the information about the above pipeline, the pipeline for processing data packets is separated into a first pipeline and a second pipeline, To a first device among the one or more hardware devices, setting up the first pipeline; To a second device among the one or more hardware devices, setting up the second pipeline, To the first device, set a table for the first bridge, and configured to set a table for the second bridge to the second device; The first bridge and the second bridge are network entities used for processing the data packets based on the first pipeline and the second pipeline.

12. In claim 11, the controller, A network entity further configured to receive a message requesting creation of a pipeline for processing said data packets.

13. In claim 11, to separate the first pipeline and the second pipeline, the controller, A network entity configured to separate the first pipeline and the second pipeline based on at least one of information about a pipeline for processing the data packet, a type of matching for the data packet, the presence or absence of a processing engine for processing the data packet, or a resource capacity of the one or more devices.

14. In claim 11, information about a pipeline corresponding to each of the one or more hardware devices is: Each of said one or more hardware devices: A network entity that includes at least one of the following: device capacity, maximum number of available pipelines, performance per available pipeline, buffer size of available pipelines, or capacity of processing rules per available pipeline.

15. In claim 11, The one or more hardware devices are network entities that include programmable devices.

Images