KR20210064983A - Open fronthaul network system and method for timestamping packet of the same - Google Patents

Abstract

The present invention relates to an open fronthaul network system including a time synchronization module that synchronizes a packet time with a time stamp value of a network device, and a method for granting a packet time stamp thereof, wherein even if an overflow occurs in a register of an elapsed time counter of a switch processor, a time stamp is allowed to be granted to a packet to achieve an UTC-format nanosecond-level accuracy at a hard-layer level by correcting thereof. The open fronthaul network system comprises: a plurality of RRHs; an RAN equipment; a plurality of OLTs; and a mobile communication core network.

Description

OPEN FRONTHAUL NETWORK SYSTEM AND METHOD FOR TIMESTAMPING PACKET OF THE SAME

The present invention relates to an open fronthaul network system and a network packet processing method using the same.

With the development of mobile communication technology, following the 4th generation mobile communication that processes large-capacity traffic at high speed, the 5th generation, which maintains high-speed processing of large-capacity traffic with low latency, and connects a large number of devices such as the Internet of Things Mobile communication technology is being developed.

In particular, research on wired and wireless backhaul, midhaul, and fronthaul is being actively conducted to smoothly provide high-speed/low-latency wireless transmission and simultaneous access to a large number of devices through a mobile communication access network. In order to do this, a huge 5G fronthaul construction cost and a monopoly based on the existing Radio Access Network (RAN) equipment vendor's own hall standard require a lot of cost to build a 5G RAN.

Therefore, as in the prior art, when a RAN equipment vendor uses a vendor-specific fronthaul standard, it is almost impossible to enter a new vendor, and there is a problem in that it causes a huge 5G RAN construction cost due to a monopoly by the existing RAN vendor. However, there is a demand for a technology that can implement various network functions through software.

On the other hand, quality monitoring of a mobile network is always important, and time synchronization at both ends of the monitoring device improves the accuracy of the analysis system, and thus is one of the important technical factors.

However, in order to provide time synchronization in the quality monitoring device, there is a problem in that an expensive network card (Network Interface Card) is used.

In addition, as the mobile network develops into MEC (Mobile Edge Computing), in order to determine the subscriber's traffic at the edge, all src/dst IPs must be acquired from the subscriber's packet.

However, since the conventional system was able to match only tunnel IPs (GTP Outer IPs) at the edge, it was impossible to distribute traffic according to the type of internal traffic in the edge cloud (Traffic Steering), and all traffic goes through the edge cloud, Due to this, unnecessary edge traffic was generated, which caused a lot of cost, and when load balancing only with the GTP Outer, only the base station was balanced, which caused a problem of concentration of balancing.

Also, with the introduction of 5G networks, EPC functions are reconfigured and mapped to 5GC network functions (NFs). In the control plane, the authentication, access control, and mobility control functions of the EPC MME are reconfigured into the 5GC Access and Mobility Management Function (AMF), and the session management functions of the EPC MME and GW-C are reconfigured into the 5GC Session Management Function (SMF).

As the user plane and the control pane are separated, a problem that the quality monitoring device needs to link the GTP user plane packet and the GTP control plane packet and transmit them together has emerged.

mapped to network functions (NFs). In the control plane, the authentication, access control, and mobility control functions of the EPC MME are reconfigured into the 5GC Access and Mobility Management Function (AMF), and the session management functions of the EPC MME and GW-C are reconfigured into the 5GC Session Management Function (SMF).

As the user plane and the control plane are separated, a problem that the quality monitoring device needs to link the GTP user plane packet and the GTP control plane packet and transmit them together has emerged.

Network Virtualization (NV) is defined as a function that allows the network to be more effectively integrated and supported with the virtual environment by creating a logical virtual network separated from the underlying network hardware.

Virtualization technology has been rapidly adopted in recent networks. Network virtualization is a logical virtual network that is executed independently from a physical network from hardware, and abstracts networking connections and services provided through hardware.

When applied to a network, virtualization creates a logical software-based view of hardware and software networking resources (switches, routers, etc.).

Physical networking devices are simply responsible for forwarding packets, while virtual networks (software) provide an intelligent abstraction that makes it easy to deploy and manage network services and underlying network resources. As a result, network virtualization can adapt the network to better support virtualized environments.

Through virtualization, you can leverage the efficiency and agility of software-based computing and storage resources.

Networks are moving towards greater virtualization, but more recently network virtualization has advanced further by actually separating the control and delivery planes, as suggested by Software Defined Networking (SDN) and Network Functions Virtualization (NFV).

Network virtualization must support multiple virtual network topologies on a single switch or set of switches independent of the underlying hardware. Since virtual network components use physical resources, they are defined as slices. These slices may represent L2 tenant switches, L3 tenant routers, or aggregate routers connecting various virtual slices together. Each slice has its own management rights, and the administrator of each slice must configure it like a physical switch or router. The requirement for these slices is that each slice can be connected to another slice virtually by design using logical slices or virtual LANs (VLANs), and must be efficiently mapped to the same hardware switch.

The most direct way to satisfy the requirements of the slide is to reserve a physical loopback port for each network slice interconnect. However, this method has many problems, such as being able to use only a limited number of physical loopback ports, and making it difficult to manage cables and the like.

An object of the present invention is to provide an open fronthaul network system and an open fronthaul network system that can implement various network functions in software without being dependent on a vendor by applying network dis-aggregation to a wired/wireless network.

Another object of the present invention is to provide a network packet intermediary apparatus capable of providing an accurate hardware time synchronization function even at a switch level with a small register storage space size, and a packet time stamping method thereof.

Another object of the present invention is to provide a network packet intermediary device capable of interlocking a GTP user plane packet and a GTP control plane packet and delivering the same to an analysis device, and a GTP correlation method thereof.

In addition, an object of the present invention is to provide a network packet intermediary apparatus capable of providing deep packet matching by extracting GTP inner information as well as GTP outer information of a packet at the switch level, and a deep packet matching method thereof.

Another object of the present invention is to provide a wired/wireless integrated network packet brokering device capable of handling a plurality of virtual networks without complicated cable management, regardless of a limited number of physical loopback ports, and a virtual router slicing method thereof.

A network packet brokering apparatus according to an embodiment of the present invention is a plurality of openflow edge switches connected to a plurality of legacy networks that are wireless access networks or wired access networks, wherein the plurality of openflow edge switches are connected to a switch group. a software defined network (SDN) controller for acquiring information on the plurality of openflow edge switches belonging to;

a legacy router container that treats a switch group including at least some of the plurality of switches as a virtual router, and generates routing information for a packet arriving at any one of the switch groups; and

The network application module is a network packet intermediary device including a network application module including modules that perform a function of controlling the operation and flow of packets according to a request through the controller,

The legacy routing container directs a plurality of network devices connected to the plurality of OpenFlow switches for generating legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router to the virtual router. It maps to the connected external network information,

The network application module includes a time synchronization module for synchronizing the time of the packet with the timestamp value of the network device,

The network packet relay device further includes a processor, the switch further includes a processor, the processor of the network packet relay device includes a clock for returning a time value, and the processor of the switch includes a time elapsed from a reference time in the processor. a register for storing a parameter, wherein the time synchronization module stores the time stamp in the packet by correcting the overflow of the time parameter from the register of the processor of the reference time switch when the switch receives a request for time stamping of the packet .

The controller of the network packet intermediary apparatus according to an embodiment of the present invention is a virtual radio network control module that maps a remote radio head (RRH) of the connected radio access network to external network information directly connected to the virtual router. may further include.

The controller of the network packet intermediary apparatus according to an embodiment of the present invention comprises a virtual wired network control module that maps an optical line terminal (OLT) of the connected wired access network to external network information directly connected to the virtual router. may include more.

The controller of the network packet intermediary apparatus according to an embodiment of the present invention comprises a distributed radio network control module that maps a digital unit (DU) of the connected radio access network to external network information directly connected to the virtual router. may include more.

In accordance with an embodiment of the present invention, there is provided a method for granting a packet time stamp of a network packet mediation device, comprising: acquiring, by a switch, a clock of a processor of the network packet mediation device;

updating the reference time parameter Tb of the switch with the obtained clock;

receiving, by the switch, a time stamp request of the packet;

updating, by the time synchronization module, the previous elapsed time parameter Tp of the switch to the current elapsed time parameter Tc;

acquiring, by the time synchronization module, an elapsed time value based on the parameter Tb from the switch as a parameter Tc;

comparing, by the time synchronization module, magnitudes of the parameter Tc and the parameter Tp;

updating, by the time synchronization module, when the parameter Tc is smaller than the parameter Tp by adding the parameter Tb by the sum of the parameter Tp and the correction value;

updating, by the time synchronization module, adding the parameter Tb by the parameter Tp when the parameter Tc is greater than or equal to the parameter Tp; and

The time synchronization module may include, by the switch, storing the parameter Tb in the packet as a time stamp.

The packet time stamping method of the network packet intermediary apparatus according to an embodiment of the present invention may use an IEEE 1588 Precision Time Protocol (PTP) synchronization protocol.

In the packet time stamping method of the network packet brokering apparatus according to an embodiment of the present invention, the parameter Tp and the parameter Tc may be stored in a register of a processor of the switch.

In the method for providing a packet time stamp by a network packet broker according to an embodiment of the present invention, the storage unit of the register may be 48 bits.

In the method for providing a packet time stamp by a network packet brokerage apparatus according to an embodiment of the present invention, in the step of storing the packet as a time stamp, the time stamp storage unit may be 64 bits.

In the method for assigning a packet time stamp of a network packet brokerage apparatus according to an embodiment of the present invention, the correction value in the updating step may be the maximum value of the storage unit of the register.

In the method for providing a packet time stamp by a network packet broker according to an embodiment of the present invention, the correction value of the updating step may be 4,294,967,294.

A network packet brokering apparatus according to an embodiment of the present invention is a plurality of openflow edge switches connected to a plurality of legacy networks that are wireless access networks or wired access networks, wherein the plurality of openflow edge switches are connected to a switch group. a software defined network (SDN) controller for acquiring information on the plurality of openflow edge switches belonging to;

a legacy router container that treats a switch group including at least some of the plurality of switches as a virtual router, and generates routing information for a packet arriving at any one of the switch groups; and

The network application module is a network packet intermediary device including a network application module including modules that perform a function of controlling the operation and flow of packets according to a request through the controller,

The legacy routing container directs a plurality of network devices connected to the plurality of OpenFlow switches for generating legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router to the virtual router. It maps to the connected external network information,

The network application module may include a GTP correlation module that interworks so that a GTP-C packet and a GTP-U packet of a flow packet can be delivered to the same outgoing port.

A GTP correlation module according to an embodiment of the present invention includes: a storage unit for storing a subscriber table for storing subscriber IMSI and a GTP session table for storing subscriber session information;

The GTP user plane packet is received from the port unit of the switch and transferred to the port unit of the switch designated in advance, the GTPU TEID of the GTP user plane packet is retrieved from the storage unit, and the outflow port of the GTP user plane packet is connected to the storage unit to store, GTP user plane delivery module; and

The GTP control plane packet is received from the port unit of the switch, the storage unit searches for the outgoing port of the GTP user plane packet connected to the GTPU TEID of the GTP control plane packet, and the port of the switch is identical to the searched outgoing port. and a GTP control plane forwarding module that forwards the received GTP control plane packet.

The network packet mediation apparatus according to an embodiment of the present invention may further include a processor, and the storage unit of the GTP correlation module may be located in the processor.

The storage unit of the GTP correlation module according to an embodiment of the present invention includes an IMSI table, an MME context table, and an SGW context table,

The subscriber table of the storage of the GTP correlation module is an IMSI table,

The GTP session table of the storage of the GTP correlation module includes an MME context table and an SGW context table,

The GTP session table of the storage unit of the GTP correlation module may further include a correlation table that stores correlations between the IMSI table, the MME context table, and the SGW context table.

The correlation table of the storage unit of the GTP correlation module according to an embodiment of the present invention may include a first correlation table, a second correlation table, a third correlation table, and a fourth correlation table.

In the method for assigning GTP correlation of a network packet intermediary device according to an embodiment of the present invention, a GTP user plane packet is received from a port unit of the switch and transferred to a predetermined port unit of a switch, and the GTP user plane packet is transmitted from the storage unit a GTP user plane forwarding step of retrieving the GTPU TEID of the packet and storing the outgoing port of the GTP user plane packet by connecting to a storage unit; and

The GTP control plane packet is received from the port unit of the switch, the storage unit searches for the outgoing port of the GTP user plane packet connected to the GTPU TEID of the GTP control plane packet, and the port of the switch is identical to the searched outgoing port. and a GTP control plane forwarding step of forwarding the received GTP control plane packet.

In the method for granting GTP correlation of a network packet intermediary device according to an embodiment of the present invention, the GTP correlation module uses the MME IP address as a key in the MME context table, and the bearer ID set including the MME IP, the bearer ID and the sequence and generating a record having the MME S11 TEID as a value;

generating, by the GTP correlation module, a record using the SGW IP address as a key in the SGW context table;

The GTP correlation module searches the SGW context table for a record having the SGW IP address as a key, and updates the SGW S11 TEID and the SGW S1U TEID;

generating, by the GTP correlation module, a record in the first correlation table with the MME S11 TEID as a key and the IMSI context and the SGW S11 TEID context as values;

generating, by the GTP correlation module, a record in the second correlation table with the SGW S11 TEID as a key and the MME S11 context as a value;

