Improved use of IP networks for routing cellular data packets

Abstract

The cellular data communication system includes a BBU connected to a UPF by an IP network. A first conversion module converts GTP packets into IP packets transmitted on the IP network. A second conversion module converts the IP packets back into GTP packets and forwards the GTP packets to the UPF. A PFCP proxy intercepts control packets of the UPF. Information snooped by the PFCP proxy is provided to a routing / SDN controller that programs the conversion module and the routing module to route packets bypassing the UPF.

Description

Technical Field

[0001] This application relates to the routing of packets to and from a cellular data communication network.

Background Art

[0002] Referring to FIG. 1A, in a conventional 5G cellular data communication network 100, a user equipment (UE) 102 can transmit packets to a gNodeB 106, and the gNodeB 106 performs a function of receiving packets by a radio antenna and transmitting the received packets to an IP network 110 through a gateway (GW) 108. In a conventional cellular data communication network, packets from the UE 102 must be forwarded to a user plane function (UPF) 112, that is, the UPF 112 associated with the GW 108 that first receives the packets. The UPF 112 can receive packets on the network, and the network can be an Internet protocol (IP) network 110 between the UPF 112 and the GW 108. The UPF 112 can forward packets to a mobile edge computing (MEC) server 116 on another IP network 114. The MEC server 116 can be the destination of the packets. For example, the server can be a gateway accessing a wider network such as the Internet or provide a service that the packets are to handle.

[0003] Referring to Figure 1B, in some cases, packets need to be redirected from MEC server 116 associated with UPF112 to another MEC server 118. For example, GW108 can also be connected to one or more IP networks 120 connecting MEC server 118 and GW108. In the event of a failure of MEC server 116, or due to redirection for other purposes, packets are redirected to MEC server 118. However, the current 5G protocol requires packets to first be routed to UPF112, and then forwarded to MEC server 118, as illustrated in Figure 1B. Traffic from MEC server 118 to UE102 can follow the reverse path. This increases the latency of packets sent from and destined for UE102. [Overview of the project] [Problems that the invention aims to solve]

[0004] Providing an improved approach to handling packet redirection in cellular communication networks represents a technological advancement. [Means for solving the problem]

[0005] To solve the above problems, the present application provides a system and method as described in the claims.

[0006] To facilitate understanding of the advantages of the present invention, a more detailed description of the invention, briefly outlined above, is provided below with reference to specific embodiments illustrated in the accompanying drawings. These drawings are understood to illustrate only typical embodiments of the invention and therefore do not limit the scope of the invention. The present invention is described in detail and additional specifications using the accompanying drawings. [Brief explanation of the drawing]

[0007] [Figure 1A]This is a schematic diagram showing the routing of packets received on a cellular data communication network using conventional technology. [Figure 1B] This is a schematic diagram illustrating the rerouting of packets received on a cellular data communication network using conventional technology. [Figure 2] This is a schematic diagram illustrating an approach to routing packets received on a cellular data communication network according to an embodiment of the present invention. [Figure 3] This is a schematic diagram of a component that performs routing of packets received on a cellular data communication network according to an embodiment of the present invention. [Figure 4] This is a schematic diagram illustrating information snooping by a PFCP proxy and the programming of a conversion module and routing module using this information according to an embodiment of the present invention. [Figure 5] This is a schematic diagram of a PFCP proxy according to an embodiment of the present invention. [Figure 6] This is a schematic diagram illustrating the exchange of information between a PFCP proxy and a routing / SDN controller according to an embodiment of the present invention. [Figure 7] This is a schematic diagram of a computer system suitable for carrying out the method according to an embodiment of the present invention. [Modes for carrying out the invention]

[0008] It will be readily apparent that the components of the present invention illustrated and described in the accompanying drawings can be designed and arranged in a wide variety of different configurations. Therefore, the following more detailed description of the illustrated embodiments of the present invention is not intended to limit the scope of the invention as defined in the claims, but merely to illustrate specific examples of the embodiments of the present invention discussed herein. The embodiments described herein are best understood by reference to the drawings, and similar parts are indicated by similar reference numerals throughout the specification and drawings.

[0009] Embodiments of the present invention can be embodied as apparatus, methods, or computer program products. Therefore, the present invention can be embodied entirely in hardware form, entirely in software form (including firmware, resident software, microcode, etc.), or in combinations of hardware and software commonly referred to herein as “modules” or “systems.” Furthermore, the present invention can take the form of computer program products embodied in any tangible medium having computer-usable program code embodied within that medium.

[0010] Any combination of one or more computer-usable or computer-readable media can be used. For example, computer-readable media may include one or more portable computer diskettes, hard disks, random access memory (RAM) devices, read-only memory (ROM) devices, erasable programmable read-only memory (EPROM or flash memory) devices, portable compact disc read-only memory (CDROM), optical memory devices, and magnetic memory devices. In a selected embodiment, computer-readable media may include any non-temporary media that can contain, store, communicate, propagate, or transfer programs used by or connected to an instruction execution system, apparatus, or device.

[0011] The computer program code for performing the operations of the present invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and idiomatic procedural programming languages ​​such as the C programming language or similar programming languages, and can also be written using description languages ​​or markup languages ​​such as HTML, XML, and JSON. The program code can be executed as a standalone software package entirely on a computer system, on a standalone hardware unit, partially on a remote computer located at a certain distance from the computer, or entirely on a remote computer or server. In the later scenarios, the remote computer can be connected to the computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, via the Internet using an Internet service provider).

[0012] The present invention is described below with reference to flowcharts and / or diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. Each block of the flowchart and / or diagram, and combinations of blocks of the flowchart and / or diagram, can be implemented by computer program instructions or code. These computer program instructions are provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device, and the instructions executed by the processor of the computer or other programmable data processing device can generate means for implementing the functions / operations specified in one or more blocks of the flowchart and / or diagram.

[0013] These computer program instructions can also be stored in a non-temporary computer-readable medium that can guide a computer or other programmable data processing device to function in a particular way, so as to generate a product that includes instruction means that implements functions / operations specified in one or more blocks of a flowchart and / or configuration diagram, the instructions stored in the computer-readable medium generate a product that includes instruction means.

