Control unit, control method and program

Abstract

To lighten the load of check sum calculation in processing packets.SOLUTION: A PGW 320 encapsulates received packets P with a header for mobile (for example, an IP header, an UDP header, and a GTP header) when transmitting the received packets P to an SGW 33 on a downlink side. When calculating a check sum of UDP, a PGW 34 is enabled to lighten the load of a calculation amount as compared with before by reusing checksum information put in the TCP header of the received packets without reading in the whole packets of a part corresponding to a segment of the UDP.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a control device, a control method, and a program. [Background technology]

[0002] The Evolved Packet System (EPS) includes not only 3GPP (3rd Generation Partnership Project (registered trademark)) access networks but also non-3GPP access networks. Non-3GPP access networks are Internet Protocol (IP) access networks that use access technologies with specifications outside the scope of 3GPP, and include wireless local area networks (WLANs) such as Wi-Fi (registered trademark) and WiMAX (Worldwide Interoperability for Microwave Access) (see, for example, Patent Document 1).

[0003] In Release 8, 3GPP specified EPS100 as the fourth-generation mobile architecture, which consists of a terminal (User Equipment: UE) 110 such as a smartphone, a communication carrier's base station (evolved NodeB: eNB) 120, and an evolved packet core network (Evolved Packet Core: EPC) 130, as shown in Figure 1.

[0004] The UE 110 is connectable to a packet data network (PDN) 140 such as an Internet Multimedia Subsystem (IMS) or the Internet via the eNB 120 and the EPC 130.

[0005] The MME (Mobility Management Entity) 131 of the EPC 130 performs various processes, such as mobility management and authentication of the UE 110 and setting up a packet forwarding path. The MME 131 also performs user authentication and other processes in cooperation with a Home Subscriber Server (HSS), not shown. The MME 131 sets up and releases a packet forwarding path between a Serving Gateway (SGW) 132 of the EPC 130 and the eNB 120. The SGW 132 transmits and receives packets to and from the eNB 120, for example, and sets up and releases a communication path between the SGW 132 and a Packet Data Network Gateway (PGW) 133, while the PGW 133 connects to the PDN 140. The illustrated EPC 130 is based on the architecture specified in Release 8 of LTE, but the CUPS (Control and User Plane Separation) architecture specified in Release 15 may also be adopted for the EPC 130 (see, for example, TS 23.214). In this case, SGW132 can be separated into an SGW-C having C-Plane functions and an SGW-U having U-Plane functions, and PGW133 can be separated into a PGW-C having C-Plane functions and a PGW-U having U-Plane functions. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Special Publication No. 2014-511585 Summary of the Invention [Problem to be solved by the invention]

[0007] FIG. 2 is a diagram for explaining problems with packet processing in the conventional PGW 133, and shows the structure of a packet that the PGW 133 receives from the PDN 140 and the packet that the PGW 133 transmits the received packet to the SGW 132 on the downlink side.

[0008] As shown in FIG. 2, a packet received by the PGW 133 from the PDN 140 is composed of a header section Ph and a payload section Pp. The header section Ph includes an Ethernet header (ETH), an IP header (IP), and a TCP header (TCP). When transmitting the received packet to the SGW 132 on the downlink side, the PGW 134 encapsulates (encaps) the received packet with a mobile header (in FIG. 2, an IP header (IP), a UDP header (UDP), and a GTP header (GTP)). At this time, the PGW 133 needs to calculate the UDP checksum. However, to calculate the UDP checksum, the PGW 133 needs to read the entire packet corresponding to the UDP segment (see the range A1 indicated by the arrow in FIG. 2), which causes problems such as a heavy calculation load.

[0009] The present invention has been made in consideration of the above-described circumstances, and has as its object to provide a technique that can reduce the load of checksum calculation when processing packets. [Means for solving the problem]