generating, by the GTP correlation module, a record in the third correlation table with the SGW S11 TEID as a key and the SGW S11 TEID context as a value;

generating, by the GTP correlation module, a record in the fourth correlation table with the eNB TEID and the eNB IP as the keys and having the SGW S1U TEID context value;

updating, by the GTP correlation module, the bearer ID set and eNB S1U TEID values including the MME IP, bearer ID and sequence of a record using the MME IP address as a key in the MME context table; and

generating, by the GTP correlation module, a record in the IMSI table with the IMSI as the key and the bearer ID set including the MME IP, bearer ID, and sequence as a value;

A wired/wireless integrated network packet brokerage device according to an embodiment of the present invention is a plurality of openflow edge switches connected to a plurality of legacy networks that are wireless access networks or wired access networks, wherein the plurality of openflow edge switches are switches. a Software Defined Network (SDN) controller that acquires information on the plurality of openflow edge switches belonging to a group;

a legacy router container that treats a switch group including at least some of the plurality of switches as a virtual router, and generates routing information for a packet arriving at any one of the switch groups; and

The network application module is a network packet intermediary device including a network application module including modules that perform a function of controlling the operation and flow of packets according to a request through the controller,

The legacy routing container directs a plurality of network devices connected to the plurality of OpenFlow switches for generating legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router to the virtual router. It maps to the connected external network information,

The network application module includes a GTP correlation module that interworks so that a GTP-C packet and a GTP-U packet of a flow packet can be delivered to the same outgoing port,

The network application module extracts, modifies, removes or inserts a GTP header or a VxLAN header of a flow packet, a deep packet matching module; includes;

The GTP correlation module includes a GTP session tracking module, a GTP user plane forwarding module, and a storage unit,

The deep packet matching module may control the GTP correlation module to match the GTP control plane packet and the GTP user plane packet.

Deep packet matching method of a network packet intermediary apparatus according to an embodiment of the present invention Deep packet matching module receiving a packet from the incoming port unit of the switch;

An incoming packet parsing step of extracting deep packet information from the packet received by the packet parsing module of the switch;

An incoming packet pipeline step of processing a packet with the information obtained by the deep packet matching module;

distinguishing a packet type from the packet information obtained by the deep packet matching module;

When the type of the distinguished packet is a GTP control plane packet, the GTP session tracking module queries the GTP control plane outflow table for a flow matching the packet to obtain the outgoing port part or outgoing port group to which the packet is sent. GTP control plane packet processing step; and

Network packet intermediary apparatus comprising a; when the type of the distinguished packet is a GTP user plane packet, the GTP user plane forwarding module queries the GTP user plane outflow table for a flow matching the packet to process the packet; of deep packet matching methods.

The parsing of an incoming packet according to an embodiment of the present invention includes: an incoming port parsing step in which the packet parsing module extracts incoming port information from the incoming packet;

*Ethernet protocol parsing step in which the packet parsing module extracts Ethernet protocol information from the incoming packet;

If the extracted Ethernet protocol information is VLAN, the packet parsing module performs a VLAN parsing step of extracting VLAN information from the incoming packet;

an IPv4 parsing step of extracting, by the packet parsing module, IPv4 information from an incoming packet when the extracted Ethernet protocol information is IPv4;

a TCP parsing step of extracting, by a packet parsing module, TCP information from an incoming packet when the extracted IPv4 protocol type is TCP;

an IMCP parsing step of extracting, by a packet parsing module, IMCP information from an incoming packet when the extracted IPv4 protocol type is IMCP;

an SCTP parsing step of extracting, by the packet parsing module 250, SCTP information from an incoming packet when the extracted IPv4 protocol type is SCTP;

UDP parsing step in which the packet parsing module extracts UDP protocol number information from the incoming packet;

when the extracted UDP protocol number is VxLAN, a VxLAN parsing step in which the packet parsing module extracts VxLAN information from the incoming packet;

GTP parsing step of extracting GTP information from the incoming packet by the packet parsing module when the extracted UDP protocol number is GTP;

an inner Ether parsing step in which the packet parsing module extracts inner Ether information from an incoming packet;

an inner IPv4 parsing step in which the packet parsing module extracts inner IPv4 information from the incoming packet; and

an inner TCP/UDP parsing step in which the packet parsing module extracts inner TCP and inner UDP information from the incoming packet; may include.

An incoming pipeline step according to an embodiment of the present invention comprises: an incoming port mapping step in which the deep packet matching module converts an incoming physical port into a logical port used in a match action table;

GTP filter application step of the deep packet matching module storing the processing of the packet corresponding to the GTP information extracted from the incoming packet in the outgoing port match action table; and

When the deep packet matching module has inner IPv4 information extracted from the incoming packet, the inner IPv4 filter application step of storing the processing of the packet corresponding to the extracted inner IPv4 information in the outgoing port match action table; may include.

The outgoing packet parsing step according to an embodiment of the present invention comprises: an incoming port filter number parsing step in which the deep packet matching module extracts the incoming port filter number from the outgoing packet;

Ingress port filter matching step in which the deep packet matching module queries the policy manager module for the incoming port filter number extracted from the outgoing packet;

if the matched incoming port filter number exists, extracting the matched incoming port action from the policy manager module;

GTP filter number parsing step in which the deep packet matching module extracts the GTP filter number from the outgoing packet;

GTP filter matching step in which the deep packet matching module queries the policy manager module for the GTP filter number extracted from the outgoing packet;

if the matched GTP filter number exists, extracting the matched GTP action from the policy manager module;

Inner IPv4 parsing step in which the deep packet matching module extracts inner IPv4 information from the outgoing packet;

Inner IPv4 matching step in which the deep packet matching module queries the policy manager module for inner IPv4 information extracted from outgoing packets;

if the matched inner IPv4 information exists, extracting the matched inner IPv4 action from the policy manager module; and

The deep packet matching module generates an outgoing packet and all the extracted action list pairs in the GTP user plane outgoing port match action table creating an action list.

A network packet brokerage apparatus according to an embodiment of the present invention applies Network dis-aggregation to a wired/wireless access network based on SDN (Software Defined Network), and separates the BBU and RRH for the wireless access network while separating the RAN By abstracting the protocol layer, it is possible to provide mutual compatibility with the existing vendor lock-in protocol through service chaining for each access device, and to provide various functional divisions based on open hardware/software.

In addition, the network packet intermediary apparatus according to an embodiment of the present invention includes a time synchronization module that synchronizes the time of the packet with the timestamp value of the network device. Even if an overflow of the register of the time counter occurs, it can be corrected to give the packet a timestamp with an accuracy of the UTC (Coordinated Universal Time) format nanosecond level at the hard-rare level.

In addition, the network packet intermediary apparatus according to an embodiment of the present invention includes a GTP correlation module that interworks so that a GTP-C packet and a GTP-U packet of a flow packet can be delivered to the same outgoing port, and uses the same. The GTP correlation method may provide correlation so that the GTP control plane packet and the GTP user plane packet can be delivered to the same outgoing port.

In addition, the network packet intermediary apparatus according to an embodiment of the present invention includes a deep packet matching module for matching a GTP control plane packet and a GTP user plane packet by controlling the GTP correlation module, and a GTP deep packet matching method using the same can extract deep-level packet information at the switch level to match the flow of GTP control plane packets and GTP user plane packets.

In addition, the network packet intermediary device according to an embodiment of the present invention converts a virtual LAN and at the same time efficiently performs interconnection between virtual L2 / L3 slices using a MAC loopback channel that is not used inside a hardware switch. By managing, it is possible to handle multiple virtual networks, independent of a limited number of physical loopback ports, and without complicated cable management.

1 is a block diagram of a network packet mediation system according to an embodiment of the present invention;
2 is a block diagram of a network packet intermediary apparatus according to another embodiment of the present invention;
3 is a block diagram of a network packet mediation system according to another embodiment of the present invention;
4 is a block diagram of a network packet mediation system according to another embodiment of the present invention;
5 is an embodiment of a block configuration of an SDN controller of a network packet intermediary apparatus;
6 is an embodiment of a block configuration of a switch of a network packet intermediary apparatus;
7 is an operation table showing a field table of a flow entry and an operation type according to the flow entry;
8 is a field table of group and meter tables;
9 is a block diagram of a network system including a routing system according to an embodiment of the present invention;
10 is a block diagram of a legacy routing container according to an embodiment of the present invention;
11 is a virtualized block diagram of the network system of FIG. 9;
12 is a flowchart for a method of determining whether legacy routing for a flow of an SDN controller;
13 is a signal flow diagram according to an integrated routing method according to an embodiment of the present invention;
14 is a signal flow diagram according to an integrated routing method according to another embodiment of the present invention;
15 is a flow table according to an embodiment of the present invention;
16 shows a network application module according to an embodiment of the present invention;
17 is a block diagram of a control unit of a network packet intermediary apparatus according to an embodiment of the present invention;
18 shows an embodiment of a method for time stamping a packet according to an embodiment of the present invention;
19 shows an embodiment of a method for assigning a time stamp according to a packet structure according to an embodiment of the present invention;
20 illustrates an embodiment of a method for assigning a time stamp according to a packet structure according to an embodiment of the present invention;
21 shows an example in which a network packet intermediary apparatus is connected to a wireless cellular network architecture according to an embodiment of the present invention;
22 schematically shows an access procedure of a user terminal in a mobile communication network according to an embodiment of the present invention;
23 shows the structure of a network packet intermediary apparatus according to an embodiment of the present invention;
24 shows an embodiment of a storage unit of a GTP correlation module according to an embodiment of the present invention;
25 is a diagram illustrating a method of obtaining a packet output port of a GTP-C packet matching a GTP-U packet according to an embodiment of the present invention;
26 shows a method of obtaining a packet output port of a GTP-C packet matching a GTP-U packet according to another embodiment of the present invention;
27 is a diagram illustrating a structure in which a deep packet matching module of a network packet intermediary apparatus processes a packet according to an embodiment of the present invention;
28 shows a deep packet matching method of a network packet intermediary apparatus according to an embodiment of the present invention;
29 shows an incoming packet parsing step according to an embodiment of the present invention;
30 shows an incoming pipeline stage of a deep packet matching module according to an embodiment of the present invention;
31 shows an outgoing packet parsing step according to an embodiment of the present invention;
32 shows a virtual slice topology of a network packet broker according to an embodiment of the present invention;
33 is a diagram illustrating a network configuration for each slide of a virtual slice topology of a network packet broker according to an embodiment of the present invention;
34 is a diagram showing the conversion of virtual LAN connections for each slide in the virtual slice topology of the network packet broker according to an embodiment of the present invention;
FIG. 35 is a diagram illustrating a virtual slice topology of a network packet broker according to an embodiment of the present invention in which a virtual LAN is converted and connected.

Hereinafter, the present invention will be described in more detail with reference to the drawings.

The terms first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

When a component is referred to as being “connected” or “connected” to another component, it is understood that the other component may be directly connected or connected to the other component, but other components may exist in between. it should be On the other hand, when it is mentioned that a certain element is "directly connected" or "directly connected" to another element, it should be understood that the other element does not exist in the middle. Also, when the first component and the second component on the network are connected or connected, it means that data can be exchanged between the first component and the second component by wire or wirelessly.

In addition, the suffixes "module" and "part" for the components used in the following description are given simply considering the ease of writing the present specification, and do not give a particularly important meaning or role per se. Accordingly, the terms “module” and “unit” may be used interchangeably.

When these components are implemented in an actual application, two or more components may be combined into one component, or one component may be subdivided into two or more components as needed. The same reference numerals are assigned to the same or similar components throughout the drawings, and detailed descriptions of the components having the same reference numerals may be omitted instead of being replaced with the descriptions of the above-described components.

Referring to Figure 1, a network packet brokerage system according to an embodiment of the present invention (Network Packer Broker System) is a plurality of remote wireless equipment (RRH, 2) for transmitting and receiving data of a wireless terminal; RAN (Radio Access Network) equipment 3, which transmits and receives data of a radio terminal, and a MAC address is assigned to a frame; a plurality of optical line terminals (OLT, 4); and a mobile communication core network 5; It may include a network packet broker (Network Packer Broker, 6) connected to the mobile communication core network (5).

Referring to FIG. 2 , the network packet intermediary device 6 according to an embodiment of the present invention is connected to the remote radio equipment by Ethernet, the RAN equipment and Ethernet, or the optical line terminal and a passive optical communication network (PON); A plurality of openflow (openflow) edge switches 20 connected by a Passive Optical Network; a Software Defined Network (SDN) controller 10 for acquiring information on the plurality of openflow edge switches; A network application module 40 that performs various functions on a network through the SDN controller when calling; and a switch group including at least some switches among the plurality of switches is treated as a virtual router, and any one switch in the switch group It may include a; legacy router container 300 for generating routing information for the incoming packet. A plurality of network devices connected to the plurality of openflow switches 20 in which the legacy routing container 300 generates legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router may be mapped to external network information directly connected to the virtual router.

The SDN controller 10 is a kind of command computer for controlling the SDN system, and may perform various and complex functions, for example, routing, policy declaration, and security check. The SDN controller 10 may define a flow of packets generated in a plurality of switches 20 of a lower layer. The SDN controller 10 may calculate a path (data path) through which the flow will pass by referring to the network topology for a flow permitted by the network policy, and then set the entry of the flow to a switch on the path. The SDN controller 10 may communicate with the switch 20 using a specific protocol, for example, the OpenFlow protocol. A communication channel between the SDN controller 10 and the switch 20 may be encrypted by SSL. The SDN controller 10 may be physically included in the network packet mediation device 6 or may be connected to the network packet mediation device 6 as an external device.