[0014] Just as instructions executed on a computer or other programmable data processing device provide a process for implementing the functions / operations specified in one or more blocks of a flowchart and / or diagram, computer program instructions are also loaded onto a computer or other programmable data processing device, triggering a series of operational steps executed on the computer or other programmable data processing device, thereby generating a computer implementation process.

[0015] Referring to Figure 2, in some embodiments, packets from UE102 are received by gNodeB106 and formatted as general packet radio service (GPRS) packets. gNodeB106 controls the functions of RU (radio unit, i.e., antenna), DU (distributed unit), and CU (centralized unit) and can manage the forwarding of packets between UE102 and network 110. gNodeB106 then encapsulates these packets in GPRS tunneling protocol (GTP) packets and forwards them to UPF112. Route 204 shows the route of packets sent to and from UPF112. Route 206 shows the route of redirected packets, as shown in Figure 1B, sent to and from different MEC servers 118, or sent to and from other destinations.

[0016] Packet output by gNodeB106 can be processed by translation module 208. In the illustrated embodiment, translation module 208 translates between GTP and Internet Protocol, i.e., protocols other than GTP that are not suitable for use in a cellular data network. In the illustrated embodiment, the Internet Protocol is SRv6 (Segment Routing on the IPv6 Data Plane). In the following description, references to migration between GTP and SRv6 can be understood as being interchangeable with references to migration between GTP and other Internet Protocols.

[0017] The translation module 208 can be placed between the gNodeB 106 and the SRv6 network 210, including a data plane and / or network with routing implemented by, for example, SRv6 or other IP protocols. The UPF 112 can be connected to the SRv6 network 210 by other translation modules 212. In some embodiments, the translation module 208, the network 210, and the translation modules 212 can be part of a common computing device installed in a common chassis. The common computing device can be installed together with one or both of the antenna 104 and the gNodeB 106. The common computing device may also include the MEC server 116.

[0018] Network 210 can also be connected to an external network 214 via an Internet Protocol routing module 216, etc. In the illustrated embodiment, the routing module 216 is an SRv6 router, but a router implementing other routing protocols can also be used. In some embodiments, the routing module 216 does not implement the GTP protocol. The external network 214 can be a WAN such as the Internet, and network 210 can be connected to other MEC servers 118 or any third-party servers that provide services to UE 102.

[0019] In the illustrated embodiment, some of the routes 204 and 206 labeled as "A" can transmit packets formatted as GTP packets (hereinafter referred to as "Type A packets"). In addition to encapsulated payload data, Type A packets may include an internal Internet Protocol (IP) header, a GTP header, a UDP (User Datagram Protocol) header, and an external IP header. The internal IP header may be an IP header generated on UE102 using an IP protocol. The external IP header may be an IP header generated by gNodeB106 using an IP protocol, or an IP header using a different IP protocol, and defines information for routing Type A packets to UPF112, MEC server 116, MEC server 118, or external network 214 on network 210.