[0010] A control device according to one aspect of the present invention is a control device that transmits received packets, and is characterized by comprising: a receiving unit that receives the received packets from an external device; a first derivation unit that calculates a checksum of the received packet using the Layer 4 header if the received packet includes a Layer 4 header; a creation unit that creates a header for a mobile network; a second derivation unit that calculates a checksum element to be added to the checksum of the received packet based on information included in the created header for the mobile network; a checksum processing unit that adds the checksum element to the checksum of the received packet; an encapsulation processing unit that stores the checksum of the received packet after addition in a predetermined field of the header for the mobile network and encapsulates the header for the mobile network into the received packet; and a transmitting unit that transmits the encapsulated received packet. [Effects of the Invention]

[0011] According to the present invention, it is possible to reduce the load of checksum calculation when processing packets. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 illustrates a fourth-generation mobile architecture. [Figure 2] 10A and 10B are diagrams for explaining problems with packet processing in a conventional PGW 34. [Figure 3] 1 is a diagram illustrating an overview of an LTE network configuration according to an embodiment of the present invention. [Figure 4] FIG. 1 is a diagram illustrating an example of a main hardware configuration of an SGW. [Figure 5] FIG. 1 is a diagram illustrating an example of a main functional block configuration of an SGW. [Figure 6] 10 is a flowchart illustrating a packet processing operation by a PGW. [Figure 7] FIG. 1 is a diagram illustrating an overview of a 5G network configuration according to a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0013] An embodiment of the present invention will be described below. In the following description of the drawings, identical or similar parts are denoted by identical or similar reference numerals. However, the drawings are schematic. Therefore, specific dimensions and the like should be determined in light of the following description. Furthermore, it goes without saying that the dimensional relationships and ratios of parts included in the drawings differ from one another. Furthermore, the technical scope of the present invention should not be interpreted as being limited to the embodiment.

[0014] A. This embodiment 3 is a diagram showing an outline of the configuration of an LTE network (i.e., EPS) 1000 according to this embodiment. In this embodiment, a network configuration of LTE (Long Term Evolution) defined by 3GPP (3rd Generation Partnership Project) is illustrated as an example, but it is also applicable to network configurations such as 5G (described later).

[0015] The EPS 1000 mainly includes a UE 100, an eNB 200, and an EPC 300. The EPC 300 includes an SGW 310, a PGW 320, and the like.

[0016] As explained in the section on the related art, when the PGW 320 transmits a received packet (received packet) to the SGW 310 on the downlink side, it encapsulates (encaps) the received packet with a header for mobile use (for example, an IP header, a UDP header, and a GTP header). At this time, the PGW 320 needs to calculate the UDP checksum, but to calculate the UDP checksum, it needs to read the entire packet (see range A1 in Figure 2 above) that corresponds to the UDP segment, which causes problems such as a heavy calculation load.

[0017] In contrast to this, in this embodiment, by reusing the checksum information contained in the TCP header of the received packet, it is possible to reduce the calculation load compared to the conventional method (details will be described later). Note that although the main protocols in Layer 4 of the OSI reference model include TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), the following explanation will be given using TCP as an example.

[0018] The UE 100 is capable of connecting to a PDN 400 such as the Internet via the eNB 200 and the EPC 300 . The SGW 310 transmits and receives packets to and from the eNB 200, for example, and sets up and releases a communication path to and from the PGW 320. The PGW 320 connects to the PDN 400 and the SGW 310. When the PGW 320 receives a packet sent from the PDN 400, it encapsulates the received packet with a header for mobile use (specifically, an IP header (IP), a UDP header (UDP), and a GTP header (GTP)), and transmits the downlink packet to the SGW 310.

[0019] The UE 100 and the eNB 200 transmit and receive RRC messages in the Radio Resource Control (RRC) layer, and proceed with session processing (also referred to as a connection sequence). As the session processing proceeds, the UE 100 changes from an idle state (RRC Idle) to a connected state (RRC Connected) to the eNB 200. The idle state corresponds to the standby state of the UE 100.