As a virtualized network function, there is a Network Function Virtualization (NFV) defined in the NFV-related white paper published by ETSI (European Telecommunications Standards Institute). In this specification, network function (NF) may be used interchangeably with network function virtualization (NFV). NFV provides necessary network functions by dynamically creating necessary L4-7 service connections for each tenant, or in case of DDoS attacks, necessary firewall, IPS, and DPI functions are quickly provided through a series of service chaining based on policy. can be In addition, NFV can be easily turned on and off firewall or IDS/IPS, and can be provisioned automatically. NFV can also reduce the need for over-provisioning.

Referring to FIG. 3 , a network device 2 , 3 , 4 , or not shown is a physical or virtual device connected to the switch 20 , and a user terminal device for exchanging data or information or performing a specific function. it could be From a hardware point of view, the network device 30 may be a PC, a client terminal, a server, a workstation, a supercomputer, a mobile communication terminal, a smart phone, a smart pad, or the like. Also, the network device 30 may be a virtual machine (VM) created on a physical device.

A network device may be referred to as a network function that performs various functions on a network. Network functions include anti-DDoS, intrusion detection/blocking (IDS/IPS), integrated security service, virtual private network service, anti-virus, anti-spam, security service, access management service, firewall, load balancing, QoS, video optimization, etc. may include. These network functions can be virtualized.

Referring to FIG. 4 , the SDN controller 10 according to an embodiment of the present invention maps remote radio equipment (RRH, 2) of the connected radio access network to external network information directly connected to the virtual router. It may further include a network control module 150 . The SDN controller 10 according to an embodiment of the present invention is a distributed radio network control module 160 that maps a digital unit (DU) of the connected radio access network to external network information directly connected to the virtual router. ) may be further included. The SDN controller 10 according to an embodiment of the present invention includes a virtual wired network control module 170 that maps an optical line terminal (OLT) of the connected wired access network to external network information directly connected to the virtual router. ) may be further included.

Referring to FIG. 5 , the SDN controller 10 according to an embodiment of the present invention includes a switch communication unit 110 communicating with the switch 20 in FIG. 2 , a control unit 100 , and a storage unit 190 . can do.

Referring to FIG. 5 , the control unit 100 of the SDN controller includes a topology management module 120 , a path calculation module 125 , an entry management module 135 , a message management module 130 , a legacy interface module 145 and an API. It may further include an interface module 146 . Each module may be configured as hardware in the control unit 100 , or may be configured as software separate from the control unit 100 . Reference is made to FIG. 2 for a description of the components with the same reference numerals.

5, the control unit 100 of the SDN controller 10 according to an embodiment of the present invention, for synchronizing the time of the packet with the timestamp value of the network device, a time synchronization module 410; a policy manager module 420 that controls QoS (Quality of Service); and a deep packet matching module 430 for extracting, modifying, removing or inserting a GTP header or a VxLAN header of a flow packet.

The storage unit 190 may store a program for processing and control of the control unit 100 . The storage unit 190 may perform a function for temporarily storing input or output data (packets, messages, etc.). The storage unit 190 may include an entry database (DB) 191 that stores flow entries.

The control unit 100 may control the overall operation of the SDN controller 10 by generally controlling the operation of each unit. The control unit 100 may include a topology management module 120 , a path calculation module 125 , an entry management module 135 , an API server module 136 and an API parser module 137 , and a message management module 130 . have. Each module may be configured as hardware in the control unit 100 , or may be configured as software separate from the control unit 100 .

The topology management module 120 may build and manage network topology information based on the connection relationship of the switch 20 collected through the switch communication unit 110 . The network topology information may include a topology between switches and a topology of a network device connected to each switch.

The path calculation module 125 may obtain a data path of a packet received through the switch communication unit 110 and an action sequence to be executed by a switch on the data path based on the network topology information built in the topology management module 120 . .

The entry management module 135 registers in the entry DB 191 as entries such as a flow table, a group table, and a meter table based on the results calculated by the path calculation module 125, policies such as QoS, and user instructions. can The entry management module 135 may allow an entry of each table to be registered in the switch 20 in advance (proactive), or may respond to a request to add or update an entry from the switch 20 (reactive). The entry management module 135 may change or delete an entry in the entry DB 191 as necessary or by an entry destruction message of the switch 10 .

The API parser module 137 may interpret a procedure for changing information of a mapped network device.

The message management module 130 may interpret a message received through the switch communication unit 110 or generate an SDN controller-switch message to be described later transmitted to the switch through the switch communication unit 110 . The state change message, which is one of the SDN controller-switch messages, may be generated based on an entry according to the entry management module 135 or an entry stored in the entry DB 191 .

When the switch group includes an OpenFlow switch and an existing legacy switch, the topology management module 120 may obtain connection information with the legacy switch through the OpenFlow switch.

The legacy interface module 145 may communicate with the legacy routing container 300 . The legacy interface module 145 may transmit topology information of the switch group built by the topology management module 120 to the legacy routing container 300 . The topology information may include, for example, connection relationship information of the first to fifth switches SW1-SW5 and connection or connection information of a plurality of network devices connected to the first to fifth switches SW1-SW5. can

When the message management module 130 cannot create a processing rule for a flow included in the flow inquiry message received from the OpenFlow switch, the corresponding flow can be transmitted to the legacy routing container 300 through the legacy interface module 145. have. The corresponding flow may include a packet received from the OpenFlow switch and port information of the switch receiving the packet. When the flow processing rule cannot be generated, there may be a case in which a received packet is configured with a legacy protocol and cannot be interpreted, and a case in which the path calculation module 125 cannot calculate a path for the legacy packet.

The switch 20 may be a physical switch or a virtual switch supporting the OpenFlow protocol. The switch 20 may process the received packet to relay the flow between the network devices 30 . To this end, the switch 20 may include one flow table or multiple flow tables for pipeline processing.

The flow table may include a flow entry defining a rule of how to process a flow of a network device (2, 3, 4 or not shown).

A flow may mean a packet flow of a specific path according to a series of packets sharing a value of at least one header field from the viewpoint of one switch or a combination of several flow entries of multiple switches. The OpenFlow network can perform path control, fault recovery, load balancing and optimization on a per flow basis.

The switch 20 may be divided into an ingress and egress switch of a flow according to a combination of multiple switches and a core switch between the edge switches.

Referring to FIG. 6 , the switch 20 includes a port unit 205 that communicates with other switches and/or network devices, an SDN controller communication unit 210 that communicates with the SDN controller 10, a switch control unit 200, and storage part 290 may be included.

The port unit 205 may include a plurality of a pair of ports flowing in and out from a switch or a network device. A pair of ports may be implemented as one port.

The storage unit 290 may store a program for processing and controlling the switch control unit 200 . The storage unit 290 may perform a function for temporarily storing input or output data (packets, messages, etc.). The storage unit 290 may include a table 291 such as a flow table, a group table, and a meter table. Table 291 or entries in the table may be added, modified, or deleted by the SDN controller 10 . Table entries can be destroyed on their own.

The switch control unit 200 may control the overall operation of the switch 20 by generally controlling the operation of each unit. The controller 210 may include a table management module 240 for managing the table 291 , a flow search module 220 , a flow processing module 230 , and a packet processing module 235 . Each module may be configured as hardware in the control unit 200 , or may be configured as software separate from the control unit 200 .

The table management module 240 may add an entry received from the SDN controller 10 through the SDN controller communication unit 210 to an appropriate table, or periodically remove a time-out entry.

The flow search module 220 may extract flow information from a packet received as user traffic. The flow information includes identification information of an ingress port that is a packet ingress port of the edge switch, identification information of a packet ingress port of the corresponding switch, packet header information (the IP address of the sender and destination, MAC address, port, and VLAN information), and metadata. The metadata may be selectively added from a previous table or data added from another switch. The flow search module 220 may search whether there is a flow entry for the received packet in the table 291 with reference to the extracted flow information. When a flow entry is searched for, the flow search module 220 may request the flow processing module 260 to process a received packet according to the searched flow entry. If the flow entry search fails, the flow search module 220 may transmit the received packet or minimum data of the received packet to the SDN controller 100 through the SDN controller communication unit 210 .

The flow processing module 230 may process an action such as outputting a packet to a specific port or multiple ports, dropping a packet, or modifying a specific header field according to the procedure described in the entry found in the flow search module 220. have.

The flow processing module 230 may process the pipeline process of a flow entry, execute an instruction to change an action, or execute an action set when it can no longer go to the next table in multiple flow tables.

The packet processing module 235 may actually output the packet processed by the flow processing module 230 to one or two or more ports of the port unit 205 designated by the flow processing module 230 .

Although not shown, the network packet intermediary apparatus 6 may further include an orchestrator for creating, changing, and deleting virtual network devices, virtual switches, and the like. When the orchestrator creates a virtual network device, the network device such as identification information of a switch to which the virtual network will connect, port identification information connected to the switch, MAC address, IP address, tenant identification information, and network identification information of information may be provided to the SDN controller 10 .

The SDN controller 10 and the switch 20 exchange various information, which is called an openflow protocol message. The OpenFlow message includes types such as an SDN controller-to-switch message, an asynchronous message, and a symmetric message. Each message may have a transaction identifier (transaction id; xid) in the header that identifies the entry.

The SDN controller-switch message is a message generated by the SDN controller 10 and delivered to the switch 20 , and is mainly used to manage or check the state of the switch 20 . The SDN controller-switch message may be generated by the control unit 100 of the SDN controller 10 , in particular the message management module 130 .

The SDN controller-switch message is a function for querying the capabilities of the switch (features), a configuration for querying and setting settings such as configuration parameters of the switch 20, flow / group / of the openflow table A modify state message for adding/deleting/modifying meter entries, and a packet-out message for transmitting a packet received from a switch through a packet-in message to a specific port on the corresponding switch etc. State change messages include a modify flow table message, a modify flow entry message, a modify group entry message, a port modification message, and a meter entry change. message (meter modification message), and the like.

The asynchronous message is a message generated by the switch 20 and is used to update the state change and network events of the switch in the SDN controller 10 . The asynchronous message may be generated by the control unit 200 of the switch 20 , in particular, the flow search module 220 .

*Asynchronous messages include packet-in messages, flow-removed messages, and error messages. The packet-in message is used by the switch 20 to transmit a packet to the SDN controller 10 to receive control of the packet. In the packet-in message, when the switch 20 receives an unknown packet, all or part of a received packet or a copy thereof transmitted from the OpenFlow switch 20 to the SDN controller 10 to request a data path. message that contains Packet-in messages are also used when the action of the entry associated with the incoming packet is to be sent to the SDN controller. The deleted flow (flow-removed) message is used to deliver flow entry information to be deleted from the flow tab to the SDN controller 10 . This message occurs in the flow expiry process due to the SDN controller 10 requesting the switch 20 to delete the corresponding flow entry or due to a flow timeout.

The symmetric message is generated by both the SDN controller 10 and the switch 20, and is transmitted without a request from the other party. Hello, which is used when initiating a connection between the SDN controller and the switch, echo to confirm that there is no problem in the connection between the SDN controller and the switch, and is used by the SDN controller or switch to inform the other side of the problem. may include an error message for Error messages are mostly used by switches to indicate failures with requests initiated by the SDN controller.

The packet parsing module 250 may interpret the header of the packet to extract one or more pieces of information about the packet.

The flow table may consist of multiple flow tables to process the pipeline of OpenFlow. Referring to FIG. 8 , the flow entry of the flow table includes match fields describing a condition (matching rule) that matches a packet, a priority, and a counter that is updated when there is a matching packet. Instruction, which is a set of various actions that occur when there is a packet matching the flow entry, timeouts describing the time to be discarded at the switch, and opaque type selected by the SDN controller. SDN It may be used by the controller to filter flow statistics, flow changes, and flow deletions, and may include tuples such as cookies that are not used in packet processing. An instruction may change pipeline processing, such as forwarding a packet to another flow table. Also, the instruction may include a set of actions for adding an action to an action set, or a list of actions to be applied directly to a packet. An action refers to an operation of modifying a packet, such as transmitting a packet to a specific port or decreasing the TTL field. An action may belong to a part of an instruction set associated with a flow entry or an action bucket associated with a group entry. An action set means a set in which actions indicated in each table are accumulated. An action set can be executed when there is no matching table. 8 illustrates the processing of several packets by flow entry.

A pipeline refers to a series of packet processing processes between a packet and a flow table. When a packet is introduced into the switch 20, the switch 20 searches for a flow entry matching the packet in the order of priority of the first flow table. When matching, the instruction of the corresponding entry is executed. Instruction is a command to be executed immediately upon matching (apply-action), a command to delete or add/modify the contents of an action set (clear-action; write-action), a command to modify metadata (write-metadata), and a specified Examples include goto-tables that move packets along with metadata into a table. If there is no flow entry matching the packet, the packet may be dropped according to table settings or the packet may be sent to the SDN controller 10 in a packet-in message.

The group table may contain group entries. The group table may be indicated by a flow entry to suggest additional forwarding methods. Referring to FIG. 8A , the group entry of the group table may include the following fields. A group identifier that can distinguish a group entry, a group type that specifies a rule for whether to perform some or all of the action buckets defined in the group entry, a counter of the flow entry It may include counters for statistics, and action buckets, which is a set of actions associated with parameters defined for a group.