[0020] A portion of the paths 204, 206 labeled as "B" can transmit packets formatted as Internet Protocol packets such as SRv6 packets (hereinafter referred to as "Type B packets"). Such packets can include Internet routing headers such as the internal IP header, segment routing header (SRH'), and IPv6 header defined above. The SRH' of each Type B packet can be added by the conversion modules 208, 212 that generated the Type B packet so as to include information from some or all of the GTP header, UDP header, and external IP header of the Type A packet converted to the Type B packet. In particular, the information stored within the SRH' can include sufficient data for other conversion modules 208, 212 to convert the Type B packet into a Type A packet (GTP packet). The IPv6 field can be a packet formatted by an Internet Protocol (IP) such as IPv6 and can include information sufficient to route the packet on an IP network such as network 210, including data for the source IP address, destination IP address, and other fields defined by IPv6 or other Internet protocols. This information can be obtained from the external IP header of the Type A packet that is converted to obtain the Type B packet. The IPv6 packet can also include the payload data from the Type A packet.

[0021] A portion of the paths 204, 206 labeled as "C" includes the same field definitions as the Type B packet, but can transmit Type C packets formatted as Internet Protocol packets that do not store information from the GTP header of the Type A packet and / or are not converted to Type B packets using the information within the SRH field. As illustrated in FIG. 2, packets transmitted from the MEC server 118 to the UE 102 pass through the network 210 as Type B packets, while packets transmitted from the UE 102 to the MEC server 118 can pass through the network 210 as Type C packets.

[0022] Part of the paths 204 and 206 labeled as "D" can transmit D-type packets formatted as Internet protocol packets, including the internal IP header and payload data of C-type packets that are converted to obtain D-type packets. In particular, the D-type packets can include IP packets transmitted from the UE 102, MEC servers 116, 118, or the external network 214 and received by the gNodeB 106.

[0023] "Direct inbound packets" are packets that pass through the gNodeB 106 without being redirected and move from left to right along the path 204 in FIG. 2. The direct inbound packets are transmitted from the UE 102 to the gNodeB 106. When received by the gNodeB 106, the direct inbound packets can be D-type packets such as IPv4 or IPv6. When output by the gNodeB 106, the direct inbound packets can be A-type packets transmitted by the gNodeB 106 to the conversion module 208. In particular, the A-type packets can be GTP packets encapsulating the IP packets received from the UE **********

[0024] The conversion module 208 converts the A-type direct inbound packets into B-type packets and uses the information contained in the external IP header of the A-type direct inbound packets to transmit the B-type direct inbound packets to the UPF 112 on the network 210. As described above, the information from the GTP field of the A-type packets is included in the SRH' field of the B-type packets obtained from the A-type packets, enabling reconversion to the A-type packets. However, the B-type packets themselves can be SRv6 packets instead of GTP packets. The B-type packets further include the internal IP header and payload data from the A-type packets.

[0025] The Type B direct inbound packet is routed to the translation module 212, which uses the information stored in the SRH' of the Type B packet to convert the direct inbound packet from a Type B packet to a Type A packet. In particular, the data in the SRH' field of the Type B packet is used to generate the GTP header of the GTP packet, which contains the internal IP header and payload data of the Type B packet, and the GTP packet is the Type A direct inbound packet for the Type B direct inbound packet.

[0026] After conversion by the conversion module 212, the Type A direct inbound packet is sent to UPF 112. UPF 112 then decapsulates the direct inbound packet to obtain an internal IP packet (for example, a Type D packet received from UE 102) and forwards the Type D direct inbound packet to the MEC server 116.

[0027] A "redirected inbound packet" is a packet originating from UE102 as a Type D packet, transmitted through gNodeB106, but redirected away from MEC server 116 to an external network 214 and / or another MEC server 118 or a third-party server. The redirected inbound packet can travel along route 206 from the upper left to the lower right of Figure 2. Once output by gNodeB106, the redirected inbound packet can be a Type A packet sent by gNodeB106 to the translation module 208. The translation module 208 converts the Type A redirected inbound packet into a Type C packet, which does not contain information from the GTP or UDP header of the Type A redirected inbound packet. The translation module 208 then sends the Type C redirected inbound packet to the MEC server 118 to which the packet was redirected, for example, via routing module 216. The routing module 216 converts the Type C redirect inbound packet into a Type D packet and sends the Type D redirect inbound packet to the MEC server 118. As described above, the conversion may include decapsulating the Type D packet that was encapsulated within the Type C packet.

[0028] A "direct outbound packet" is a packet that passes through UPF112 and is sent to UE102 via gNodeB106 without responding to redirected inbound packets or any part of the same network flow as redirected inbound packets. For example, a packet from MEC server 116 is sent as a direct outbound packet via UPF112. A direct outbound packet can travel along route 204 from right to left in Figure 2. A packet sent from MEC server 116 and received by UPF112 can be a type D packet. When output by UPF112, the direct outbound packet is a type A packet encapsulating the type D packet and is sent by UPF112 to the translation module 212. The translation module 212 converts the type A direct outbound packet to a type B packet and uses the information contained in the IPv6 field of the type B packet to send the type B direct outbound packet to gNodeB106 on network 210. The conversion involves converting a GTP packet into an SRv6 packet, where the SRv6 packet contains data from the GTP header of the GTP packet in the SRH' field of the SRv6 packet, and the SRv6 packet further contains the internal IP header and payload data of the GTP packet.

[0029] Type B direct outbound packets are routed by translation module 212 to translation module 208, which uses the information stored in the SRH' of the Type B packet to re-translate the Type B direct outbound packets into Type A direct outbound packets. This involves encapsulating the SRv6 packet with the internal IP header and payload data of the Type B packet and converting it into a GTP packet containing data from the SRH' field in the GTP header.

[0030] After conversion by the conversion module 208, the Type A direct outbound packet is sent to gNodeB106. gNodeB106 then decapsulates the Type A packet to obtain a Type D direct outbound packet and forwards the Type D direct outbound packet to UE102. Decapsulation includes extracting the internal IP header and payload data from the GTP packet.

[0031] A "redirected outbound packet" can be a packet originating from a location within the external network 214 to which a redirected inbound packet is routed, or from the MEC server 118. Redirected outbound packets are sent in response to redirected inbound packets or parts of the same network flow. For example, a redirected outbound packet is sent to UE 102 by the MEC server 118 or a third-party server. A redirected outbound packet can travel along route 206 from the lower right to the upper left of Figure 2. A redirected outbound packet can travel along the route to the translation module 208, passing through the external network 214, the routing module 216, and some or all of the network 210. Upon reception by the routing module 216, the redirected outbound packet is a type D packet, which is converted by the routing module 216 into a type B redirected outbound packet, and the type B redirected outbound packet is forwarded to the translation module 208 on the network 210. The conversion involves encapsulating the internal IP header and payload data of the IP packet within a GTP packet.

[0032] The conversion module 208 converts a Type B redirected outbound packet to a Type A packet and sends the Type A redirected outbound packet to gNodeB106. The conversion from Type B to Type A involves using the information stored in the SRH' of the Type B packet. This involves converting the SRv6 packet into a GTP packet that encapsulates the internal IP header and payload data of the Type B packet and includes data from the SRH' field in the GTP header. gNodeB106 then decapsulates the Type D redirected outbound packet (internal IP header and payload data) from the Type B redirected outbound packet and sends the Type D redirected outbound packet to UE102.

[0033] In some embodiments, user plane messages are messages used to establish and maintain a session between UPF112 and UE102. User plane messages may also include messages sent by UPF112 to instruct the routing of packets to and from UE102 and MEC server 116, or the redirection of packets to the external network 214. User plane messages may also transmit 5G user plane messages such as echo requests, echo replies, error indications, or other user plane messages.

[0034] Inbound user plane messages can be routed as direct inbound packets. User plane messages sent from UPF112 are processed as direct outbound packets in all instances. When redirection occurs as instructed by UPF112, subsequent inbound data packets, i.e., non-user plane message packets, are routed by translation module 208 as redirected inbound packets that bypass UPF112. Translation module 208 can identify user plane messages by performing deep packet inspection of the inbound packets. The system and method for performing this routing are described below.

[0035] Referring to Figure 3, the network path between UE102 and the external network 214 is understood with respect to the control plane 300 and the data plane 302. The control plane 300 includes modules and inter-module communication, which configures the modules of the data plane 302 to transmit packets in a predetermined manner. The data plane 302 includes modules and inter-module communication, which transmits packets of payload data between UE102 and the external network 214. The modules of the control plane 300 and the data plane 302 can be implemented in a single device, in multiple devices connected to a common circuit board or chassis, or in multiple devices connected to each other by one or more network connections. The illustrated components can run on a server, a cloud computing platform, or other location, or can be distributed across one or more of these locations.

[0036] The control plane 300 and data plane 302 can also be divided into parts 304 and 306. Part 304 is understood to transmit data packets using a packet radio communication protocol (packet radio part 304), i.e., a protocol suitable for use in communication using GPRS, GTP, or other cellular data communication protocols. In the illustrated embodiment, part 304 implements the Third Generation Partnership Project (3GPP) protocol for cellular data communication, but other cellular data communication protocols may also be used.

[0037] Part 306 can be understood to transmit data packets using an Internet protocol such as the IPv6 protocol or another Internet protocol that is not suitable for use in packet radio communication (IP part 306).

[0038] The control plane 300 of the packet radio portion 304 may include the following components: • A Home Subscriber Server (HSS UDM) 308 or other component with integrated data management that manages some or all of the authentication, handover, IP Multimedia Subsystem (IMS), and Simple Message Service (SMS). • Policy control function (PCF) and / or policy and billing rule function (PCRF)310 that manages user access to the cellular data communication network. • Access and mobility management functions (AMF) and / or mobility management entities (MME) 312 or other components that manage connection and mobility management tasks (i.e., handover). • Session management function (SMF) and / or serving and packet gateway (SPGW such as SPGW-C) 314 (also referred to here as SMF314) or other components that manage user sessions with UPF and facilitate interfacing between packet radio networks and Internet Protocol networks.

[0039] The SMF314 can manage GTP session information and provide it to the AMF312. The AMF312 can program components within the data plane 302 (gNodeB106 described below) to route packets based on the GTP session information.

[0040] The data plane 302 of the packet radio portion 304 may include the following components: The gNodeB106 or other hardware component can also communicate directly with the UE via an antenna, encapsulate packets from the UE into GTP packets, and implement the User Plane Control Protocol. A conversion module 208 that converts packets to GTP or SRv6 when traversing between the packet radio portion 304 and the IP portion 306.

[0041] The control plane 300 of the IP portion 306 may include the following components: • Packet Forwarding Control Protocol (PFCP) proxy 322, as described in more detail below. • Border Gateway Protocol (BGP) module 324 or other components that receive and / or transmit routing paths to other components illustrated in Figure 3 and / or to any other devices in any of the networks described herein. • A User Plane Function Control Module (UPF N4) 326 or other component that disconnects the GTP connection and manages packet transmission between the packet radio network and the Internet Protocol network. The UPF N4 326 facilitates session establishment with UPF 112.

[0042] The data plane 302 of the IP portion 306 may include the following components: • The above UPF112. • Conversion module 208 that operates with both parts 304 and 306. Network 210 • Routing module 216. • A conversion module 212 that converts the traffic sent to UPF112 as described above.

[0043] In the illustrated implementation, packet forwarding associations via PFCP are coordinated between the SMF314 and the UPF control module 326 via the PFCP proxy 322. Therefore, the SMF314 and the UPF control module 326 can exchange session information via the PFCP proxy 322. The PFCP proxy 322 can snoop this information and provide it to the BGP module 324. Thus, the PFCP proxy 322 can be associated with the PFCP implementation of the UPF control module 326 and the SMF314. The BGP module 324 can use the snooped information to program the data plane 302 (e.g., translation modules 208, 212, routing module 216) and perform GTP-to-IP protocol (e.g., SRv6) and IP protocol-to-GTP conversions using the information snooped by the PFCP proxy 322, as described below.

[0044] Existing software packages for implementing PFCP are proprietary and cannot be easily modified. While several open-source software packages for implementing PFCP are available, they only exist as packages that must be integrated into the application. Furthermore, the network stack of the UPF control module 326 is implemented by third-party or open-source software (e.g., upg-vpp (User Plane Gateway Vector Packet Processor)) that cannot be easily modified.

[0045] In some embodiments, the PFCP proxy 322, BGP module 324, and internal routing module 216 can be modified compared to conventional implementations of such components in order to perform the following: • Establish the PFCP implementation of the UPF control module (UPF N4) 326 and the association between it and the SMF 314. • Transferring messages between the PFCP implementation of the UPF control module 326 and the SMF314. • Snooping session messages to BGP module 324 to obtain such information as the UE102 address, remote / local tunnel endpoint (TEP) address, tunnel endpoint identifier (TEID), and other information.

[0046] Figure 4 further illustrates exemplary implementations of the PFCP proxy 322 and BGP module 324. In a conventional 5G mobile network, associations, such as a control channel, are established between the AMF MME 312 and the UPF N4 326. Sessions, such as user plane information, are established between the SMF SPGW 314 and the UPF N4 326. Once a session is established between the SMF SPGW 314 and the UPF N4 326, the UE 102 begins transmitting payload traffic. Subsequently, the gNodeB 106 encapsulates the packets from the UE 102 into GTP packets and forwards the GTP packets to the UPF 112. In a typical 5G implementation, association and session requests are sent to UDP port 8805 of the UPF N4 326, and responses to the requests from the UPF N4 326 are sent to the source UDP port from which the requests were received.

[0047] In conventional systems, optimizing the routing between gNodeB106 and UPF112 is difficult for the reasons mentioned above. All UE traffic must be encapsulated in GTP packets and forwarded through UPF112.

[0048] In some embodiments, the limitations of conventional 5G mobile networks are overcome by placing a PFCP proxy 322 between the SMF SPGW 314 and the UPF N4 326, with the PFCP proxy 322 forwarding traffic between these components. Thus, the PFCP proxy 322 receives PFCP messages from the SMF SPGW 314 and forwards these messages to the UPF N4 326. Similarly, the PFCP proxy 322 receives PFCP messages from the UPF N4 326 and forwards these messages to the SMF SPGW 314. At that time, the PFCP proxy 322 can parse PFCP messages bidirectionally to obtain user plane information.

[0049] Subsequently, the PFCP proxy 322 can provide user plane information to a routing / software-defined network (SDN) controller operating outside the PFCP proxy 322.402 In the illustrated embodiment, the routing / SDN controller is implemented using a BGP module 324, but other implementations can be used. The PFCP proxy 322 and the routing / SDN controller 324 can run on the same computing device or on separate computing devices. The PFCP proxy 322 and the routing / SDN controller 324 can achieve the routing illustrated in Figure 2 without further modifications to the control plane 300, particularly the SMF SPGW-C314 and UPF N4 326. In particular, the SMF SPGW-C314 and UPF N4 326 can exchange information to establish a 5G session via the PFCP proxy 322 so that the operation of the PFCP proxy 322 is not detected by the SMF SPGW-C314 and UPF N4 326.

[0050] BGP module 324 can program translation module 208 in the data plane according to user plane information 404a. Translation module 208 then forwards packets redirected to redirect targets such as MEC server 118 or external network 214 via routes received from BGP module 324 over UPF 112, resulting in more optimized routing compared to the conventional approach where packets are routed to first pass through UPF 112. BGP module 324 can also program translation module 212 to route control packets to UPF 112 404b, and routing module 216 to route packets to and from MEC server 118 or other devices connected to routing module 216 via external network 214 404c.

[0051] Regarding programming 404a, the BGP module 324 provides the translation module 208 with a route to UPF112 and also provides rules on how to translate GTP packets into SRv6 packets, i.e., A-type packets into B-type packets as described above. Therefore, when the translation module 208 receives a GTP packet whose destination is UPF112, the translation module 208 applies the rules received from the BGP module 324 and performs the translation.

[0052] With respect to programming 404b, BGP module 324 can provide similar or identical rules to translation module 212. Based on these rules, translation module 212 can convert SRv6 packets to GTP packets and regenerate the original GTP packets sent to UPF112. BGP module 324 can also provide translation module 212 with a route to gNodeB106. When UPF112 sends a GTP packet destined for gNodeB106, translation module 212 converts the GTP packet to an SRv6 packet according to the above rules and then forwards the resulting SRv6 packet to translation module 208. Translation module 208 can convert the SRv6 packet back to a GTP packet according to the same rules and then forward the resulting GTP packet to gNodeB106.

[0053] For packets sent by UE102 toward external network 214 or external MEC server 118, routing module 216 can announce external routes to external MEC server 118 and / or external routing module 214 to translation module 208. This can be done based on the standard L3VPN SRv6 method. Therefore, translation module 208 can perform standard SRv6 encapsulation based on internal packets generated by UE.

[0054] Regarding programming 404c, routing module 216 can implement a standard SRv6 router that lacks the ability to process GTP packets. Therefore, programming 404c may include having BGP module 324 generate a special service SID for SRv6 that includes GTP information (e.g., some or all of the GTP information that can be embedded in the SRH' header of a Type B packet). As described above, redirected inbound packets passing through network 210 can be formatted as Type B packets. Therefore, programming 404c may program routing module 216 to add GTP information to the SRH' field of the SRv6 header that encapsulates each packet received from MEC server 118 or external network 214 destined for gNodeB106.

[0055] For responses received from the external network 214 or external MEC server 118 destined for UE102, the routing module 216 can encapsulate the response packet (an IP packet such as IPv4 or IPv6) into an SRv6 packet. In this case, the routing module 216 can use a special service SID provided by the BGP module 324. This SID contains the necessary GTP information included in the SRH' header. Therefore, the translation module 208 can translate the SRv6 packet into a GTP packet and send the resulting GTP packet to gNodeB106.

[0056] Figure 5 illustrates an exemplary implementation of a PFCP proxy 322. The PFCP proxy 322 can parse PFCP messages to obtain 5G session information, process the messages as shown below, and forward the PFCP messages to these destinations. In some embodiments, the go-pfcp package is used to parse PFCP messages. For example, in the illustrated embodiment, the PFCP proxy 322 includes a PFCP request receiver 500, an SMF request forwarder 502, a UPF request forwarder 504, an SMF response receiver 506, a UPF response receiver 508, an SMF response forwarder 510, and a UPF response forwarder 512. Each of these components can be assigned to send from or listen on a specific port of the PFCP proxy 322. The operation of each component is described below.

[0057] When a PFCP message is forwarded to UPF N4 326, the PFCP proxy 322 rewrites the IP source address of the forwarded message to the PFCP proxy's address and the IP destination address to the UPF N4 326's address. The PFCP proxy 322 can also rewrite the UDP source port of the forwarded request to the PFCP proxy's port number. The PFCP request, rewritten by the PFCP proxy 322, can then be sent to UPF N4 326.

[0058] When a PFCP message is forwarded to the SMF SPGW-C314, the PFCP proxy 322 rewrites the IP source address to the PFCP proxy's address, the IP destination address to the SMF SPGW-C314's address, and the UDP source port to the PFCP proxy's local port number. The PFCP proxy then sends the rewritten PFCP response to the SMF SPGW-C314.

[0059] By rewriting messages 514 and 516 in this manner, the SMF SPGW-C314 and UPF N4 326 communicate with the PFCP proxy 322. However, the PFCP proxy 322 can override the IP source / destination addresses and UDP source port so that the SMF SPGW-C314 and UPF N4 326 cannot recognize the PFCP proxy 322.

[0060] The PFCP proxy 322 intercepts PFCP messages by listening on UDP port 8805. UDP port 8805 is a 3GPP-defined port for receiving PFCP messages. Therefore, if a different configuration is used, UDP port 8805 can be replaced with a different port through the following description. The operation of the PFCP proxy 322 components is as follows: The PFCP request receiver 500 listens for PFCP request messages 514 and 516 destined for UDP port 8805 from an SMF SPGW-C314 or UPF N4 326, i.e., a port assigned to receive PFCP messages, and records the source port of PFCP request 514 from SMF SPGW-C314 (port A in the illustrated embodiment). The PFCP request receiver 500 further records the source port of PFCP request 516 from UPF N4 326 (port B in the illustrated embodiment). The source ports of messages 514 and 516 can be pre-configured (on ports X and Y, respectively). The SMF request forwarder 502 forwards request 516 to the SMF SPGW-C314. The SMF request forwarder 502 is configured by the PFCP request receiver 500 to use X as the source port for request 516 forwarded to the SMF SPGW-C314 by the SMF request forwarder 502. The SMF request forwarder 502 further modifies the forwarded request 516 by rewriting the IP destination address to the IP address of the SMF SPGW-C314 and the IP source address to the IP address of the PFCP proxy 322. The UPF request forwarder 504 forwards request 514 to UPF N4 326. The UPF request forwarder 504 is configured by the PFCP request receiver 500 to use Y as the source port for request 514 forwarded to UPF N4 326 by the UPF request forwarder 504. The UPF request forwarder 504 further modifies the forwarded request 514 by rewriting the IP destination address to the IP address of UPF N4 326 and the IP source address to the IP address of the PFCP proxy 322. The SMF response receiver 506 is configured to detect a PFCP response 518 from the SMF SPGW-C314 destined for port X and to provide the detected PFCP response 518 to the UPF response forwarder 512. The UPF response receiver 508 is configured to detect the PFCP response 520 from the UPF N4 326 destined for port Y and to provide the detected PFCP response 520 to the SMF response forwarder 510. The SMF response forwarder 510 is programmed to forward the PFCP response 520 to the SMF SPGW-C314, setting the source of the forwarded PFCP response 520 to UDP port 8805 and the destination to port A (the pre-recorded source port of request 514). The SMF response forwarder 510 further modifies the forwarded response 520 by rewriting the IP destination address to the IP address of the SMF SPGW-C314 and the IP source address to the IP address of the PFCP proxy 322. The UPF response forwarder 512 is programmed to forward the PFCP response 518 to port Y of UPF N4 326, set the source of the forwarded PFCP response 518 to UDP port 8805 and the destination to port B (the previously recorded source port of request 516). The UPF response forwarder 512 further modifies the forwarded response 518 by rewriting the IP destination address to the IP address of UPF N4 326 and the IP source address to the IP address of PFCP proxy 322.

[0061] Referring to Figure 6, as described above with respect to Figure 4, when the PFCP proxy 322 forwards a message, the PFCP proxy 322 can also snoop information about the associations and sessions created using the message. This snooped information is then provided to the routing / SDN controller 324 (BGP module 324). In the illustrated embodiment, the transfer of information between the PFCP proxy 322 and the routing / SDN controller 324 is performed using inter-process communication (IPC) 600, for example, gRPC (Open Source Remote Procedure Call (RPC) system). The SDN controller 324 can then program the routing table 602 with the snooped information.

[0062] The snooped information includes some or all of the following: • The address of the remote tunnel terminus (TEP), for example, UPF112. • The address of the local tunnel terminus, for example, gNodeB106. • Tunnel terminus identifier (TEID). • QFI (Quality of Service (QoS) Flow Identifier). • UE address (address of UE102). • Access network instance. • Core network instance.

[0063] After receiving this information, the routing / SDN controller 324 can generate routing entries in the routing table 602 based on this information. These routing entries can be used to control the routing of translation modules 208, 212, or routing module 216 in order to implement the routing described above with respect to Figures 2 and 4.

[0064] Referring again to Figure 2, the desired routing may include receiving internal IP packets from UE102 via gNodeB106, which generates Type A (GTP) packets containing internal IP packets. gNodeB106 then transmits Type A packets to UPF112 over a GTP tunnel between gNodeB106 and UPF112. The parameters defining this GTP tunnel are included in the snooped information described above, particularly in the remote tunnel terminus referencing UPF112 and the local tunnel terminus referencing gNodeB106.

[0065] As described above with respect to Figure 2, rather than simply routing Type A packets through the GTP tunnel, Type A packets are converted to Type B or Type C packets and routed on the IP network 210, such as the SRv6 network 210. The transition between the IP network 210 and the GTP tunnel is managed by conversion modules 208 and 212. The routing module 216 also needs to route packets by referring to the parameters that define the GTP tunnel. Snooped information obtained by the PFCP proxy 322 can be provided to the routing / SDN controller 324. The routing / SDN controller 324 then programs the conversion modules 208, 212 and the routing module 216 to achieve the routing described above with respect to Figure 2. Various embodiments of how the routing / SDN controller 324 programs the conversion modules 208, 212 and the routing module 216 are described below.

[0066] In the first embodiment, the routing / SDN controller 324 receives the remote tunnel endpoint and generates and distributes a route to UPF112. In particular, this route can be provided to the translation module 208. The route can also be provided to programming 404a to perform the translation between GTP and SRv6, as described above.

[0067] In the second embodiment, the routing / SDN controller 324 receives the local tunnel endpoint and UE address, and generates and distributes a service SID based on this information via SRv6. In particular, the service SID can be provided to the routing module 216. The service SID advertises a route to UE102 on network 210 via gNodeB106, referencing the local tunnel endpoint. The routing / SDN controller 324 can also use QFI when generating the service SID. This second embodiment can be implemented when the above programming 404c is executed.

[0068] In the third embodiment, gNodeB106 can send Type A (GTP) packets into the GTP tunnel established with UPF112 by setting the destination of the Type A packets to the remote tunnel endpoint (the tunnel endpoint address of UPF112). The PFCP proxy 322 obtains this remote tunnel endpoint address by snooping control packets between gNodeB106 and UPF112 when the GTP tunnel is configured. The PFCP proxy 322 can then provide the remote tunnel endpoint address to the routing / SDN controller 324.

[0069] Subsequently, the routing / SDN controller 324 generates a routing entry for this remote tunnel endpoint, and this routing entry can be used to program the translation module 208. In some embodiments, the routing / SDN controller 324 generates the routing entry using a function such as GTP4.D. The routing entry can specify the conversion from type A packet to type B packet, including encoding of GTP header information into the SRH' header, and can specify routing to the translation module 212 through the network 210 in the form of one or more SIDs by a segment routing protocol such as SRv6.

[0070] In the fourth embodiment, the routing of traffic from ingress premise equipment (PE) to egress premise equipment is managed based on the snooped information described above. The ingress premise equipment may be, for example, a translation module 208, and the egress premise equipment may be a routing module 216 for interface connection with an external network 214 or MEC server 118. In the reverse direction, the routing module 216 is the ingress premise equipment and the translation module 208 is the egress premise equipment.

[0071] In a standard virtual private network (VPN) such as L3VPN SRv6, the egress premises device sends an SRv6 packet containing an internal packet, which is a packet received from the IP network. The destination address of the SRv6 packet can be set to an IP address, such as an IPv6 address (e.g., a segment identifier (SID)) assigned to the egress premises device. The egress premises device receives the SRv6 packet, decapsulates the internal packet, and forwards the internal packet to the internal packet's destination address. In the illustrated embodiment, the destination address of the internal packet can be in the form of an IPv6 destination (e.g., SID). Therefore, the egress premises device can determine where to forward the internal packet based on the destination address of the internal packet, which is a third-party server or UE102, depending on the direction the packet is traveling through network 210.

[0072] In the illustrated embodiment, the egress premises device (e.g., translation module 208) needs to determine which set of gNodeB instances (gNodeB106) are available to which internal packets should be forwarded to reach a particular UE102. Thus, the egress premises device can receive routing entries from the routing / SDN controller 324 that map the IP address of UE102 to the local tunnel endpoint of gNodeB106 to which UE102 is connected (e.g., has TCP or other established sessions). The association between the IP address of UE102 and the local tunnel endpoint can be determined from the snooped information described above.

[0073] A routing entry can instruct egress premises devices to use the local tunnel endpoint of gNodeB when performing packet translation from type C packets to type A packets and sending the resulting type A packets to gNodeB106 over the GTP connection. For example, when GTP4.D (IPv4 GTP) is used, the routing / SDN controller 324 can provide the following IPv6 addresses to egress premises devices. SRv6 locator (<56 bits) + TEID (32 bits) + QFI (8 bits) + local tunnel endpoint address (32 bits)

[0074] The SRv6 locator can refer to the configuration on the routing / SDN controller 324. Based on the SRv6 locator, translation modules 208 and 212 can recognize the translation function they are about to perform. For example, BGP324 can assign 2001:db8:: / 48 as the SRv6 locator for translation between GTP and SRv6. In this case, when translation modules 208 and 212 generate an SRv6 packet from a GTP packet, they use 2001:db8:: / 48 as the SRv6 locator and embed the TEID, QFI, and TEP address of the GTP packet in the SRH' field. When translation modules 208 and 212 receive an SRv6 packet whose destination matches 2001:db8:: / 48, they can understand that the SRv6 packet needs to be translated to GTP. The conversion modules 208 and 212 can obtain the TEID, QFI, and TEP address from the SRH' field and then regenerate the original GTP packet. The GTP packet can then be sent to either the UPF112 or gNodeB106, which is the designated destination.

[0075] In Multipath Label Switching (MPLS) within an L3VPN, an SRv6 locator can be used to identify the assigned VPN. In the case of an SRv6 L3VPN, the SRv6 locator can identify the service SID (IPv6 address format) and can be used to identify the assigned VPN instead of the MPLS L3VPN label.

[0076] The local tunnel endpoint address can be embedded within the IPv6 address mentioned above. This address can also be announced to the egress premises device as a service SID. When the egress premises device receives a packet whose destination matches this IPv6 address, it can determine which gNodeB instance to forward the packet to, obtain the local tunnel endpoint of the baseband unit (BBU), and generate a GTP packet (Type A packet) to send to the gNodeB instance. The routing / SDN controller 324 can program the egress premises device using routing rules such as GTP4.D routing rules, which instruct the egress premises device on how to perform the conversion from IPv6 addresses to GTP packets.

[0077] To convert from SRv6 to GTP, the Egress premises equipment can use the following information: the local tunnel endpoint address (the address of gNodeB106), the TEID (tunnel identifier), and the QFI (QoS identifier). The local tunnel endpoint address is the destination address of the GTP packet. The TEID and QFI are values ​​that must be embedded in the GTP header. Therefore, this information is embedded in the IPv6 destination address (see the example address above) of packets routed from the Ingress premises equipment to the Egress premises equipment, facilitating the conversion from SRv6 to GTP.

[0078] This information (local tunnel endpoint address, TEID, QFI) is obtained by the PFCP proxy 322 and provided to the routing / SDN controller 324, which then uses the information to embed it in the ingress and egress premises devices and program them to perform the conversion using the information as described above. The routing / SDN controller 324 performs the above programming by announcing a VPNv4 / v6 route with an IPv6 address containing the information embedded as a service SID provided to the ingress premises device. The routing / SDN controller 324 can also program this information into the egress premises device in the form of an SRv6 locator created using the GTP4.E function.

[0079] When an Ingress premises device receives a packet from an IP network, it can encapsulate the SRv6-containing packet from the IP network. At this time, the external IPv6 destination address is the service SID, which includes the embedded information. When an Egress premises device receives a packet with an external IPv6 destination address that matches the service SID, it can decide to perform the GTP4.E function on the received packet and convert the packet into a GTP(Type A) packet using the TEID, QFI, and local tunnel termination embedded in the IPv6 destination address.

[0080] In the fifth embodiment, the routing module 216 can receive packets from the external network 214 destined for the IP address of UE102. The snooped information provides an association with the local tunnel terminus of gNodeB106. Thus, the routing / SDN controller 324 announces a route to the routing module 216, instructing it to route traffic destined for the IP address of UE102 to gNodeB106. The packets are then routed by the routing module 216 to UE102 via gNodeB106 through route 206 in Figure 2, which includes the conversion between D, C, and A packets as described above.

[0081] In the sixth embodiment, the snooped information may include core network instances. This value can be used for network slicing in the 5G core network. Based on this value, the routing / SDN controller 324 can determine which virtual routing and forwarding (VRF) table to import UE addresses from and which VPN (VRF) to use when generating routes to UE102 during the execution of programming 404c. Access network instances in the snooped information can be used to remove specific UE addresses from the assigned VRF table. Thus, the routing / SDN controller 324 can specify import rules and / or filter rules based on the core network instances and access network instances specified in the snooped information.

[0082] Figure 7 is a diagram illustrating an exemplary computing device 700 that can be used to implement the methods and systems disclosed herein. The computing device 700 can function as a server, a client, or any other computing entity. The computing device can perform various functions described herein and can run one or more application programs, such as the application programs described herein. The computing device 700 can be any of the many types of computing devices, such as desktop computers, laptop computers, server computers, portable computers, tablets, etc.

[0083] The computing device 700 includes one or more processors 702, one or more memory devices 704, one or more interfaces 706, one or more mass storage devices 708, one or more input / output (I / O) devices 710, and a display device 730, all of which are connected to the bus 712. The processor 702 includes one or more processors or control devices and executes instructions stored in the memory devices 704 and / or mass storage devices 708. The processor 702 may also include various types of computer-readable media such as cache memory.

[0084] The memory device 704 includes various computer-readable media such as volatile memory (e.g., random access memory (RAM) 714) and / or non-volatile memory (read-only memory (ROM) 716). The memory device 704 may also include rewritable ROM such as flash memory.

[0085] The mass storage device 708 includes various computer-readable media such as magnetic tape, magnetic disks, optical disks, and solid-state memory (e.g., flash memory). As illustrated in Figure 7, a specific mass storage device is a hard disk drive 724. Various drives may also be included within the mass storage device 708 to enable reading from and / or writing to various computer-readable media. The mass storage device 708 includes removable media 726 and / or non-removable media.

[0086] The input / output device 710 includes various devices that enable inputting data and / or other information to or from the computing device 700. Exemplary input / output devices 710 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other imaging devices, etc.

[0087] The display device 730 includes any type of device capable of displaying information to one or more users of the computing device 700. Examples of the display device 730 include monitors, display terminals, video projection devices, and the like.

[0088] Interface 706 includes various interfaces that enable the computing device 700 to exchange information with other systems, devices, or computing environments. An exemplary interface 706 includes any number of different network interfaces 720, such as interfaces to a local area network (LAN), a wide area network (WAN), a wireless network, and the Internet. Other interfaces include a user interface 718 and a peripheral device interface 722. Interface 706 may also include one or more user interface elements 718. Interface 706 may also include one or more peripheral device interfaces, such as interfaces to a printer, pointing device (mouse, trackpad, etc.), and keyboard.

[0089] Bus 712 enables the processor 702, memory device 704, interface 706, mass storage device 708, and input / output device 710 to communicate with each other, as well as with other devices or components connected to bus 712. Bus 712 represents one or more types of bus structures, such as a system bus, PCI bus, IEEE1394 bus, and USB bus.

[0090] For illustrative purposes, programs and other executable program components are shown here as separate blocks, but it is understood that such programs and components reside at different times within different storage components of the computing device 700 and are executed by the processor 702. Alternatively, the systems and processes described herein can be implemented in hardware or in a combination of hardware, software, and / or firmware. For example, one or more application-specific integrated circuits (ASICs) can be programmed to perform one or more systems and processes disclosed herein. [Explanation of symbols]

[0091] 100 Network Environment Route 204 206 routes 514 Message 516 Message 518 PFCP response 520 PFCP response 700 Computing Devices 712 Bus

Claims

1. An antenna that receives signals from user equipment, A packet radio network connected to the aforementioned antenna, Internet Protocol Network and A conversion module placed between the packet radio network and the Internet Protocol network, A user plane function configured to manage communication with the aforementioned user device, A proxy placed between the packet radio network and the user plane function, A cellular data communication system including, The aforementioned proxy, Intercept any traffic from and to the user plane function, Snooping session information from the aforementioned traffic, and then The programming of the conversion module that converts the first packet received on the packet wireless network into a second packet is called. The second packet is transmitted over the Internet Protocol Network according to the session information. A cellular data communication system characterized by being configured in such a way.

2. The cellular data communication system according to claim 1, wherein the session information includes information describing a protocol tunnel terminated by the user plane function, and the information describing the protocol tunnel includes any of the following: a tunnel endpoint (TEP) address, a TEP identifier (TEID) of the user plane function, a local TEID of the protocol tunnel, and the address of the user device.

3. The cellular data communication system according to claim 2, characterized in that the TEP address is the address of gNodeB.

4. The cellular data communication system according to claim 2, characterized in that the protocol tunnel is a General-Purpose Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel.

5. The cellular data communication system according to claim 4, characterized in that the first packet is formatted by GTP, and the conversion module is programmed to convert the first packet into the second packet so that the second packet is formatted by the Internet Protocol.

6. The cellular data communication system according to claim 5, characterized in that the second packet contains sufficient information to re-convert the second packet into a GTP packet.

7. The cellular data communication system according to claim 5, further comprising a routing and software-defined network (routing / SDN) controller positioned between the proxy and the conversion module, wherein the routing / SDN controller is programmed to program the conversion module using the information.

8. The cellular data communication system according to claim 7, characterized in that the routing / SDN controller includes a Border Gateway Protocol (BGP) module.

9. Furthermore, it includes a routing module that connects the Internet Protocol network to an external network, The cellular data communication system according to claim 5, further characterized in that the proxy is programmed to call the programming of the routing module according to the session information.

10. The aforementioned conversion module is a first conversion module, The cellular data communication system further includes a second conversion module, and the path between the antenna and the user plane function includes the first conversion module, the Internet Protocol network, and the second conversion module, and The cellular data communication system according to claim 5, characterized in that the proxy is configured to call the programming of the second conversion module which converts the second packet into a third packet according to the session information, and the third packet is formatted by GTP.

11. The present invention provides a cellular data communication system comprising an antenna for receiving signals from user equipment, a packet radio network connected to the antenna, an Internet Protocol network, and a user plane function configured to manage communication with the user equipment. A conversion module is provided that is placed between the packet radio network and the Internet Protocol network. A proxy placed between the conversion module and the antenna receives the first packet destined for the user plane function. The proxy snoops session information from the first packet and forwards the first packet to the user plane function. The proxy invokes the programming of the conversion module according to the session information, The conversion module receives a second packet from the packet wireless network. The conversion module converts the second packet according to the program to obtain a third packet, and then, The third packet is transmitted over the Internet Protocol Network. A method characterized by including the following.

12. The method according to 11, wherein the session information includes information describing a protocol tunnel terminated by the user plane function, and the information describing the protocol tunnel includes any of the following: a tunnel endpoint (TEP) address, a TEP identifier (TEID) of the user plane function, a local TEID of the protocol tunnel, and the address of the user device.

13. The method according to 12, characterized in that the TEP address is the address of the baseband unit between the user plane function and the antenna.

14. The method according to 12, characterized in that the protocol tunnel is a General-Purpose Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel.

15. The method according to 14, characterized in that converting the second packet according to the programming to obtain the third packet includes converting the second packet formatted by GTP to the third packet formatted by the Internet Protocol.

16. The method according to 14, wherein converting the second packet according to the programming to obtain the third packet includes converting the second packet formatted by GTP to the third packet formatted by the Internet Protocol, and the third packet contains sufficient information to convert the third packet to a fourth packet formatted by GTP.

17. Calling the programming of the conversion module according to the session information is: The proxy provides the session information to the routing and software-defined network (routing / SDN) controllers located between the proxy and the conversion module, and The routing / SDN controller programs the conversion module using the session information. The method according to 15, characterized by including the following:

18. The method according to 17, characterized in that the routing / SDN controller includes a Border Gateway Protocol (BGP) module.

19. The above method further, The method according to 17, characterized in that the proxy includes programming routing modules placed between the Internet Protocol Network and an external network in accordance with the session information.

20. The aforementioned conversion module is a first conversion module, The above method further, A second conversion module is provided between the Internet Protocol Network and the user plane function. The proxy invokes the programming of the second translation module according to the session information, the second translation module is programmed to translate the third packet into a fourth packet, and the fourth packet is formatted by GTP. The method according to the previous version, characterized by including the following:

Images