[0020] Furthermore, the UE 100 and the eNB 200 transmit and receive MAC Control Elements (MAC CEs) in the Medium Access Control (MAC) layer. RRC messages are transmitted as RRC Protocol Data Units (PDUs), and the logical channels to which they are mapped include a Common Control Channel (CCCH), a Dedicated Control Channel (DCCH), a Paging Control Channel (PCCH), a Broadcast Control Channel (BCCH), or a Multicast Control Channel (MCCH). MAC CEs are transmitted as MAC PDUs (or MAC subPDUs). A MAC subPDU is equivalent to a Service Data Unit (SDU) in the MAC layer plus, for example, an 8-bit header, and the MAC PDU includes one or more MAC subPDUs.

[0021] <Hardware configuration> 4 is a diagram showing an example of the main hardware configuration of the PGW 320, which is characteristic of the present invention. The PGW 320 includes a processor 320a, a memory 320b, a storage device 320c, and a communication device 320d for wired or wireless communication.

[0022] The processor 320a is, for example, a central processing unit (CPU) or a graphics processing unit (GPU), and performs overall control of the entire device.

[0023] The memory 320b is configured by, for example, a read only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), and / or a random access memory (RAM).

[0024] The storage device 320c is configured by storage such as a hard disk drive (HDD), a solid state drive (SSD), and / or an embedded multi media card (eMMC).

[0025] The communication device 320d is a device that performs communication via a wired and / or wireless network, such as a network card, a communication module, etc. The communication device 320d may also include an amplifier, an RF (Radio Frequency) device that performs processing related to wireless signals, and a BB (Base Band) device that performs baseband signal processing.

[0026] In addition to these hardware components, the PGW 320 may also have an input device that accepts input operations, an output device that outputs information, etc. The input device may be, for example, a keyboard, a touch panel, a mouse, and / or a microphone, and the output device may be, for example, a display and / or a speaker.

[0027] <Function block configuration> 5 is a diagram showing an example of a configuration of main functional blocks of the PGW (control device, computer) 320. The PGW 320 includes a receiving unit 31, a determining unit 32, a deriving unit 33, a creating unit 34, a checksum processing unit 35, an encapsulation processing unit 36, and a transmitting unit 37. The determining unit 32, the derivation unit 33, the creating unit 34, the checksum processing unit 35, and the encapsulation processing unit 36 ​​may be realized by the processor 320a executing a program stored in the storage device 320c. The receiving unit 31 and the transmitting unit 37 may be realized by the communication device 320d, or may be realized by the processor 320a in addition to the communication device 320d executing a program stored in the storage device 320c.

[0028] The receiving unit 31 receives packets (received packets) transmitted from a PDN 400 such as the Internet. The determination unit 32 determines what protocol is higher than the IP protocol of the received packet (specifically, TCP or UDP). The determination unit 32 determines the higher protocol by checking the protocol number included in the IP header. Note that the determination unit 32 may also determine the IP protocol version (e.g., IPv4 or IPv6) by checking version information included in the IP header of the received packet.

[0029] The lead-out portion 33 includes a first lead-out portion 33a and a second lead-out portion 33b. The first derivation unit 33a calculates the checksum of the received packet (details will be described later). The second derivation unit 33b calculates a checksum element to be added to the checksum of the received packet based on the information contained in the created header for the mobile network (details will be described later).

[0030] The creation unit 34 creates headers for the mobile network (specifically, an IP header, a UDP header, and a GTP header). The checksum processing unit 35 adds the checksum element calculated by the second derivation unit 33b to the checksum of the received packet.

[0031] The encapsulation processing unit 36 ​​stores the checksum of the received packet after the addition in a predetermined field of the header for the mobile network, and encapsulates the received packet by adding a header for the mobile network.

[0032] The transmitter 37 transmits the encapsulated received packet to the UE 100. The following describes the characteristic packet processing operation of the PGW 310 with reference to the drawings.