A meter table is made up of meter entries and defines per-flow meters. Per flow meter-per-flow allows OpenFlow to apply various QoS operations. A meter is a kind of switch element that can measure and control the rate of packets. Referring to FIG. 8( b ), the meter table includes a meter identifier for identifying a meter, meter bands indicating a rate specified in a band and a packet operation method, and a packet It consists of counter fields that are updated when the meter is operated. The meter bands are the band type indicating how the packet is being processed, the rate used by the meter to select the meter band, and counters that are updated as packets are processed by the meter band. ), and fields such as type specific argument, which are bad types having an optional argument.

The switch control unit 200 may control the overall operation of the switch 20 by generally controlling the operation of each unit. The controller 200 may include a table management module 240 for managing the table 291 , a flow search module 220 , a flow processing module 230 , and a packet processing module 235 . Each module may be configured as hardware in the control unit 200 , or may be configured as software separate from the control unit 200 .

The table management module 240 may add an entry received from the SDN controller 10 through the SDN controller communication unit 210 to an appropriate table, or periodically remove a time-out entry.

The flow search module 220 may extract flow information from a packet received as user traffic. The flow information includes identification information of an ingress port, which is a packet ingress port of the edge switch, identification information of an incoming port of the corresponding switch, and packet header information (IP addresses, MAC addresses, ports, and VLAN information), and metadata. The metadata may be selectively added from a previous table or data added from another switch. The flow search module 220 may search whether there is a flow entry for the received packet in the table 291 with reference to the extracted flow information. When a flow entry is searched for, the flow search module 220 may request the flow processing module 260 to process a received packet according to the searched flow entry. If the flow entry search fails, the flow search module 220 may transmit the received packet or minimum data of the received packet to the SDN controller 100 through the SDN controller communication unit 210 .

The flow processing module 230 may process an action such as outputting a packet to a specific port or multiple ports, dropping a packet, or modifying a specific header field according to the procedure described in the entry found in the flow search module 220. have.

The flow processing module 230 may process the pipeline process of a flow entry, execute an instruction to change an action, or execute an action set when it can no longer go to the next table in multiple flow tables.

The packet processing module 235 may actually output the packet processed by the flow processing module 230 to one or two or more ports of the port unit 205 designated by the flow processing module 230 .

Although not shown, the SDN network system may further include an orchestrator for creating, changing, and deleting virtual network devices, virtual switches, and the like. When the orchestrator creates a virtual network device, the network device such as identification information of a switch to which the virtual network will connect, port identification information connected to the switch, MAC address, IP address, tenant identification information, and network identification information of information may be provided to the SDN controller 10 .

The SDN controller 10 and the switch 20 exchange various information, which is called an openflow protocol message. The OpenFlow message includes types such as an SDN controller-to-switch message, an asynchronous message, and a symmetric message. Each message may have a transaction identifier (transaction id; xid) in the header that identifies the entry.

The SDN controller-switch message is a message generated by the SDN controller 10 and delivered to the switch 20 , and is mainly used to manage or check the state of the switch 20 . The SDN controller-switch message may be generated by the control unit 100 of the SDN controller 10 , in particular the message management module 130 .

The SDN controller-switch message is a function for querying the capabilities of the switch (features), a configuration for querying and setting settings such as configuration parameters of the switch 20, flow / group / of the openflow table A modify state message for adding/deleting/modifying meter entries, and a packet-out message for transmitting a packet received from a switch through a packet-in message to a specific port on the corresponding switch etc. State change messages include a modify flow table message, a modify flow entry message, a modify group entry message, a prot modification message, and a meter entry change. message (meter modification message), and the like.

The asynchronous message is a message generated by the switch 20 and is used to update the state change and network events of the switch in the SDN controller 10 . The asynchronous message may be generated by the control unit 200 of the switch 20 , in particular, the flow search module 220 .

*Asynchronous messages include packet-in messages, flow-removed messages, and error messages. The packet-in message is used by the switch 20 to transmit a packet to the SDN controller 10 to receive control of the packet. In the packet-in message, when the switch 20 receives an unknown packet, all or part of a received packet or a copy thereof transmitted from the OpenFlow switch 20 to the SDN controller 10 to request a data path. message that contains Packet-in messages are also used when the action of the entry associated with the incoming packet is to be sent to the SDN controller. The deleted flow (flow-removed) message is used to deliver flow entry information to be deleted from the flow tab to the SDN controller 10 . This message occurs in the flow expiry process due to the SDN controller 10 requesting the switch 20 to delete the corresponding flow entry or due to a flow timeout.

The symmetric message is generated by both the SDN controller 10 and the switch 20, and is transmitted without a request from the other party. Hello, which is used when initiating a connection between the SDN controller and the switch, echo to confirm that there is no problem in the connection between the SDN controller and the switch, and is used by the SDN controller or switch to inform the other side of the problem. may include an error message for Error messages are mostly used by switches to indicate failures with requests initiated by the SDN controller.

The group table may contain group entries. The group table may be indicated by a flow entry to suggest additional forwarding methods. Referring to FIG. 8A , the group entry of the group table may include the following fields. A group identifier that can distinguish a group entry, a group type that specifies a rule for whether to perform some or all of the action buckets defined in the group entry, a counter of the flow entry It may include counters for statistics, and action buckets, which is a set of actions associated with parameters defined for a group.

A meter table is made up of meter entries and defines per-flow meters. Per flow meter-per-flow allows OpenFlow to apply various QoS operations. A meter is a kind of switch element that can measure and control the rate of packets. Referring to FIG. 8( b ), the meter table includes a meter identifier for identifying a meter, meter bands indicating a rate specified in a band and a packet operation method, and a packet It consists of counter fields that are updated when the meter is operated. The meter bands are the band type indicating how the packet is being processed, the rate used by the meter to select the meter band, and counters that are updated as packets are processed by the meter band. ), and fields such as type specific argument, which are bad types having an optional argument.

Referring to FIG. 9 , the network packet intermediary apparatus 6 according to an embodiment of the present invention is, for example, a switch group including first to fifth switches SW1-SW5 and 20, an SDN controller 10 . , and a legacy routing container 300 . Among the first to fifth switches SW1-SW5, the first and third switches SW1 and SW3 that are edge switches connected to an external network are OpenFlow switches supporting the OpenFlow protocol. The OpenFlow switch may be in the form of physical hardware, virtualized software, or a mixture of hardware and software.

In this embodiment, the first switch SW1 is an edge switch connected to the first legacy router R1 through the eleventh port (port 11), and the third switch SW3 is the third and third ports (port 32). , an edge switch connected to the second and third legacy routers R2 and R3 through port 33). The switch group may further include a plurality of network devices (2, 3, 4 or not shown) connected to the first to fifth switches.

Referring to FIG. 10 , the legacy routing container 300 may include an SDN interface module 345 , a virtual router creation unit 320 , a virtual router 340 , a routing processing unit 330 , and a routing table 335 . have.

The SDN interface module 345 may communicate with the controller 10 . Each of the legacy interface module 145 and the SDN interface module 345 may serve as an interface between the controller 10 and the legacy routing container 300 . The legacy interface module 145 and the SDN interface module 345 may communicate in a specific protocol or in a specific language. The legacy interface module 145 and the SDN interface module 345 may translate or interpret messages exchanged between the controller 10 and the legacy routing container 300 .

The virtual router generator 320 may create and manage the virtual router 340 using the topology information of the switch group received through the SDN interface module 345 . Through the virtual router 340 , a switch group may be treated as a legacy router in an external legacy network, that is, the first to third routers R1-R3.

The virtual router creation unit 320 may enable the virtual router 340 to have ports for virtual routers corresponding to edge ports of the edge switches of the switch group, that is, the first and third edge switches SW1 and SW3. For example, as in the case of Fig. 11(a), the ports of the v-R0 virtual legacy router are the 11th port (port 11) of the first switch (SW1), and the 32 and 33 ports of the third switch (SW3) (port 32, port 33) information can be used as it is.

A port of the virtual router 340 may be associated with identification information of a packet. The identification information of the packet may be tag information such as vLAN information of the packet or a tunnel ID added to the packet when it is accessed through a mobile communication network. In this case, multiple virtual router ports can be created with one real port of the OpenFlow edge switch. The virtual router port associated with the identification information of the packet may contribute to allowing the virtual router 340 to operate as a plurality of virtual legacy routers. If a virtual router is created with only the physical ports (real ports) of the edge switch, the number of physical ports is limited. However, when associating with packet identification information, this restriction is removed. In addition, it can be made to operate similarly to the flow of existing packets in a legacy network. In addition, a virtual legacy router can be run for each user or user group. A user or group of users can be identified by packet identification information such as vLAN or tunnel ID. Referring to FIG. 11( b ), the switch group is virtualized with a plurality of virtual legacy routers (v-R1, v-R2), and each port (vp 11) of the plurality of virtual legacy routers (v-R1, v-R2) ~13, vp 21~23) may be respectively associated with identification information of the packet.

Referring to FIG. 11B , the connection between the plurality of virtual legacy routers v-R1 and v-R2 and the legacy router is a plurality of sub-interfaces in which one real interface of the first legacy router R 1 is separated. It may be connected or may be connected to a plurality of real interfaces like the second and third legacy routers R2 and R3.

The virtual router generating unit 320 is configured to connect a plurality of network devices connected to the first to fifth switches SW1 to SW5 in which the first to third routers R1 to R3 are connected to an external network (vN) connected to the virtual router 340 . ) can be treated as This allows the legacy network to access the network devices of the OpenFlow switch group. In the case of FIG. 7A , the virtual router creation unit 320 creates a 0th port (port 0) in the 0th virtual legacy router v-R0. In the case of FIG. 7(b), the virtual router creation unit 320 has created 10th and 20th ports vp 10 and vp 20 in the first and second virtual legacy routers v-R1 and v-R2. . Each of the created ports (port 0, vp 10, vp 20) may have information such as a plurality of network devices of a switch group connected. The external network vN may consist of all or a part of a plurality of network devices.

Information on ports for virtual routers (port 0, por 11v, port 32v, port 33v, vp 10-13, vp 20-23) may have port information of the legacy router. For example, port information for a virtual router includes the MAC address, IP address, port name, connected network address range, legacy router information of the port for each virtual router, and may further include vLAN range, tunnel ID range, etc. Such port information may inherit edge port information of the first and third edge switches SW1 and SW3 as described above, or may be designated by the virtual router creation unit 320 .

The data plane of the network of FIG. 9 by the virtual router 340 created in the virtual router 340 may be virtualized as shown in FIG. 11(a) or 11(b). For example, in the case of FIG. 11( a ), in the virtualized network, the first to fifth switches SW1 to SW5 are virtualized as a virtual legacy router v-R0, and the virtualized network of the 0th virtual legacy router v-R0. The 11v, 32v, and 33v ports (port 11v, 32v, 33v) are connected to the first to third legacy routers R1 to R3, and port 0 of the 0 virtual legacy router v- R0 ( port 0) may be connected to an external network vN that is at least a part of a plurality of network devices.

The routing processing unit 330 may generate the routing table 335 when the virtual router 340 is created. The routing table 335 is a table used for reference for routing in the legacy router. The routing table 335 may be composed of some or all of the RIB, FIB, and ARP tables. The routing table 335 may be modified or updated by the routing processing unit 330 .

The routing processing unit 330 may generate a legacy routing path for the flow inquired by the controller 10 . The routing processing unit 330 performs legacy routing using some or all of the received packet received from the OpenFlow switch provided in the flow, port information into which the received packet was introduced, virtual router 340 information, and routing table 335 , etc. information can be generated.

The routing processing unit 330 may include a third-party routing protocol stack to determine legacy routing.

12 is a flowchart for a method of determining whether legacy routing for a flow of an SDN controller is performed.

The legacy routing method for the flow means whether the controller 10 should perform general SDN control on the flow received from the OpenFlow switch or inquire about the flow control to the legacy routing container 300 .

Referring to FIG. 12 , the controller 10 determines whether the flow inlet port is an edge port (S510). When the flow inlet port is not an edge port, the controller 10 may perform SDN-based flow control, such as calculating a path for a general openflow packet (S590).

When the flow inlet port is an edge port, the controller 10 determines whether a packet of the corresponding flow is interpretable (S520). If the packet cannot be interpreted, the controller 10 may transfer the flow to the legacy routing container 300 (S550). This is because, in the case of a protocol message used only in a legacy network, the SDN-based general controller cannot interpret the packet.

When the received packet is a legacy packet such as that transmitted from the first legacy network to the second legacy network, the SDN-based controller 10 cannot calculate a routing path of the introduced legacy packet. Therefore, when the controller 10 cannot calculate a path like a legacy packet, the controller 10 preferably sends the legacy packet to the legacy routing container 300 . However, if the edge port to which the legacy packet is to be leaked and the final processing method of the legacy packet are known, the controller 10 can process the legacy packet through flow modification. If it is possible to interpret the packet, the controller 10 searches for a flow path such as whether it can calculate the path of the corresponding flow or whether there is an entry in the entry table (S530). If the path cannot be searched, the controller 10 may transfer the corresponding flow to the legacy routing container 300 (S550). If the path can be searched, the controller 10 may generate a packet-out message designating the output of the packet and transmit the packet to the querying OpenFlow switch (S540). A detailed example of this will be described later.