[0033] FIG. 6 is a flowchart illustrating a packet processing operation by the PGW 320. In step S1, the receiving unit 31 receives a packet (a received packet) sent from the PDN 400 and directed to the UE 100.

[0034] In step S2, the determination unit 32 checks the protocol number included in the IP header of the received packet to determine the protocol (layer 4) above the IP protocol (layer 3). More specifically, the determination unit 32 checks the IP protocol number of the received packet to determine whether the received packet includes a header of a higher-level protocol, i.e., an "L4 header" (such as a TCP header or a UDP header). The received packet includes packets of various communication methods, such as IPv4 and IPv6.

[0035] If the decision unit 32 determines that the received packet includes an "L4 header" (step S2: YES), the process proceeds to step S3, whereas if it determines that the received packet does not include an "L4 header", the process proceeds to step S4.

[0036] In step S3, the first derivation unit (extraction unit) 33a extracts checksum information that indicates the checksum of the entire received packet, which is stored in the checksum field of the L4 header.

[0037] In step S4, the first derivation unit 33a determines whether the value of the checksum information is "0." If the received packet does not include an "L4 header" (step S2: NO), the value of the checksum information is "0" (step S4: YES), and the process proceeds to step S5, where a normal checksum calculation is performed.

[0038] On the other hand, if the received packet includes an "L4 header," the first derivation unit (deletion unit) 33a creates a pseudo header based on the header of the received packet (step S6). Specifically, the first derivation unit 33 creates the pseudo header by using information (e.g., IP address) included in the TCP header and IP header of the received packet. The structure of the pseudo header is defined in, for example, RFC9293 (For IPv4) or RFC8200 (For IPv6).

[0039] In step S7, the first derivation unit (deletion unit) 33a deletes unnecessary checksum elements from the checksum information by adding the complement of the checksum calculated from the created pseudo header to the checksum information.

[0040] In step S8, the first derivation unit (addition unit) 33a calculates the checksum element of the IP header of the received packet and adds it to the checksum information. The details of such a checksum difference calculation method are disclosed in, for example, RFC1624.

[0041] In step S9, the creation unit 34 creates a header for the mobile network (here, an IP header, a GTP header, and a UDP header required to add the GTP header) based on the bearer setting.

[0042] Next, the second derivation unit 33b performs a necessary checksum calculation from the created header information for the mobile network. Specifically, the second derivation unit 33b creates a pseudo header from information included in the IP header and UDP header that configure the header for the mobile network (step S10), calculates the checksum using the pseudo header to obtain checksum element 1, and adds checksum element 1 to the checksum information (step S11).

[0043] Furthermore, the second derivation unit 33b calculates checksums using the GTP header and UDP header that constitute the header for the mobile network, respectively, to obtain checksum elements 2 and 3, and adds these to the checksum information (step S12). Note that the checksum using the UDP header can be calculated using the same method as that used in TCP (see, for example, RFC768).

[0044] The second derivation unit 33b determines whether the checksum information obtained as described above falls within a 16-bit range (step S13). If the checksum does not fall within the 16-bit range (step S13: NO), the second derivation unit 33b performs calculations to make it fall within the 16-bit range (step S14), but if the checksum falls within the 16-bit range (step S13: YES), the second derivation unit 33b proceeds to step S15.

[0045] In step S15, the encapsulation processing unit 36 ​​stores checksum information in the checksum field of the UDP header, and then encapsulates the received packet with a header for the mobile network (i.e., IP header, UDP header, GTP header) (step S16).

[0046] The transmitter 37 transmits the encapsulated received packet to the UE 100, and ends the process. The packet transmitted from the PGW 320 is received by the UE 10 via the SGW 310, the eNB 200, and the like.

[0047] As described above, according to this embodiment, by deriving the checksum element in the header portion of the mobile network and adding it to the checksum information contained in the TCP header of the received packet, it is possible to reduce (optimize) the amount of calculation related to the checksum.

[0048] B. Variation 1: Pre-calculating checksums Figure 6 illustrates an example of a processing flow in which a checksum is calculated when PGW320 receives a packet sent from the PDN to the UE, i.e., when the U-Plane packet is transmitted. However, the checksum may also be calculated before the U-Plane packet is transmitted.

[0049] Mobile communication networks beyond LTE adopt the Always-ON concept, in which a bearer is configured and an IP address is assigned to a terminal as soon as the terminal is powered on. Therefore, the bearer configuration at the time of power-on is used unless the bearer is released due to being out of service area or the terminal being powered off. As explained in S9 of FIG. 6, the header for the mobile network is created based on the bearer configuration. Therefore, the PGW 320 can create the header for the mobile network in advance. After that, the PGW 320 can calculate the checksum in advance by calculating checksum elements 1 to 3 based on the generated header for the mobile network, as explained in S10 to S12 of FIG. 6.

[0050] The header for the mobile network can be generated at any timing between the attachment of the terminal and the transmission of the U-Plane packet, but the earliest timing at which it can be generated is when the terminal is attached when it is powered on, that is, when the PGW 320 receives a Create Session Request (CSR). In this case, the C-Plane function may generate the header for the mobile network.

[0051] In this way, the checksum can be calculated before sending or receiving a U-Plane packet, thereby reducing the calculation load on the U-Plane function of the PGW 320.

[0052] In the current 3GPP standard, the Sxb interface, which is the communication interface between the PGW-C and PGW-U, does not support the transmission of checksums. Therefore, in order to transfer the checksum calculated in the PGW-C to the PGW-U, a separate transmission means can be secured by extending the 3GPP standard specifications, for example.

[0053] Here, the PGW 320 can create a header for a mobile network if it has bearer information. Therefore, generation of a header for a mobile network is not limited to being performed by the C-Plane function. Specifically, generation of a header for a mobile network may be performed by the U-Plane function. In this way, by having the U-Plane function generate a header for a mobile network, the process of transmitting a checksum calculated by the C-Plane function to the U-Plane function becomes unnecessary, and it becomes possible to reduce the load on the PGW 320.

[0054] C. Variation 2: Application to 5G networks In the above-described embodiment, the network configuration of LTE (Long Term Evolution) has been described as an example, but the present invention can also be applied to a 5G network configuration. Fig. 7 is a diagram showing an outline of a 5G network configuration according to a modified example.

[0055] 5G-compatible base stations (Next-Generation Node B: gNB) are connected to the 5G core network (5GC). The User Plane Function (UPF) provides the U-plane functionality for transmitting and receiving user data in the SGW 310 and PGW 320 shown in Figure 3, while the Session Management Function (SMF) provides the C-plane functionality for session management in the SGW and PGW. Other functions include the Authentication Server Function (AUSF), which is an authentication server; the Unified Data Management (UDM), which stores related information; and the Access and Mobility Management Function (AMF: subscriber), which manages terminal locations, but these are omitted from Figure 7.

[0056] Even in such a network configuration, when processing downlink packets, the UPF (control device, computer) performs packet processing similar to that of the PGW in this embodiment (i.e., encapsulating with a mobile network header, etc.), thereby making it possible to reduce (optimize) the amount of calculation related to the checksum in the packet processing.

[0057] D.Other In the above-described embodiment and modification, a case has been described in which a PGW (LTE) or a UPF (5G) encapsulates a received packet in a mobile network header including GTP, assuming an LTE or 5G core network, but the present invention is not limited to this. For example, the present invention can be applied to devices other than a PGW (LTE) or a UPF (5G) that constitute a mobile network.