13 shows a flow of processing a legacy protocol message in an SDN-based network to which the present invention is applied. 13 illustrates a case in which a hello message of an Open Shortest Path First (OSPF) protocol is received from the first edge switch SW1 as an example.

In this example, it is assumed that the OpenFlow switch group is virtualized by the SDN controller 10 and the legacy routing container 300 as shown in FIG. 11(a).

Referring to FIG. 13 , when the first legacy router R1 and the first edge switch SW1 are connected, the first legacy router R1 transmits the OSPF protocol hello message to the first edge switch SW1. can be (S410).

Since there is no flow entry for the received packet in the table 291 of the first edge switch SW1, the first edge switch SW1 sends a packet-in message indicating an unknown packet to the SDN controller 10. It transmits (S420). The packet-in message preferably includes a Hello1 packet and a flow including incoming port (port 11) information.

The message management module 130 of the SDN controller 10 may determine whether a processing rule for the corresponding flow can be generated (S430). For details on the determination method, refer to FIG. 15 . In this example, since the OSPF protocol message is a packet that the SDN controller 10 cannot interpret, the SDN controller 10 may transfer the corresponding flow to the legacy routing container 300 (S440).

The SDN interface module 345 of the legacy routing container 300 transmits the Hello1 packet received from the SDN controller 10 to the ingress port 11 of the first edge switch SW1 provided in the flow and the corresponding virtual router 340 ) to the port (port 11v). When the virtual router 340 receives the Hello1 packet, the routing processing unit 330 may generate legacy routing information of the Hello1 packet based on the routing table 335 ( S450 ). In this embodiment, the routing processing unit 330 generates a Hello2 message corresponding to the Hello1 message, and creates a routing path that designates an output port as the 11v port (port 11v) so that the Hello2 packet is transmitted to the first legacy router R1. can create The Hello2 message has a destination, which is the first legacy router R1, and a predefined virtual router identifier. The legacy routing information may include a Hell2 packet, and an output port that is an 11v port. Although it has been described that the Hello1 packet is received into the virtual router 340 in the present embodiment, the present invention is not limited thereto, and the routing processing unit 330 may generate legacy routing information using the information of the virtual router 340 .

The SDN interface module 345 may transfer the generated legacy routing information to the legacy interface module 145 of the SDN controller 10 (S460). Any one of the SDN interface module 345 and the legacy interface module 145 may convert an 11v port (port 11v), which is an output port, into an 11th port (port 11) of the first edge switch SW1. Alternatively, port conversion may be omitted by making the 11v port and the 11th port the same name.

The path calculation module 125 of the SDN controller 10 uses the legacy routing information received through the legacy interface module 145 to output the Hello2 packet to the 11th port (port 11) of the first legacy router R1. path can be set (S470).

The message management module 130 generates a packet-out message for outputting the Hello2 packet to the incoming port, port 11, using the set path and legacy routing information, and transmits it to the first legacy router R1. can be (S480).

In this embodiment, although it has been described as corresponding to the Helle message of the external legacy router, it is not limited thereto. For example, the legacy routing container 300 may generate an OSPF hello message to be actively outputted to an edge port of an edge switch and transmit it to the SDN controller 10 . In this case, the SDN controller 10 may transmit the hello packet to the OpenFlow switch as a packet-out message. In addition, this embodiment can be implemented by setting the OpenFlow switch to follow the instruction of the packet-out message even for a packet-out message that does not correspond to the packet-in message.

14 illustrates a case in which a general legacy packet is transmitted from the first edge switch SW1 to the third edge switch SW3.

The first edge switch SW1 starts by receiving the legacy packet P1 whose destination IP address does not belong to the OpenFlow switch group from the first legacy router R1 (S610).

Since there is no flow entry for the packet P1, the first edge switch SW1 may transmit the packet P1 to the SDN controller 10 and inquire about flow processing (packet-in message) (S620).

The message management module 130 of the SDN controller 10 may determine whether SDN control for the corresponding flow is possible (S630). In this example, packet P1 is interpretable but is destined for the legacy network, so the SDN controller 10 cannot create a path for packet P1. Accordingly, the SDN controller 10 may transmit the packet P1 and the 11th port, which is an incoming port, to the legacy routing container 300 through the path calculation module 125 ( S640 ).

The routing processing unit 330 of the legacy routing container 300 may generate legacy routing information based on the information of the virtual router 340 and the routing table 335 for the packet P1 received from the SDN controller 10 (S650). ). In this example, it is assumed that the packet P1 should be output to the 32v port (port 32v) of the virtual router. In this case, the legacy routing information includes an output port that is the 32v port (port 32v) for the packet P1, a destination MAC address that is the MAC address of the second legacy router R2, and a source MAC address that is the MAC address of the 32v port. It may include an address. This information is header information of a packet output from the legacy router. For example, when the first legacy router R1 sees the virtual legacy router v-R0 as the legacy router and transmits the packet P1, header information of the packet P1 is as follows. Since the source and destination IP addresses are the same as header information generated by the packet P1, they will be omitted from this description. The source MAC address of the packet P1 is the MAC address of the output port of the router R1. The destination MAC address of the packet P1 is the MAC address of the 11v port (port 11v) of the virtual legacy router (v-R0). In the case of an existing router, the packet P1' output to the 32v port (port 32v) of the virtual legacy router v-R0 may have the following header information. The source MAC address of the packet P1' is the MAC address of the 32v port (port 32v) of the virtual legacy router v-R0, and the destination MAC address becomes the MAC address of the ingress port of the second legacy router. That is, a part of header information of packet P1 is changed during legacy routing.

In order to correspond to the legacy routing, the routing processing unit 330 may generate a packet P1' obtained by adjusting the header information of the packet P1 and include it in the legacy routing information. In this case, it is necessary to process the incoming packet to the SDN controller 10 or the legacy routing container 300 every time for the same packet or a similar packet having the same destination address range. Therefore, the step of changing the packet to the format after the existing routing is performed in the edge switch (in this example, the third edge switch SW3) that outputs the packet to an external legacy network rather than the legacy routing container 300. it is preferable To this end, the legacy routing information described above may include source and destination MAC addresses. The SDN controller 10 may transmit a flow-Mod message for changing the header information of the packet P1' to the third edge switch by using this routing information.

The SDN interface module 345 may transfer the generated legacy routing information to the legacy interface module 145 of the SDN controller 10 (S660). In this step, the output port may be converted into an edge port mapped.

The path calculation module 125 of the SDN controller 10 outputs from the first edge switch SW1 to the 32 port of the third edge switch SW3 using the legacy routing information received through the legacy interface module 145 . It is possible to calculate the path to be possible (S670).

The message management module 130 transmits a packet-out message specifying an output port for the packet P1 to the first edge switch SW1 based on the calculated path (S680), and flows to the openflow switch of the corresponding path (S680). A flow-Mod change message may be transmitted (S690, S700). The message management module 130 may also transmit a flow-Mod message to the first edge switch SW1 to define processing for the same flow.

It is preferable that flow processing for the packet P1 is performed based on an identifier that can identify a legacy flow. To this end, the packet-out message transmitted to the first edge switch SW1 includes the packet P1 to which the legacy identifier (tunnel ID) is added, and the flow change message includes a flow entry that allows the legacy identifier (tunnel ID) to be added. can be included. Refer to FIG. 15 for an example of a flow table of each switch. 15A is a flow table of the first edge switch SW1. For example, in Table 0 of FIG. 15A , tunnel2 is added to the flow as a legacy identifier to the flow directed to the second legacy router R2 and the flow is moved to Table 1. Legacy identifiers can be written in metafields or other fields. Table 1 includes a flow entry that allows a flow having tunnel2 to be output to a 14th port (port information of the first switch SW1 connected to the fourth switch SW4). 15B is an example of a flow table of the fourth switch SW4. The table of FIG. 15( b ) allows a flow whose legacy identifier is tunnel2 among flow information to be output to a port 43 connected to the third switch SW3 . 15( c ) is an example of a flow table of the third switch SW3 . Table 0 of FIG. 15(c) removes the legacy identifier of the flow whose legacy identifier is tunnel2 and moves the flow to Table 1. Table 1 outputs the corresponding flow to the 32nd port. If multiple tables are used in this way, the number of cases can be reduced. This enables a quick search and can reduce resource consumption such as memory.

The first edge switch SW1 may add a legacy identifier (tunnel ID) to the packet P1 (S710) or transmit a packet to which the legacy identifier (tunnel ID) is added to the core network (S720). The core network refers to a network composed of the open flow switches SW2, SW4, and SW5 rather than the edge switches SW1 and SW3.

The core network may transmit the corresponding flow to the third edge switch SW3 (S730). The third edge switch SW3 may remove the legacy identifier and output the packet P1 to the designated port (S740). In this case, although not shown in the flow table of FIG. 15 , the flow table of the third switch SW3 preferably includes a flow entry for changing the destination and source MAC addresses of the packet P1.

The flow table may consist of multiple flow tables to process the pipeline of OpenFlow. Referring to FIG. 8 , the flow entry of the flow table includes match fields describing a condition (matching rule) that matches a packet, a priority, and a counter that is updated when there is a matching packet. Instruction, which is a set of various actions that occur when there is a packet matching the flow entry, timeouts describing the time to be discarded at the switch, and opaque type selected by the SDN controller. SDN It may be used by the controller to filter flow statistics, flow changes, and flow deletions, and may include tuples such as cookies that are not used in packet processing. An instruction may change pipeline processing, such as forwarding a packet to another flow table. Also, the instruction may include a set of actions for adding an action to an action set, or a list of actions to be applied directly to a packet. An action refers to an operation of modifying a packet, such as transmitting a packet to a specific port or decreasing the TTL field. An action may belong to a part of an instruction set associated with a flow entry or an action bucket associated with a group entry. An action set means a set in which actions indicated in each table are accumulated. An action set can be executed when there is no matching table. Fig. 15 illustrates various packet processing by flow entry.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include a time synchronization module 410 that synchronizes the time of the packet with the timestamp value of the network device.

The network packet mediation device 6 further includes a processor 801, the switch 20 further includes a processor 801, and the processor 801 of the network packet mediation device 6 returns a clock time value. The processor 801 of the switch 20 includes a register storing an elapsed time parameter from the reference time in the processor, and the time synchronization module 410 allows the switch 20 to send a request to time stamp the packet. When receiving, it may be to store the time stamp in the packet by correcting the overflow of the time parameter from the processor's register of the reference time switch.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include a policy manager module 420 for controlling Quality of Service (QoS). The policy manager module 420 may store and control a packet flow processing method according to packet information.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention further includes a deep packet matching module 430 for extracting, modifying, removing or inserting a GTP header or a VxLAN header of a flow packet. can do.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention interworks so that a GTP-C packet and a GTP-U packet of a flow packet can be delivered to the same outgoing port, a GTP correlation module 440 may be further included. The GTP correlation module 440 classifies the GTP-U traffic, and specifically identifies the GTP-U TEID as the Src IP of the GTP-U packet (eNodeB IP of uplink and SGW IP of downlink) to one IMSI. It could be mapping. In addition, the GTP correlation module 440 identifies the uplink GTP-U traffic with the eNB IP and S1-U SGW GTP-U interface tunnel ID of the packet, and identifies the uplink GTP-U traffic with the SGW IP with the S1-U eNodeB GTP-U interface tunnel ID. By identifying downlink traffic, both can be mapped to one IMSI.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include a network slicing module 470 that creates, changes, and processes one or more virtual networks.

The network slicing module 470 creates one or more legacy routing containers for any one of the switches or any one of the switch group, and allocates any one of the ports of the switch as a virtual port, Allocating a virtual LAN and allocating a converted virtual LAN may be performed.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include an API parser module 450 for interpreting a procedure for changing information of a mapped network device.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include an API server module 460 that performs an operation according to a procedure for changing information of a mapped network device. .

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include a network slicing module 470 that creates, changes, and processes one or more virtual networks.

Referring to FIG. 16 , the network application module 40 according to an embodiment of the present invention may further include a port manager module 480 for controlling the port 205 of the switch 20 .

The port manager module 480 may be configured to set the port 205 of the switch to ingress, egress, and transit states, and set ports as a single or a group.

Referring to FIG. 17 , the control unit 800 of the network packet intermediary device 6 according to an embodiment of the present invention includes a processor 801 , a memory 803 , a persistent storage device 805 , and a transceiver 802 . ), a bus system 804 and an I/O unit 806 . In accordance with this exemplary embodiment, processor 801 is a microprocessor, microcontroller, complex instruction set computing microprocessor, reduced instruction set computing microprocessor, very long instruction word microprocessor, explicit parallel instruction computing microprocessor, graphics It may be any type of physical computing circuitry or hardware, such as, but not limited to, a processor, digital signal processor, integrated circuit, application specific integrated circuit, or any other type of similar and/or suitable processing circuitry. Processor 801 may also include an embedded controller, such as a general purpose or programmable logic device or array, application specific integrated circuit, single chip computer, smart card, or the like.

The transceiver 802 supports communication with other systems or other entities in the cellular network. For example, transceiver 802 may include a network interface card or a wired/wireless transceiver that facilitates communication over a network. Communication unit 802 may support communication over any suitable physical or communication link.

The memory 803 may be a volatile memory or a non-volatile memory. Various computer-readable storage media can be stored in and accessed from memory elements of memory 803 . Memory elements include ROM, random access memory (RAM), erasable programmable read only memory (EPROM), electrically EPROM (EEPROM), hard drives, removable media drives for handling memory cards, memory sticks, and any may include any number of suitable memory devices for storing data and machine readable instructions, such as other similar and/or suitable types of memory storage devices and/or storage media.

Persistent storage 805 may include one or more components or devices that support long-term storage of data, such as read only memory (ROM), hard drives, flash memory, or optical disks. can

I/O unit 806 allows input and output of data. For example, I/O unit 806 may provide a connection for user input via a keyboard, mouse, keypad, touch screen, or other suitable input device. I/O unit 806 may also send output to a display, printer, or other suitable output device.

18 shows an embodiment of a method for time stamping a packet according to an embodiment of the present invention;

Referring to FIG. 18 , a method for giving a time stamp of a packet according to an embodiment of the present invention includes:

Step (S1010) the switch 20 acquires the clock of the processor 801 of the network packet intermediary device 6;

updating the reference time parameter Tb of the switch 20 with the acquired clock (S1020);

Step (S1030) of the switch 20 receiving a request to give a time stamp of the packet;

* The step of the time synchronization module 410 updating the previous elapsed time parameter Tp of the switch 20 to the current elapsed time parameter Tc (S1040);

Step (S1050) of the time synchronization module 410 acquiring the elapsed time value based on the parameter Tb from the switch 20 as the parameter Tc;

Comparing, by the time synchronization module 410, the magnitudes of the parameter Tc and the parameter Tp (S1060);

When the parameter Tc is smaller than the parameter Tp, the time synchronization module 410 adds and updates the parameter Tb by the sum of the parameter Tp and the correction value (S1070);

When the parameter Tc is greater than or equal to the parameter Tp, the time synchronization module 410 adds and updates the parameter Tb by the parameter Tp (S1080); and

The time synchronization module 410 may include a step ( S1090 ) of the switch 20 storing the parameter Tb in the packet as a time stamp.

In the method for assigning a time stamp to a packet according to an embodiment of the present invention, the method for assigning a time stamp to the packet may be to use an IEEE 1588 Precision Time Protocol (PTP) synchronization protocol.

In the method for giving a time stamp of a packet according to an embodiment of the present invention, the parameter Tp and the parameter Tc may be stored in a register of the processor 800 of the switch 20 .

In the method for giving a time stamp of a packet according to an embodiment of the present invention, the storage unit of the register may be less than 64 bits, and specifically, may be 48 bits or 32 bits.

In the method for assigning a time stamp to a packet according to an embodiment of the present invention, the time stamp storage unit of storing the packet as a time stamp ( S1090 ) may be 64 bits. Due to this, it is possible to give a time stamp in nanoseconds to a packet.

In the method for assigning a time stamp to a packet according to an embodiment of the present invention, the correction value in the updating step S1070 may be the maximum value of the storage unit of the register. For example, when the storage unit is 48 bits, it may be 2^48-1, that is, 281,474,976,710,655, and when the storage unit is 32 bits, it may be 2^32-1, that is, 4,294,967,294. The correction value enables the processor of the switch to provide a 64-bit time stamp in nanosecond units even if an overflow of the elapsed time parameter occurs when the register storage unit is generally smaller than 64 bits.

In the method for giving a time stamp of a packet according to an embodiment of the present invention, the parameter Tp and the parameter Tc may be stored in a register of the processor 800 of the switch 20 .

Referring to FIG. 19 , in the step of storing as a timestamp ( S1090 ), in the case of an ERSPAN type packet, the 33 th bit to 32 bits of the ERSPAN header are stored as the LSB 32 bit timestamp of the timestamp, Platform specific subheader It may be to store the 32 bits from the 33rd bit of the MSB as a 32-bit timestamp of the timestamp. Since this storage method is a standard used in the existing system, it has the advantage of good compatibility and does not require a separate modification in the packet analysis equipment.

Referring to FIG. 20 , in the step of storing as a timestamp ( S1090 ), in the case of an In-band Network Telemetry (INT) type packet, 32 bits from the first bit of the INT header are stored as an LSB 32-bit timestamp of the timestamp. and storing 32 bits from the 33rd bit as the LSB 32-bit timestamp of the timestamp. This storage method can reduce the overhead capacity during processing because the packet size is small in the packet analysis equipment.

Referring to FIG. 21 , the network packet intermediary device 6 according to an embodiment of the present invention may receive packets directly or through TAP (Test Application Protocol) in each connection step of the 4G LTE or 5G cellular network architecture. have. The wireless cellular network architecture includes a UE 801, an eNB 802, a Mobility Management Entity (MME, 803), a Serving Gateway (805), a Packet Data Network Gateway (PGW), and a Packet Data Network (PDN, 5). may include.

In a wireless cellular network architecture, the eNB 802 may communicate with the UE 801 via an X2 or Uu interface. In addition, the eNB 802 may communicate with the MME 803 through an S1AP control or S1-MME interface. The Uu interface may be used for NAS (mobility management, bearer control), radio resource control (RRC), and the like. Through the S1AP control interface, it may be used for delivery of an initial terminal context (UE context) when establishing an EPS bearer, subsequent mobility, paging, and release of the UE context.

The GTP-U interface can be used to carry user traffic on the S1-U, S5, and X2 interfaces. The GTP-C control interface may be used for transmission of control messages for creating, maintaining and deleting GTP tunnels.

The SGW 805 communicates with the PGW 806 through a GTP-U interface/GTP-C control interface, and the PGW 806 may communicate with the PDN 5 through an IP interface.

22 illustrates a call flow for supporting IP address assignment in a control plane and TEID assignment in a user plane in a wireless cellular network according to an embodiment of the present invention.

In step S2101, the UE 801 selects a cell through a Public Land Mobile Network (PLMN) and a cell search process to make an initial access request. Then, in order to synchronize the radio link with the selected cell, an RRC connection process with the base station 802 is performed. When the RRC connection setup is completed, the UE 801 transmits an RRC Connection Setup Complete message to the base station 802 . Thereafter, the UE 801 includes the Attach Request message in the RRC Connection Setup Complete message and transmits it to the eNodeB 802 in order to transmit an attachment request message (Attach Request message) to the MME 803 .

In step S2102 , the eNodeB 802 transmits a request for PDN connection to the MME 803 as part of the Attach procedure. The base station 802 transmits an Initial UE message including the cell ID and tracking area information of the cell to which the UE 801 is connected to the MME 803 for S1 signaling connection with the MME 803 . Here, the base station 802 transmits the Attach Request message received from the UE 101 to the MME 803 by including the Attach Request message in the Initial UE message. In this way, as the base station 802 transmits the Initial UE message to the MME 803, the S1 signaling connection between the base station 802 and the MME 803 is established.

In step S2103, the MME 803 sends a Create Session Request with the PGW-C IP address to the serving gateway control plane function (SGW-C) of the serving gateway 805 to create a Default Bearer. request. The Create Session Request may include the GTP-C TEID 901 of the MME 803 . The control plane function of the SGW 805 may be configured as an SGW of one of a plurality of serving gateway user plane functions (SGW-U) based on criteria such as, for example, the location of the UE, an optimal path for user data transmission. Select -U. The SGW-C allocates an IP address from a designated pool of SGW-U addresses. In some embodiments, this IP address may also be obtained by other means within the operator's network, ie based on operator defined policies or provisioning. When an IP address is assigned, the SGW-C 253 requests the Serving Gateway User Plane Function (SGW-U) to allocate a TEID by sending an Allocate Resource Request message. Upon receiving the resource allocation request from SGW-C, SGW-U sends PGW (SGW-U TEID for downlink transmission) and also eNB (SGW-U for uplink transmission) from local pools for GTP user plane and control plane. TEID) to assign a TEID. The SGW-U may also obtain this information based on the network operator's policy. The TEID allocated for uplink and downlink transmission is returned to the SGW-C in the Allocate Resource Ack.

In step S2104, the SGW-C sends a Create Session Request including the SGW-U IP address for downlink transmission, the SGW GTP-C TEID 902 and the SGW GTP-U TEID 902 to the SGW-U. It sends to the control plane function (PGW-C) of the PGW 806 along with the assigned IP address and the TEID for the GTP connection towards the PGW-U 256. The PGW-C assigns an IP address to the specified pool of PGW-U addresses. This address may also be obtained by other means of the operator's network, ie based on operator defined policies or provisioning. When the IP address is allocated, the PGW-C requests the PGW-U to allocate a TEID by sending an Allocate Resource Request message containing the SGW-U IP address and the SGW-U TEID for downlink transmission. Upon receiving the resource allocation request from the PGW-C, the PGW-U allocates a TEID from the local pool. The PGW-U may also obtain this information based on the network operator's policy. The allocated PGW-U TEID is returned to the PGW-C 255 in the Allocate Resource Ack message.

In step S2105, upon receiving a response from the PGW-U 256 together with the newly allocated TEID, the PGW-C 255 is an IP CAN (Internet Protocol connectivity access network) with a PCRF (Policy and Charging Rule Function). A Session Establishment/Modification procedure may be initiated.

In step S2106, the response is PGW-U TEID and also PGW-U IP in the Create Session Response message including PGW-U IP address, PGW GTP-C TEID 903 and PGW GTP-U TEID 903 It is sent to SGW-C with the address.

Then, in step S2107, the SGW-C 253 transfers the received PGW-U TEID and PGW-U IP address to the SGW-U 254 by sending a Modify Request message. The SGW-U 254 acknowledges the request. After receiving the response of the Modify Request, a Create Session Response message is sent to the MME 803 together with the SGW-U IP address, SGW GTP-C TEID 904 and SGW GTP-U TEID 904 .

Next, in step S2108 , the MME 803 transmits an Attach Accept message to the UE 801 via the eNB 802 . The Initial Context Setup message that piggybacks the Attach Accept message includes the SGW-U IP address and the SGW-U TEID. The base station 802 receiving the Initial Context Setup Request message from the MME 803 performs an AS Security Setup procedure for secure communication with the UE 801 in the radio section. Through the AS Security Setup procedure, the RRC message is integrity protected and encrypted, and user traffic of the UE 801 is also encrypted and transmitted.

Next, in step S2109, when the AS Security Setup procedure is completed, the base station 802 transmits an RRC Connection Reconfiguration message to the UE 801 for radio interval bearer establishment.

Then, in step S2110, the UE 801 receiving this completes the DRB bearer establishment. Accordingly, the uplink EPS bearer setup from the UE 801 to the P-GW 806 is completed, and the UE 801 transmits an RRC Connection Reconfiguration message to the base station 802 .

Next, in step S2111, when the AS Security Setup procedure and the DRB setup procedure are completed, the base station 802 allocates an S1 eNB TEID for the configuration of the downlink S1-MEC bearer. Then, it is included in the Initial Context Setup Response message and transmitted to the MME (803).

In step S2112, the UE 801 transmits the Attach Complete message to the base station 802 by including the Attach Complete message in the UL Information Transfer message to deliver the Attach Complete message to the MME 803.

Next, in step S2113 , the base station 802 receiving this includes the Attach Complete message in the UL NAS Transport message and delivers it to the MME 803 .

Next, in step S2114, the MME 803, upon receiving the S1 eNB GTP-U TEID 905 from the base station 802, includes it in a Modify Bearer Request message and transmits it to the SGW 804.

Next, in step S2115, the SGW 805 that has received this completes the downlink S1-MEC bearer configuration using the S1 eNB TEID, and sends a Modify Bearer Response message to the MME 805 in response to the Modify Bearer Request message. ) to (S522). Accordingly, both the uplink and downlink S1-MEC bearer configuration between the base station 102 and the edge server 103 is completed, and the uplink and downlink traffic transmission between the base station 802 and the SGW 805 is performed. allowed

Referring to FIG. 23 , the GTP correlation module 440 may include a GTP session tracking module 4401 , a GTP user plane forwarding module 4402 , and a storage unit 4403 .

GTP session tracking module 4401, MME 803, SGW 805, and various GTP-C transactions between PGW 806, for example, CreateSession Request (S2103, S2104), Create Session Response (S2106, S2107) , ModifyBearer Request (S2114), etc. can be snooped to grant and maintain user IMSI mapping for GTP-U and GTP-C TEIDs. Also, the GTP correlation module 440 may transmit a GTP-C message belonging to the same user (IMSI) to the same port unit 205 or port group as the GTP-U message.

The GTP session tracking module 4401 may parse the subscriber IMSI and subscriber session information from the information of the GTP control plane packet, and update the subscriber table 44031 and the GTP session table 44032, respectively.

The GTP session tracking module 4401 may redirect the outflow path of the TEID associated with the IMSI corresponding to the same user to the same outflow port unit 25 or port group.

The GTP user plane forwarding module 4402 transmits the GTP user plane (GTP-U) packets that have entered the ingress port unit 205 of the switch 20 from the GTP session table 44032 of the GTP correlation module 440 to the GTP-U. The outflow port information of the GTP session table 44032 may be updated by querying the TEID.

The GTP user plane forwarding module 4402 may search for the GTP TEID and IP address in the incoming packet and, in the case of a GTP-C packet, transmit it to the GTP session tracking module 4401 .

24 shows an embodiment of the storage unit of the GTP correlation module according to an embodiment of the present invention.

The storage unit 4403 of the GTP correlation module 440 may be located in the memory 803 of the control unit 800 of the network packet intermediary device 6 , more preferably, the processor 801 .

The storage unit 4403 of the GTP correlation module 440 may include an IMSI table 44031 , an MME context table 440321 , and an SGW context table 440322 .