[0058] As an example, the present invention can be applied to base stations (control devices, computers) such as eNBs (LTE) and gNBs (5G) when they process uplink packets. For example, an eNB may encapsulate a packet (received packet) sent from a UE with a mobile network header including GTP and transmit it to an SGW using an S1-U interface. On the other hand, a gNB may encapsulate a packet (received packet) sent from a UE with a mobile network header including GTP and transmit it to a UPF using an NG-U interface. In this way, the present invention can be applied to base stations such as eNBs (LTE) and gNBs (5G) when they process uplink packets. [Explanation of symbols]

[0059] 1000...EPS, 100...UE, 200...eNB, 300...EPC, 310...SGW, 320...PGW, 400...PDN, 320a...processor, 320b...memory, 320c...storage device, 320d...communication device, 31...receiving unit, 32...determining unit, 33...derivation unit, 33a...first derivation unit, 33b...second derivation unit, 34...creation unit, 35...checksum processing unit, 36...encapsulation processing unit, 37...transmitting unit

Claims

1. A control device for transmitting a received packet, a receiving unit that receives the received packet from an external device; a first derivation unit that calculates a checksum of the received packet using a Layer 4 header when the received packet includes the Layer 4 header; a generator for generating a header for a mobile network; a second derivation unit that calculates a checksum element to be added to the checksum of the received packet based on information included in the created mobile network header; a checksum processor that adds the checksum element to a checksum of the received packet; an encapsulation processing unit that stores the checksum of the received packet after the addition in a predetermined field of the header for the mobile network and encapsulates the header for the mobile network in the received packet; a transmitter for transmitting the encapsulated received packet; A control device comprising:

2. The first lead-out portion is an extractor for extracting checksum information from the Layer 4 header; a deletion unit that creates a pseudo-header based on the header of the received packet and deletes unnecessary checksum elements from the checksum information using the pseudo-header; an adding unit that calculates a checksum element of an IP header included in the received packet, and adds the checksum element of the IP header to the received packet after deleting the unnecessary checksum element; The control device of claim 1 , comprising:

3. The control device according to claim 2 , wherein the deletion unit deletes unnecessary checksum information from the checksum information by adding a complement calculated from the pseudo header to the checksum information.

4. the header for the mobile network includes an IP header, a GTP header, and a UDP header or a TCP header required to attach the GTP header; The encapsulation processing unit The control device according to claim 1 , wherein the checksum of the received packet after the addition is stored in a checksum field of the UDP header or the TCP header included in the header for the mobile network.

5. The control device according to claim 4 , wherein the control device is a relay device that relays the received packets from a data network, and the receiving unit receives the received packets from the data network.

6. the received packets include user plane packets; the creation unit creates a header for the mobile network before the receiving unit receives the user plane packet from an external device; the second derivation unit calculates the checksum element before the receiving unit receives the user plane packet from the outside. The control device according to claim 1 .

7. A method for controlling a computer that transmits a received packet, comprising: receiving the received packet from an external device by the computer; If the received packet includes a Layer 4 header, the computer calculates a checksum of the received packet using the Layer 4 header; creating a header for a mobile network by the computer; calculating, by the computer, a checksum element to be added to the checksum of the received packet based on information included in the created header for the mobile network; the computer adding the checksum element to a checksum of the received packet; the computer stores the checksum of the received packet after the addition in a predetermined field of the header for the mobile network, and encapsulates the header for the mobile network in the received packet; the computer transmitting the encapsulated received packet; A method for controlling a relay device, comprising:

8. The computer that sends the received packet is a receiving unit that receives the received packet from an external device; a first derivation unit that calculates a checksum of the received packet using a Layer 4 header when the received packet includes the Layer 4 header; a generator for generating a header for a mobile network; a second derivation unit that calculates a checksum element to be added to the checksum of the received packet based on information included in the created mobile network header; a checksum processor that adds the checksum element to a checksum of the received packet; an encapsulation processing unit that stores the checksum of the received packet after the addition in a predetermined field of the header for the mobile network and encapsulates the header for the mobile network in the received packet; A program for causing the device to function as a transmitter for transmitting the encapsulated received packet.

Images