The subscriber table 44031 of the storage unit 4403 of the GTP correlation module 440 may be an IMSI table 44031 .

The GTP session table 44032 of the storage unit 4403 of the GTP correlation module 440 may include an MME context table 440321 and an SGW context table 440322 .

The GTP session table 44032 of the storage unit 4403 of the GTP correlation module 440 stores the correlation between the IMSI table 44031, the MME context table 440321, and the SGW context table 440322. A correlation table ( 44035) may be further included.

The correlation table of the storage unit 4403 of the GTP correlation module 440 includes a first correlation table 440323 , a second correlation table 440324 , a third correlation table 440325 , and a fourth correlation table. (440326).

The IMSI table 44031 may include an IMSI, a packet output port, and a bearer ID set. The IMSI table 44031 may use the IMSI as a primary key. The bearer ID set may include an MME IP, a bearer ID, and a sequence.

GTP correlation module 440 in the MME context table 440321, with the MME IP address as the key, the bearer ID set including the MME IP, the bearer ID and the sequence, and the MME S11 TEID 901 as a value generating a record (S3010);

generating, by the GTP correlation module 440, a record using the SGW IP address as a key in the SGW context table 440322 (S3020);

The GTP correlation module 440 searches the SGW context table 440322 for a record having the SGW IP address as a key, and updates the SGW S11 TEIDs 902, 904 and the SGW S1U TEIDs 902 (S3030);

Generating, by the GTP correlation module 440, a record in the first correlation table 440323 with the MME S11 TEID as the key and the IMSI context and the SGW S11 TEID context 902, 904 as values (S3040);

generating, by the GTP correlation module 440, a record having the SGW S11 TEID 902, 904 as a key and the MME S11 context 901 as a value in the second correlation table 440324 (S3050);

generating, by the GTP correlation module 440, a record having the SGW S11 TEID as a key and the SGW S11 TEID contexts 902 and 904 as values in the third correlation table 440325 (S3060);

In the fourth correlation table 440326, the GTP correlation module 440 generates a record having the eNB TEID 905 and the eNB IP as the SGW S1U TEID context values 902 and 904 as keys (S3070) ;

The GTP correlation module 440 updates the bearer ID set and eNB S1U TEID 905 value including the MME IP, bearer ID and sequence of the record using the MME IP address as a key in the MME context table 440321. to (S3080); and

The GTP correlation module 440 generates a record in the IMSI table 44031 with the IMSI as the key and the bearer ID set including the MME IP, the bearer ID and the sequence as a value (S3090);

The MME context table 440321 may include an MME IP address, a bearer ID set, an MME S11 TEID, and an eNB S1U TEID. The MME context table 440321 may use the MMP IP address as a primary key. The MME context table 440321 may be connected to the first correlation table 440323 using the bearer ID set as a foreign key. The MME context table 440321 may be connected to the IMSI table 44031 using the MME S11 TEID as a foreign key. The MME context table 440321 may be connected to the fourth correlation table 440326 using the eNB S1U TEID as a foreign key.

The SGW context table 440322 may include an SGW IP address, an SGW S11 TEID, and an SGW S1U TEID. The SGW context table 440322 may use the SGW IP address as a primary key. The SGW context table 440322 may be connected to the second correlation table 440324 using the SGW S11 TEID as a foreign key. The SGW context table 440322 may be connected to the third correlation table 440325 using the SGW S1U TEID as a foreign key.

The first correlation table 440323 may include an MME S11 TEID, an IMSI context, and an SGW S11 TEID context. The first correlation table 440323 may use the MME S11 TEID as a primary key. The first correlation table 440323 and the IMSI table 44031 may be cross-referenced with the IMSI context of the first correlation table 440323 and the bearer ID set of the IMSI table 44031 .

The second correlation table 440324 may include the SGW S11 TEID and the MME S11 context. The second correlation table 440324 may use SGW S11 TEID as a primary key. The first correlation table 440323 and the second correlation table 440324 may be cross-referenced to the SGW S11 TEID context of the first correlation table 440323 and the MME S11 context of the second correlation table 440324. .

The third correlation table 440325 may include SGW S1U TEID and SGW S11 TEID contexts. The third correlation table 440325 may use SGW S1U TEID as a primary key. The second correlation table 440324 and the third correlation table 440325 may be cross-referenced as the MME S11 context of the second correlation table 440324 and the SGW S11 TEID context of the third correlation table 440325. .

The fourth correlation table 440326 may include an eNB TEID set and an SGW S1U TEID context. The fourth correlation table 440326 may use the eNB TEID set as a primary key. The eNB TEID set may include an eNB S1U TEID and an eNB IP. The third correlation table 440325 and the fourth correlation table 440326 may be cross-referenced as the SGW S1U TEID of the third correlation table 440325 and the SGW S1U TEID context of the fourth correlation table 440326. .

24 shows an embodiment of a storage unit of a GTP correlation module according to an embodiment of the present invention;

The storage unit 4403 of the GTP correlation module 440 may be located in the memory 803 of the control unit 800 of the network packet intermediary device 6 , more preferably, the processor 801 .

The storage unit 4403 of the GTP correlation module 440 may include an IMSI table 44031 , an MME context table 440321 , and an SGW context table 440322 .

The subscriber table 44031 of the storage unit 4403 of the GTP correlation module 440 may be an IMSI table 44031 .

The GTP session table 44032 of the storage unit 4403 of the GTP correlation module 440 may include an MME context table 440321 and an SGW context table 440322 .

The GTP session table 44032 of the storage unit 4403 of the GTP correlation module 440 stores the correlation between the IMSI table 44031, the MME context table 440321, and the SGW context table 440322. A correlation table ( 44035) may be further included.

The correlation table of the storage unit 4403 of the GTP correlation module 440 includes a first correlation table 440323 , a second correlation table 440324 , a third correlation table 440325 , and a fourth correlation table. (440326).

The IMSI table 44031 may include an IMSI, a packet output port, and a bearer ID set. The IMSI table 44031 may use the IMSI as a primary key. The bearer ID set may include an MME IP, a bearer ID, and a sequence.

GTP correlation module 440 in the MME context table 440321, with the MME IP address as the key, the bearer ID set including the MME IP, the bearer ID and the sequence, and the MME S11 TEID 901 as a value generating a record (S3010);

generating, by the GTP correlation module 440, a record using the SGW IP address as a key in the SGW context table 440322 (S3020);

The GTP correlation module 440 searches the SGW context table 440322 for a record having the SGW IP address as a key, and updates the SGW S11 TEIDs 902, 904 and the SGW S1U TEIDs 902 (S3030);

Generating, by the GTP correlation module 440, a record in the first correlation table 440323 with the MME S11 TEID as the key and the IMSI context and the SGW S11 TEID context 902, 904 as values (S3040);

generating, by the GTP correlation module 440, a record having the SGW S11 TEID 902, 904 as a key and the MME S11 context 901 as a value in the second correlation table 440324 (S3050);

generating, by the GTP correlation module 440, a record having the SGW S11 TEID as a key and the SGW S11 TEID contexts 902 and 904 as values in the third correlation table 440325 (S3060);

In the fourth correlation table 440326, the GTP correlation module 440 generates a record having the eNB TEID 905 and the eNB IP as the SGW S1U TEID context values 902 and 904 as keys (S3070) ;

The GTP correlation module 440 updates the bearer ID set and eNB S1U TEID 905 value including the MME IP, bearer ID and sequence of the record using the MME IP address as a key in the MME context table 440321. to (S3080); and

The GTP correlation module 440 generates a record in the IMSI table 44031 with the IMSI as the key and the bearer ID set including the MME IP, the bearer ID and the sequence as a value (S3090);

The MME context table 440321 may include an MME IP address, a bearer ID set, an MME S11 TEID, and an eNB S1U TEID. The MME context table 440321 may use the MMP IP address as a primary key. The MME context table 440321 may be connected to the first correlation table 440323 using the bearer ID set as a foreign key. The MME context table 440321 may be connected to the IMSI table 44031 using the MME S11 TEID as a foreign key. The MME context table 440321 may be connected to the fourth correlation table 440326 using the eNB S1U TEID as a foreign key.

The SGW context table 440322 may include an SGW IP address, an SGW S11 TEID, and an SGW S1U TEID. The SGW context table 440322 may use the SGW IP address as a primary key. The SGW context table 440322 may be connected to the second correlation table 440324 using the SGW S11 TEID as a foreign key. The SGW context table 440322 may be connected to the third correlation table 440325 using the SGW S1U TEID as a foreign key.

The first correlation table 440323 may include an MME S11 TEID, an IMSI context, and an SGW S11 TEID context. The first correlation table 440323 may use the MME S11 TEID as a primary key. The first correlation table 440323 and the IMSI table 44031 may be cross-referenced with the IMSI context of the first correlation table 440323 and the bearer ID set of the IMSI table 44031 .

The second correlation table 440324 may include the SGW S11 TEID and the MME S11 context. The second correlation table 440324 may use SGW S11 TEID as a primary key. The first correlation table 440323 and the second correlation table 440324 may be cross-referenced to the SGW S11 TEID context of the first correlation table 440323 and the MME S11 context of the second correlation table 440324. .

The third correlation table 440325 may include SGW S1U TEID and SGW S11 TEID contexts. The third correlation table 440325 may use SGW S1U TEID as a primary key. The second correlation table 440324 and the third correlation table 440325 may be cross-referenced as the MME S11 context of the second correlation table 440324 and the SGW S11 TEID context of the third correlation table 440325. .

The fourth correlation table 440326 may include an eNB TEID set and an SGW S1U TEID context. The fourth correlation table 440326 may use the eNB TEID set as a primary key. The eNB TEID set may include an eNB S1U TEID and an eNB IP. The third correlation table 440325 and the fourth correlation table 440326 may be cross-referenced as the SGW S1U TEID of the third correlation table 440325 and the SGW S1U TEID context of the fourth correlation table 440326. .

Referring to FIG. 26 , in the GTP-U packet, when the Src IP is the IP of the SGW 805 , the DST IP is the IP of the eNB 802 , and the TEID is the SGW GTP-U TEID, it matches the GTP-U packet The process of acquiring the packet output port of the GTP-C packet is as follows.

In the fourth correlation table 440326, after searching for a record using the IP of the eNB 802 as a key value, the SGW S1U TEID is obtained from the searched record.

Next, in the third correlation table 440325 , a record is retrieved using the acquired SGW S1U TEID as a key value, and then the SGW S11 TEID context is acquired from the retrieved record.

Next, in the second correlation table 440324 , a record is retrieved using the acquired SGW S11 TEID context as a key value, and then an MME S11 TEID context is acquired from the retrieved record.

Next, in the first correlation table 440323 , a record is retrieved using the acquired MME S11 TEID context as a key value, and then an IMSI context is acquired from the retrieved record.

Next, in the IMSI table 44031, a record is retrieved using the acquired IMSI context as a key value, and then a packet output port is acquired from the retrieved record.

The GTP correlation module 440 may include a GTP session tracking module 4401 , a GTP user plane forwarding module 4402 , and a storage 4403 .

The deep packet matching module 430 may control the GTP correlation module 440 to match the GTP control plane packet and the GTP user plane packet.

Referring to FIG. 27 , the storage unit 4403 of the GTP correlation module 440 may include a GTP control plane flow table 44034 and a GTP control plane correlation table 44035 .

GTP control plane flow table 44034 may store GTP-C TEID and egress port pairs.

The storage unit 4403 of the GTP correlation module 440 may be located in the processor 801 or the memory 803, preferably in a register of the processor 801, for quick query and response processing. .

The GTP control plane packet may be processed according to the processing action of the packet stored in the GTP Control plane-egress port Match Action Table 2911, and initially the packet is stored in the match action table 2911. Since no matching record exists, the deep packet matching module 430 may query the GTP control plane flow table 44034 for a flow to update the match action table 2911 . The GTP control plane packets processed in the match action table 2911 may be processed together in the GTP user plane-egress port Match Action Table 2912 .

The GTP control plane correlation table 44032 may be a GTP session table 44032 . Deep packets may be matched by updating outgoing port information corresponding to the corresponding GTP TEID in the GTP control plane correlation table 44032 in the GTP user plane outgoing port match action table 2912 .

If there is no flow matching the packet in the GTP user plane outflow port match action table 2912 or the action for the flow is deny, the corresponding packet may be dropped and not processed.

Referring to FIG. 28 , the deep packet matching method of the network packet intermediary apparatus according to an embodiment of the present invention may include the following steps:

Deep packet matching module 430 receiving a packet from the incoming port unit 205 of the switch 205 (S3010);

Incoming packet parsing step of extracting deep packet information from the packet received by the packet parsing module 250 of the switch 205 (S3020);

Incoming packet pipeline step (S3030) of processing the packet with the information obtained by the deep packet matching module 430;

distinguishing the type of packet from the packet information obtained by the deep packet matching module 430 (S3040);

When the type of the distinguished packet is a GTP control plane packet, the GTP session tracking module 4401 queries the GTP control plane outflow table 2911 for a flow matching the packet, and sends the packet to the outflow port unit 205 or outflow port GTP control plane packet processing step of obtaining a group (S3050); and

When the type of the distinguished packet is a GTP user plane packet, the GTP user plane forwarding module 4402 queries the GTP user plane outflow table 2912 for a flow matching the packet to process the packet (S3060) ).

The outgoing packet pipeline step (S3060) includes an outgoing packet parsing step (S3061) of extracting outgoing packet information and storing the flow information of the packet in the GTP user plane outflow table 2912; and querying the GTP user plane outflow table 2912 for flow information of the outgoing packet to process an action on the outgoing packet ( S3602 ).

The packet parsing module 250 according to an embodiment of the present invention includes an ethernet header, vlan header, ipv4 header, tcp header, udp header, icmp header, sctp header, gtp header, inner ether header, inner ipv4 header, inner tcp header and The inner udp header can be parsed.

Referring to FIG. 29 , the incoming packet parsing step ( S3020 ) of the deep packet matching method according to an embodiment of the present invention may include the following steps:

an incoming port parsing step in which the packet parsing module 250 extracts incoming port information from the incoming packet (S1101);

an Ethernet protocol parsing step in which the packet parsing module 250 extracts Ethernet protocol information from an incoming packet (S1102);

If the extracted Ethernet protocol information is VLAN, the packet parsing module 250 extracts VLAN information from the incoming packet (S1104);

If the extracted Ethernet protocol information is IPv4, an IPv4 parsing step (S1105) in which the packet parsing module 250 extracts IPv4 information from the incoming packet;

When the extracted IPv4 protocol type is TCP, the packet parsing module 250 extracts TCP information from the incoming packet (S1107);

If the extracted IPv4 protocol type is IMCP, the packet parsing module 250 extracts IMCP information from the incoming packet, IMCP parsing step (S1108);

When the extracted IPv4 protocol type is SCTP, the packet parsing module 250 extracts SCTP information from the incoming packet (S1109);

a UDP parsing step (S1110) in which the packet parsing module 250 extracts UDP protocol number information from the incoming packet;

when the extracted UDP protocol number is VxLAN, the packet parsing module 250 extracts VxLAN information from the incoming packet (S1112);

when the extracted UDP protocol number is GTP, the packet parsing module 250 extracts GTP information from the incoming packet (S1113);

an inner Ether parsing step in which the packet parsing module 250 extracts inner Ether information from the incoming packet (S1114);

an inner IPv4 parsing step in which the packet parsing module 250 extracts inner IPv4 information from the incoming packet (S1115); and

Inner TCP/UDP parsing step in which the packet parsing module 250 extracts inner TCP and inner UDP information from the incoming packet (S1116).

The parsing of the incoming port ( S1101 ) may further include transmitting the incoming port information to the incoming metadata of the packet ( S11011 ) and transmitting the device timestamp information to the incoming metadata ( S11012 ).

The IPv4 parsing step (S1105) may further include a step (S11051) of transferring src_ip, dst_ip, and protocol to a look-up table of incoming metadata.

The inner information extracted in the GTP parsing step (S1113), Inner Ether parsing step (S1114), Inner IPv4 parsing step (S1115), and Inner TCP/UDP parsing step (S1116) are all original destination address information of the packet, and the extracted original With the destination address information, it is possible to distribute traffic according to the type of internal traffic in the edge cloud, and it is possible to distribute the traffic load in a balanced way based on the original destination address instead of the pass-through address during load balancing.

Referring to Figure 30, the incoming pipeline step (S3030) of the deep packet matching method according to an embodiment of the present invention may include the following steps:

Incoming port mapping step (S1201) in which the deep packet matching module 430 converts the incoming physical port 205 into a logical port used in the Match Action table;

GTP filter application step (S1202) of the deep packet matching module 430 storing the processing of the packet corresponding to the GTP information extracted from the incoming packet in the outgoing port match action table 2922; and

If the deep packet matching module 430 has inner IPv4 information extracted from the incoming packet (S1203), the inner IPv4 filter is applied to store the processing of the packet corresponding to the extracted inner IPv4 information in the outgoing port match action table 2922 step S1203;

In the inner IPv4 filter application step (S1203), the deep packet matching module 430 duplicates the packet when the action of the GTP user plane outgoing port match action table 2911 according to the incoming packet is replication to the outgoing port unit 205 or Replication step of forwarding to the outflow port group (S12031); and

When the deep packet matching module 430 performs load balancing in the action of the GTP user plane outgoing port match action table 2912 according to the incoming packet, it may include a load balancing step (S12032) of delivering it to a designated outgoing port group.

The step of applying the GTP filter ( S1202 ) may be to store an action for the corresponding packet as deny, permit, replication, strip_vxlan_and_permit, or strip_vxlan_and_replication.

Inner IPv4 filter application step (S1203) may be to store the action for the corresponding packet as deny, permit, or replication.

In one embodiment of the present invention, the policy management module 420 may create, modify, or process a packet filter that controls the flow of the matched packet by matching information stored in the header of the packet.

In one embodiment of the present invention, the packet filter may be a source (source, src) IP matching filter, a destination (dst) IP matching filter, a TEID matching filter, and may be a GTP filter or an IPv4 filter.

In an embodiment of the present invention, the GTP filter may match GTP Outer packet information, and specifically, match eth_type, src_mac, dst_mac, src_ip, dst_ip, ip_proto, gtp_teid, gtp_metadata, l4_src_port, l4_group_label, or port of the packet. may be doing

In an embodiment of the present invention, the IPv4 filter may match GTP inner packet information, and specifically, may match src_mac, dst_mac, src_ip, dst_ip, ip_proto, l4_src_port, l4_dst_port or port_group_label of the packet.

Referring to FIG. 31 , the outgoing packet parsing step S3061 of the deep packet matching method according to an embodiment of the present invention may include the following steps:

Ingress port filter number parsing step of the deep packet matching module 430 extracting the incoming port filter number from the outgoing packet (S1301);

Incoming port filter matching step (S1302) in which the deep packet matching module 430 queries the policy manager module 420 for the incoming port filter number extracted from the outgoing packet;

If the matched incoming port filter number exists, extracting the matched incoming port action in the policy manager module 420 (S1303);

Deep packet matching module 430 GTP filter number parsing step of extracting the GTP filter number from the outgoing packet (S1304);

Deep packet matching module 430 GTP filter matching step of querying the policy manager module 420 for the GTP filter number extracted from the outgoing packet (S1305);

If the matched GTP filter number exists, extracting the matched GTP action in the policy manager module 420 (S1306);

Inner IPv4 parsing step in which the deep packet matching module 430 extracts Inner IPv4 information from the outgoing packet (S1307);

Inner IPv4 matching step (S1308) in which the deep packet matching module 430 queries the policy manager module 420 for inner IPv4 information extracted from the outgoing packet;

If the matched inner IPv4 information exists, extracting the matched inner IPv4 action from the policy manager module 420 (S1309); and

The deep packet matching module 430 stores the outgoing packet and all the extracted action list pairs in the GTP user plane outgoing port match action table 2912 action list generation step (S1310).

The present invention may be implemented in hardware or software. Implementation The present invention can also be implemented as computer-readable codes on a computer-readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data readable by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., and may also be implemented in the form of a carrier wave (eg, transmission through the Internet). include In addition, the computer-readable recording medium is distributed in a computer system connected through a network, so that the computer-readable code can be stored and executed in a distributed manner. And functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers in the technical field to which the present invention pertains.

Embodiments of the present invention may include a carrier wave having electronically readable control signals, which may be operated as a programmable computer system in which one of the methods described herein is executed. Embodiments of the present invention may be implemented as a computer program product having a program code, the program code being operative for executing one of the methods when the computer program is run on a computer. The program code may be stored on a machine readable carrier, for example. One embodiment of the present invention may be a computer program having program code for executing one of the methods described herein when the computer program is run on a computer. The invention may comprise a computer, or programmable logic device, for carrying out one of the methods described above. Programmable logic devices (eg, field programmable gate arrays, complementary metal oxide semiconductor based logic circuits) may be used to perform some or all of the functions of the methods described above.

In addition, although preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above, and the technical field to which the present invention belongs without departing from the gist of the present invention as claimed in the claims In addition, various modifications may be made by those of ordinary skill in the art, and these modifications should not be individually understood from the technical spirit or prospect of the present invention.

Claims (12)

A plurality of remote radio equipment (RRH; Remote Radio Head) for transmitting and receiving data of the radio terminal;
RAN (Radio Access Network) equipment that transmits and receives data of a wireless terminal, and a MAC address is assigned to a frame;
a plurality of optical line terminals (OLTs); and
mobile communication core network;
An open fronthaul network system including a network intermediary device connected to the mobile communication core network,
The network intermediary device is a plurality of openflow edge switches connected to the remote wireless equipment by Ethernet, connected to the RAN equipment by Ethernet, or connected to the optical line terminal and a passive optical network (PON) by a passive optical network (PON). ,
The plurality of openflow edge switches may include a software defined network (SDN) controller configured to acquire information on the plurality of openflow edge switches belonging to a switch group;
a legacy router container that treats a switch group including at least some of the plurality of switches as a virtual router, and generates routing information for a packet arriving at any one of the switch groups; and
The network application module is a network packet intermediary device including a network application module including modules that perform a function of controlling the operation and flow of packets according to a request through the controller,
The legacy routing container directs a plurality of network devices connected to the plurality of OpenFlow switches for generating legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router to the virtual router. It maps to the connected external network information,
The network application module includes a time synchronization module for synchronizing the time of the packet with the timestamp value of the network device,
The network packet relay device further includes a processor, the switch further includes a processor, the processor of the network packet relay device includes a clock for returning a time value, and the processor of the switch includes a time elapsed from a reference time in the processor. a register for storing a parameter, wherein the time synchronization module stores the time stamp in the packet by correcting the overflow of the time parameter from the register of the processor of the reference time switch when the switch receives a request for time stamping of the packet In, open fronthaul network system. According to claim 1,
The controller further comprises a virtual radio network control module for mapping a remote radio head (RRH) of the connected radio access network to information on an external network directly connected to the virtual router. According to claim 1,
The controller further comprises a virtual wired network control module for mapping an optical line terminal (OLT) of the connected wired access network to external network information directly connected to the virtual router. According to claim 1,
The controller further comprises a distributed radio network control module that maps a digital unit (DU) of the connected radio access network to external network information directly connected to the virtual router. A plurality of remote radio equipment (RRH; Remote Radio Head) for transmitting and receiving data of the radio terminal;
RAN (Radio Access Network) equipment that transmits and receives data of a wireless terminal, and a MAC address is assigned to a frame;
a plurality of optical line terminals (OLTs); and
mobile communication core network;
An open fronthaul network system including a network intermediary device connected to the mobile communication core network,
The network intermediary device is a plurality of openflow edge switches connected to the remote wireless equipment by Ethernet, connected to the RAN equipment by Ethernet, or connected to the optical line terminal and a passive optical network (PON) by a passive optical network (PON). ,
The plurality of openflow edge switches may include: a software defined network (SDN) controller configured to acquire information on the plurality of openflow edge switches belonging to a switch group;
a legacy router container that treats a switch group including at least some of the plurality of switches as a virtual router, and generates routing information for a packet arriving at any one of the switch groups; and
The network application module is a network packet intermediary device including a network application module including modules that perform a function of controlling the operation and flow of packets according to a request through the controller,
The legacy routing container directs a plurality of network devices connected to the plurality of OpenFlow switches for generating legacy routing information for a flow processing inquiry message of the controller based on the information of the at least one virtual router to the virtual router. It maps to the connected external network information,
The network application module includes a time synchronization module for synchronizing the time of the packet with the timestamp value of the network device,
The network packet relay device further includes a processor, the switch further includes a processor, the processor of the network packet relay device includes a clock for returning a time value, and the processor of the switch includes a time elapsed from a reference time in the processor. a register for storing a parameter, wherein the time synchronization module stores the time stamp in the packet by correcting the overflow of the time parameter from the register of the processor of the reference time switch when the switch receives a request for time stamping of the packet A method for giving packet timestamps in an open fronthaul network system. 6. The method of claim 5,
The method is
acquiring, by the switch, a clock of the processor of the network packet intermediary device;
updating the reference time parameter Tb of the switch with the obtained clock;
receiving, by the switch, a time stamp request of the packet;
updating, by the time synchronization module, the previous elapsed time parameter Tp of the switch to the current elapsed time parameter Tc;
acquiring, by the time synchronization module, an elapsed time value based on the parameter Tb from the switch as a parameter Tc;
comparing, by the time synchronization module, magnitudes of the parameter Tc and the parameter Tp;
updating, by the time synchronization module, when the parameter Tc is smaller than the parameter Tp by adding the parameter Tb by the sum of the parameter Tp and the correction value;
updating, by the time synchronization module, adding the parameter Tb by the parameter Tp when the parameter Tc is greater than or equal to the parameter Tp; and
A method for assigning time stamps to packets in an open fronthaul network system, comprising: by the time synchronization module, the switch storing the parameter Tb in the packet as a time stamp. 7. The method of claim 6,
The method is to use IEEE 1588 PTP (Precision Time Protocol) synchronization protocol, packet time stamping method in an open fronthaul network system. 7. The method of claim 6,
wherein the parameter Tp and the parameter Tc are stored in a register of a processor of the switch. 7. The method of claim 6,
The storage unit of the register is 48 bits, the packet time stamping method of the open fronthaul network system. 7. The method of claim 6,
In the step of storing the time stamp in the packet, the time stamp storage unit is 64 bits. 9. The method of claim 8,
and the correction value of the updating step is the maximum value of the storage unit of the register. 10. The method of claim 9,
The correction value of the updating step is 4,294,967,294, packet time stamping method of an open fronthaul network system.

Images