Use of IP networks for routing cellular data packets

Abstract

The cellular data communication network includes a gNodeB connected to the UPF by an IP network. A first translation module translates the GTP packets into IP packets sent over the IP network. A second translation module retranslates the IP packets into GTP packets and forwards the GTP packets to the UPF. A PFCP proxy snoops information and provides the snooped information to a BGP module, which programs the first and second translation modules and the routing module to perform routing of packets that bypass the UPF. The BGP module can program the first translation module with an SR policy associated with a binding SID that is bound to an interface to the gNodeB. The SR policy can invoke the translation according to a function. The routing module can be programmed to embed the GTP information in the SRH header used by the first translation module. The BGP module can also distribute routing and VPN updates.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application is a continuation - in - part of U.S. Patent Application No. 17 / 240,726, filed on April 26, 2021, and also a continuation - in - part of U.S. Patent Application No. 17 / 362,071, filed on June 29, 2021, which is hereby incorporated by reference in its entirety.

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

Background Art

[0003] 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 receives the packets by a radio antenna and performs the function of 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 transferred 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 transfer the 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 to access a wider network such as the Internet or provide a service that the packets are to handle.

[0004] 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]

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

[0006] To solve the above problems, the present invention provides a method described in the claims of this patent application.

[0007] 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]

[0008] [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 7A] This is a schematic diagram showing the propagation of external routing information to a conversion module according to an embodiment of the present invention. [Figure 7B] This is a schematic diagram showing the programming of a conversion module for routing packets to an external network according to an embodiment of the present invention. [Figure 7C] This is a schematic diagram showing the programming of a routing module for routing packets to an external network according to an embodiment of the present invention. [Figure 7D] This is a schematic diagram showing the programming of a conversion module for routing packets to an external network according to an embodiment of the present invention. [Figure 8] This is a schematic diagram showing the configuration of a conversion module according to an embodiment of the present invention. [Figure 9A]This is a schematic diagram showing the conversion from GTP to SRv6 according to an embodiment of the present invention. [Figure 9B] This is a schematic diagram further illustrating the operation of the conversion module according to an embodiment of the present invention. [Figure 9C] This is a schematic diagram showing the conversion from SRv6 to GTP according to an embodiment of the present invention. [Figure 10] 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]

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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).

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

[0014] These computer program instructions can also be stored in a non-transitory computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a specific manner, such that the product includes instruction means for implementing the functions / operations specified in one or more blocks of the flowchart and / or block diagram.

[0015] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus and cause a series of operational steps to be executed on the computer or other programmable data processing apparatus, so that the instructions executed on the computer or other programmable data processing apparatus provide a process for implementing the functions / operations specified in one or more blocks of the flowchart and / or block diagram, and a computer-implemented process is generated.

[0016] Referring to FIG. 2, in some embodiments, when packets from UE 102 are received by gNodeB 106, they are formatted as general packet radio service (GPRS) packets. gNodeB 106 can control the functions of the RU (radio unit, i.e., antenna), DU (distributed unit), and CU (centralized unit), and manage the transfer of packets between UE 102 and network 110. gNodeB 106 then encapsulates these packets within GPRS tunneling protocol (GTP) packets and then transfers them to UPF 112. Path 204 indicates the path of packets sent to UPF 112 and sent from UPF 112. Path 206 indicates the path of redirected packets sent to different MEC servers 118 as shown in FIG. 1B, sent from MEC servers 118, or sent to other destinations and sent from other destinations.

[0017] The packet output by gNodeB 106 can be processed by conversion module 208. In the illustrated embodiment, conversion module 208 mutually converts between GTP and the Internet protocol, i.e., a protocol not suitable for use within the cellular data network other than GTP. In the illustrated embodiment, the Internet protocol is SRv6 (segment routing on the IPv6 data plane). In the following description, references to the transition between GTP and SRv6 can be understood to be replaced with the transition between GTP and other Internet protocols.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] Some of the routes 204 and 206 labeled as "B" can carry packets formatted as Internet Protocol packets, such as SRv6 packets (hereinafter referred to as "Type B packets"). Such packets may include Internet routing headers such as the internal IP header, segment routing header (SRH'), and IPv6 header as defined above. The SRH' of each Type B packet may be added by the translation modules 208 and 212 that generated the Type B packets to include information from some or all of the GTP header, UDP header, and external IP header of the Type A packets that were converted into Type B packets. In particular, the information stored in the SRH' may contain enough data for the other translation modules 208 and 212 to convert the Type B packets into Type A packets (GTP packets). The IPv6 field may be a packet formatted by an Internet Protocol (IP), such as IPv6, and may contain enough information to route the packet on an IP network such as network 210, including the source IP address, destination IP address, and data for other fields defined by IPv6 or other Internet Protocols. This information can be obtained from the external IP header of the A-type packet, which is converted to obtain a B-type packet. The IPv6 packet may also contain payload data from the A-type packet.

[0022] Some of the routes 204 and 206, labeled as "C", contain the same field definitions as Type B packets, but the SRH does not store information from the GTP header of the Type A packet, and / or can transmit Type C packets formatted as Internet Protocol packets that are not subsequently converted into Type B packets using the information in the SRH fields. As illustrated in Figure 2, packets sent from MEC server 118 to UE 102 pass through network 210 as Type B packets, while packets sent from UE 102 to MEC server 118 can pass through network 210 as Type C packets.

[0023] Some of the routes 204 and 206, labeled as "D", can carry D-type packets formatted as Internet Protocol packets, including the internal IP header and payload data of the C-type packets that are converted to obtain D-type packets. In particular, D-type packets may include IP packets sent from UE102, MEC servers 116 and 118, or the external network 214 and received by gNodeB106.

[0024] A "direct inbound packet" is a packet that passes through gNodeB106 without being redirected, and moves from left to right along path 204 in Figure 2. Direct inbound packets are sent from UE102 to gNodeB106. Upon receipt by gNodeB106, direct inbound packets can be Type D packets such as IPv4 or IPv6. Upon output by gNodeB106, direct inbound packets can be Type A packets sent by gNodeB106 to the translation module 208. In particular, Type A packets can be GTP packets that encapsulate the IP packets received from UE102.

[0025] The conversion module 208 converts a Type A direct inbound packet into a Type B packet and uses the information contained in the external IP header of the Type A direct inbound packet to send the Type B direct inbound packet to UPF112 on network 210. As described above, information from the GTP field of the Type A packet is included in the SRH' field of the Type B packet obtained from the Type A packet, enabling re-conversion to a Type A packet. However, the Type B packet itself can be an SRv6 packet rather than a GTP packet. The Type B packet further includes the internal IP header and payload data from the Type A packet.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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).

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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 with 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

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

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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 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 to the routing / SDN controller 324.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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)

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] Referring to Figures 7A to 8, the translation module 208 manages the translation of packets from SRv6 to GTP. In a typical 5G network, GTP packets are received by UPF112 from gNodeB106, internal IP packets are obtained from the GTP packets by UPF112, and the internal IP packets are then processed by the SRv6 component, which manages the routing of internal IP packets by SRv6, including using routing by virtual routing function (VRF). The SRv6 component is the target of inbound packets destined for UE102, manages routing by SRv6, and forwards the packets received by UPF112 to be encapsulated in GTP packets and forwarded to gNodeB106.

[0084] In the approach described herein, packets are routed to and from the translation module 208 on the SRv6 network 210 and the external network 214. Therefore, the translation module 208 can also manage packet routing by SRv6, including managing the VRF.

[0085] The approach described here refers to SRv6. However, it can also be implemented using labels via Multiprotocol Label Switching (MPLS).

[0086] In particular, referring to Figure 7A, the routing module 216 may function as a route reflector client 700, such as a BGP route reflector client, or may include a route reflector client 700. The BGP module 324 (also referred here to as the routing / SDN controller 324) may function as a route reflector and receive routing information broadcast by the route reflector client 700. The BGP module 324 may then reflect this routing information to the translation module 208 by performing standard route reflector functions, etc. In some embodiments, the routing module 216 sends VPNv4 / v6 updates for external routes, i.e., routes to external IP addresses within the external network 214, to the BGP module 324. The BGP module 324, acting as a route reflector with the routing module 216 as its client, reflects the VPNv4 / v6 updates from the routing module 216 to the translation module 208. Based on this, the conversion module 208 can obtain a route to the external network 214 via the routing module 216.

[0087] For example, routing module 216 can update routes such as VPNv4 / v6 routes using a service SID. A route can describe routing to the external network 214, and a service SID can instruct the execution of a segment, including performing VPNv4 / v6 functionality, for packets labeled by the service SID. A route provides an SR policy that designates routing module 216 as the next hop for one or more addresses in the external network 214, or instructs the addition of a prefix SID to packets containing one or more addresses, and the prefix SID refers to a segment that instructs routing packets to routing module 216. Therefore, when this route is provided to translation module 208, it becomes possible to receive GTP packets (Type A packets in Figure 7A) and decapsulate internal IP packets.

[0088] The translation module 208 obtains the destination IP address of the internal IP packet and performs a route determination specifying that the packet destined for the destination IP address should be forwarded to the routing module 216. Subsequently, the translation module 208 forwards the internal IP packet as an SRv6 packet (Type C packet in Figure 7A) containing the SID specified by the route (for example, the prefix SID of the routing module 216). The Type C packet can be forwarded to the routing module 216 on the network 210, which can be realized as a Level 3 (L3) VPN including SRv6 in the embodiments shown in Figures 7A to 7D.

[0089] The routing module 216 receives a Type C packet, decapsulates the internal IP packet (Type D packet in Figure 7A), and forwards the internal IP packet to the destination IP address on the external network 214.

[0090] In some embodiments, the BGP module 324 may also instruct the translation module 208 to perform a VPN service associated with the service SID of the VPN (VPNv4 / v6).

[0091] Figure 7B illustrates an approach using BGP module 324 and translation module 208 to manage the routing of traffic from UE102 to UPF112 via translation module 212. For example, 5G defines GTP-U messages. GTP-U messages can be used to check and / or detect data path information between gNodeB106 and UPF112. Other GTP-U messages include echo requests and echo replies to detect whether this data path is good. GTP-U messages can also be used to communicate error indications in response to errors on the data path. GTP-U messages can include termination markers to indicate the end of data packet forwarding (e.g., when a handover occurs). For user data traffic destined for the external network 214, translation module 208 can remove the GTP header, encapsulate the internal IP packets of the SRv6 packets (Type C packets), and then forward the Type C packets directly to translation module 212.

[0092] Similar to other embodiments described herein, the BGP module 324 obtains information from the PFCP proxy 322 and / or the CLI controller 708. The information relevant to the functionality in Figure 7B may include the remote tunnel endpoint address of the GTP tunnel, the VRF ID (or route distinguisher RD), and VPN information (VPNv4 / v6 information).

[0093] To enable processing of GTP-U messages by UPF112 and / or gNodeB106, the translation module 208 can forward GTP-U messages to UPF112. As described above, this may involve the use of a second translation module 212 between network 210 and UPF112. The translation module 212 can translate packets from SRv6 to GTP before forwarding the GTP packets to UPF112. For this purpose, GTP information can be embedded in the SRH field of the SRv6 packets forwarded to the translation module 212, for example, a Type B packet.

[0094] Therefore, BGP module 324 can provide VPNv4 / v6 updates to translation module 208 and provide routes to UPF112. BGP module 324 can also provide translation module 208 with an SR policy instructing it to translate GTP packets destined for UPF112, which includes encoding GTP information in the SRH field as described above. The VPNv4 / v6 updates and GTP information are obtained by BGP module 324 from information received from PFCP proxy 322 as described above. Programming 710 may include providing translation module 208 with VPNv4 / v6 updates including a route to UPF112. Programming 710 may include programming translation module 208 with this route in a particular VRF. Based on this programming 710, translation module 208 can route packets from gNodeB106 to UPF112.

[0095] The programming 710 provided to UPF112 by the conversion module 208 can further manage routing based on the VRF routing identifier (RD) connected to gNodeB106 and the 5G network instance (access) to which gNodeB106 belongs. The CLI controller 708 can provide mappings between the first VRF RD connected to gNodeB106 and the 5G network instance (access) to which gNodeB106 belongs, as well as between the first VRF RD and the second VRF RD of the destination IP address of internal IP packets (internal IP packets encapsulated by GTP packets). The PFCP proxy 322 can provide the addresses of the 5G network instance (access) to which gNodeB106 belongs and UPF112.

[0096] Using this information, BGP module 324 determines which VRF RD matches the 5G network instance (access, i.e., the network including UPF112) provided by PFCP proxy 322. BGP module 324 performs the following actions: It sends a VPNv4 / v6 update to the translation module 208 for the route to UPF112 of the first VRF RD that matches the 5G network instance (access). It then sends an SR policy and a second VRF RD related to the destination address of the internal IP packet, informing the translation module 208 of the above translation rule (which specifies the translation from GTP to SRv6 based on embedded GTP information).

[0097] The SR policy and VPNv4 / v6 can be programmed to perform the following functions: • Receives a GTP packet whose destination address is a UPF112 address. • Check the packet type of the GTP packet. If the packet type of the GTP packet is user data traffic, the GTP header is removed to obtain the internal IP packet, and the internal IP packet is forwarded using the routing table of the VRF RD provided by the BGP module 324 (for example, performing standard L3VPN SRv6 forwarding). If a GTP packet is a GTP-U message, the BGP controller performs a translation from GTP to SRv6 based on the translation rules provided by the BGP controller (e.g., GTP4 / 6D rules) (e.g., translation to a B-type packet based on GTP information embedded in the SRH' field).

[0098] In some embodiments, VPNv4 / v6 updates of UPF addresses have a linked SID as a prefix SID. Thus, VPNv4 / v6 updates are associated with a specific SR policy, i.e., an SR policy received from BGP module 324. The SR policy received from BGP module 324 may include the same linked SID and may also include the VRF RD of the internal IP packet. Based on this, when translation module 208 receives a GTP packet whose destination matches a UPF address, translation module 208 can apply the SR policy to the GTP packet.

[0099] In some embodiments, the SR policy may instruct translation module 208 to evaluate whether the destination address of an internal IP packet is an IPv6 link-local address. In that case, translation module 208 can perform the same translation from GTP to SRv6 by the SR policy as described above and then forward it to translation module 212. However, since link-local addresses are not globally routable, only UPF112 can process such packets. Therefore, translation module 208 needs to send the translated SRv6 packet to UPF112. For each GTP packet, the SR policy instructs translation module 208 to check whether the destination address of the internal IP packet is a link-local address, and if so, translate the GTP packet into an SRv6 packet, embedding GTP-related information in the SRH field of the SRv6 packet, and then forward the SRv6 packet to translation module 212. Translation module 212 then translates the SRv6 packet back into a GTP packet using the embedded information and forwards the GTP packet to UPF112.

[0100] Based on the VPNv4 / v6 update provided by BGP module 324, the translation module can be programmed with routing entries for UPF addresses in the routing table associated with the first VRF RD (the external VRF of the network connected to gNodeB106). The SR policy provided in step 712 can associate the second VRF RD (the internal VRF of the network connected to UPF112) with the associated SID. The associated SID can invoke the application of the SR policy for internal IP packets destined for the second VRF RD and UPF addresses. The associated SID can be used as a service SID for VPNv4 / v6 updates of UPF addresses. The associated SID can also be carried within the SR policy. The SR policy can carry the internal VRF RD used for routing internal IP packets. Therefore, according to this programming, GTP packets received from gNodeB106 can be processed by translation module 208 as follows. • Perform a routing lookup based on the destination address (UPF address) in the routing table associated with the VRF RD associated with the input interface that received the GTP packet. Obtain the SR policy based on the associated SID used as the service SID for VPNv4 / v6 updates of the UPF address. • Check the message type. If the message type is G-PDU, the translation module 208 removes the GTP header to obtain the internal IP packet, encapsulates the internal IP packet within the SRv6 packet, and routes the SRv6 packet by standard SRv6 L3VPN using the second VRF RD (internal VRF for the destination IP address of the internal IP packet) specified by the SR policy. If the message type is GTP-U, the translation module 208 generates a specific service SID that carries GTP-related information such as the UPF address, QFI, TEID, and SRv6 locator according to the SR policy, encapsulates the internal IP packet of the GTP packet within an SRv6 packet containing the specific service SID, and sends the SRv6 packet to the translation module 212.

[0101] A specific service SID can be formatted as [Destination SRv6 Locator][UPF Address + QFI + TEID], using GTP4.D. When GTP6.D is used, a specific service SID can be in the format [Destination SRv6 Locator][QFI + TEID + sid0], where sid0 is the UPF address.

[0102] Figure 7C illustrates the functionality of the BGP module 324 for configuring the routing module 216 to route packets destined for UE102 received from the external network 214. When the routing module 216 receives packets destined for UE102 from the external network 214, the routing module 216 can use the route associated with the address of UE102. This route is provided to the routing module 216 by the BGP module 324 using the approach illustrated in Figure 7C.

[0103] CLI controller 708 can provide mappings between VRF RDs and 5G network instances (cores), such as VRF RDs defined for the network, 714. PFCP proxy 322 can provide 5G network instances (cores), including UE addresses and gNodeB106.

[0104] Based on this information, the BGP module 324 can determine which VRF to import the packet destined for the UE address into, based on the 5G network instance (core) that received the packet. After importing the UE address into the VRF identified by the VRF RD (e.g., a route to the UE address), the BGP module 324 generates a VPNv4 / v6 update and informs the routing module 216 of the route to UE102.

[0105] Upon sending this VPNv4 / v6 update for the UE route, the BGP module 324 can assign a service SID to the UE route. Thus, in response to the VPNv4 / v6 update, the routing module 216 receives an internal IP packet containing the UE address from the external network 214. In response to receiving the internal IP packet containing the UE address, the routing module 216 encapsulates the internal IP packet in an SRv6 packet containing this service SID as the destination, as instructed by the VPNv4 / v6 update. This service SID instructs intervening components, including the translation module 208 and gNodeB106, to route the packet to the UE according to the route.

[0106] When the translation module 208 receives an SRv6 packet from network 210, it needs to translate the SRv6 packet into a GTP packet because the GTP packet needs to be forwarded to the UE via gNodeB 106. The service SID is encoded by the BGP module 324 and can carry GTP-related information such as the gNodeB address, TEID, and QFI.

[0107] An IPv6 address is 128 bits long. Therefore, in the case of GTP4.E (where the gNodeB address is IPv4), all GTP-related information can be embedded within a single IPv6 address: SRv6 locator + gNodeB IPv4 address + QFI + TEID. The maximum length of an SRv6 locator is 56 bits, and the gNodeB address is a 32-bit IPv4 address, leaving 8 bits for QFI and 32 bits for TEID. In the case of GTP6.E where gNodeB106 has an IPv6 address, it is not possible to embed the address of gNodeB106 along with the GTP information within a single IPv6 address. In this case, SRv6 can carry multiple segments (IPv6 addresses) within the SRH. Therefore, the last SID (SID[0]) within the SRH can be the IPv6 address of gNodeB106, and the second SID can carry the SRv6 locator, QFI, and TEID.

[0108] Figure 7D illustrates the functionality of the BGP module 324 for configuring the translation module 208 to route packets destined for the UE received from the external network 214. These packets can then be received by the routing module 216 on network 210 via the translation module 208. The BGP module 324 can further configure the translation module 208 to translate such packets from SRv6 to GTP.

[0109] The BGP module 324 can receive information from the CLI controller 708, such as an SRv6 locator for GTP4 / 6.E and external VRFs connected to the gNodeB of each VRF from which UE addresses are imported.

[0110] BGP module 324 can provide an SRv6 locator that identifies the functions applied by translation module 208, such as the GTP4 / 6.E or GTP4.D functions that perform the above translation. The SRv6 locator and the corresponding translation function can be provided to translation modules 208 and 212 by BGP module 324. This SRv6 locator can be included in the above service SID. BGP module 324 generates an SR policy and sends it to translation module 208. The SR policy contains various instructions.

[0111] The SR policy can indicate SRv6 locator information (e.g., whether the locator information format is based on an IPv6 prefix). Thus, the SR policy enables the translation module 208 to understand the location of the gNodeB address, QFI, and TEID embedded in the service SID contained within the SRH field (e.g., whether these items of information reside in SID[0] or SID[1]), as described above with respect to Figure 7C. The SR policy can also carry functions such as GTP4.E or GTP6.E functionality, which instructs the translation module 208 to discover the gNodeB address using the last segment of the SRH header and perform SRv6 to GTP translation using the embedded GTP information. The SR policy generated by the BGP module 324 can further provide an external VRF of the UE address used to route the GTP packet to UE102 after the GTP packet is obtained by the SR policy's translation from SRv6 packet to GTP packet.

[0112] Figure 8 illustrates an exemplary configuration of the translation module 208. The translation module 212 may have a similar configuration. In the illustrated embodiment, packets received from gNodeB 106 and transmitted to UPF 112 (e.g., GTP-U messages) can be processed by a first forwarding information base (FIB) lookup module 800, a GTP4 / 6.D processing module 802, an SRv6 encapsulation module 804, and a second FIB lookup module 806. Packets received from gNodeB 106 and transmitted to the routing module 216 (e.g., non-GTP-U messages) can be processed by a first FIB lookup module 800, a GTP4 / 6.D processing module 802, a third FIB lookup module 808, an SRv6 encapsulation module 810, and a fourth FIB lookup module 812.

[0113] The first FIB lookup module 800 can evaluate the interface (IP address and VRF RD) that received the packet. If that interface is associated with an associated SID, the associated SID and the associated SR policy then call the GTP4 / 6.D module 802 to process the packet. The programming of the first FIB lookup module 800, the generation of the associated SID and SR policy, and the programming of the GTP4 / 6.D module 802 can be performed by the BGP module 324 as described above.

[0114] The GTP4 / 6.D module 802 can be programmed by a function invoked by the SR policy. This function can evaluate the packet type of a GTP packet. If the packet is a GTP-U message, the packet is sent to the SRv6 encapsulation module 804. The SRv6 encapsulation module 804 can be programmed to convert a GTP packet (Type A) into an SRv6 packet (Type B) with embedded GTP information. Further details regarding the execution of this encapsulation are described below with reference to Figure 9A. The SRv6 packet generated by the SRv6 encapsulation module 804 can be processed by a second FIB lookup module 806. The second FIB lookup module 806 can evaluate the destination address of the SRv6 packet (i.e., the GTP / SRv6 212 address before UPF112) and determine where to route the SRv6 packet. This may involve using information from VPNv4 / v6 updates to determine the next hop, VPN tunnel information, VRF RD, or other information used to route SRv6 packets to UPF112. As mentioned above, VPNv4 / v6 updates can be received from BGP module 324. The translation module 208 then transmits SRv6 packets with routing information obtained from the second FIB lookup module 806.

[0115] If the GTP4 / 6.D module 802 determines that the GTP packet is not a GTP-U message, the GTP packet can be processed by a third FIB lookup module 808 after the GTP / UDP / external IP header has been removed. The third FIB lookup module 808 can look up information to encapsulate the internal IP packet of the GTP packet within the SRv6 packet. This means, for example, looking up VPNv4 / v6 routes related to the destination address of the internal IP packet and determining that such a SID encapsulates the internal IP packet within the SRv6 packet. The SID can be generated from routing information received from the BGP module 324 and can define the routing of the SRv6 packet containing the internal IP packet through network 210. The internal IP packet and SID can be provided to the SRv6 encapsulation module 810, which can encapsulate the internal IP packet and SID in the SRv6 packet. The SRv6 packet can be processed by a fourth FIB lookup module 812.

[0116] The fourth FIB lookup module 812 can evaluate the destination address of the SRv6 packet (i.e., the address of routing module 216) and determine where to route the SRv6 packet. This may involve using information from VPNv4 / v6 updates to determine the next hop, VPN tunnel information, VRF RD, or other information used to route the SRv6 packet to routing module 216 to reach an external address. As mentioned above, VPNv4 / v6 updates can be received from BGP module 324. Subsequently, translation module 208 transmits the SRv6 packet using the routing information obtained from the fourth FIB lookup module 812.

[0117] Figure 9A illustrates the process by which the translation module 208 translates a GTP(Type A) packet received into an SRv6(Type B) packet containing embedded GTP information. As described above, a Type A packet may include an internal IP packet (e.g., a destination address in the external network), a GTP header, and an external IP header (e.g., a destination address in UPF112). In the case of GTP4.D, a single SID (SID[0] or the first SID in the SRH' field) includes the GTP4.D locator described above, an external IP address (the address in UPF112), and GTP information such as QFI, TEID, and sequence IDs used for some GTP-U messages (e.g., GTP-U echo request / response messages). In some embodiments, additional padding bits may be included. QFI information may include QFI, R, and U values. QFI is a QoS (Quality of Service) flow identifier as defined in 3GPP. R is a Reflective QoS Indication (RQI) as defined in 3GPP. The U bit is used to specify the PDU (Protocol Data Unit) type of the GTP-U packet. For GTP6.D, two SIDs (SID[0] and SID[1]) can be used. SID[0] may contain an external IP address (UPF112 address), and SID[1] may contain embedded GTP information such as QFI, TEID, and sequence ID.

[0118] Figure 9B illustrates the function of the translation module 208 when processing an SRv6(Type B) packet containing embedded GTP information received from the routing module 216. The FIB lookup module 812 receives the packet and determines the associated SID associated with the interface (source address and VRF RD) on which the packet was received. The SR policy associated with the associated SID can call the GTP4 / 6.E module 814. The GTP4 / 6.E module 814 can use the embedded GTP information to translate the SRv6 packet into a GTP(Type A) packet. As with the associated SID and SR policy, the programming of the GTP4 / 6.E module can be received from the BGP module 324, as described above.

[0119] GTP packets can be processed by the FIB lookup module 800, which determines the VRF RD associated with the destination address (e.g., gNodeB106 address or UPF address) and routes the GTP packets according to the routing table of that VRF RD. The routing performed by the FIB lookup module 800 can be performed by VPNv4 / v6 updates received from the BGP module 324, as described above. Figure 9B illustrates a packet flow for downlink (from external network 214 to UE102 or from UPF112 to UE102). In such a packet flow, the FIB lookup module 812 can be programmed to determine a routing entry destined for the GTP4 / 6.E module 814. The GTP4 / 6.E module 814 can then convert each SRv6 packet into a GTP packet. This GTP packet can then be routed to the FIB lookup module 800.

[0120] Figure 9C illustrates the conversion from a Type B packet to a Type A packet. The embedded information in the SRH' field is obtained. As mentioned above, in the case of GTP4.E, this information is contained in SID[0]. In the case of GTP6.E, this information is contained in SID[1]. The GTP4.E locator in the SRH' field relates to the GTP4.E function that performs the conversion using the external IPv4 destination address and embedded GTP information (QFI, TEID / sequence ID). The conversion involves using the external IPv4 destination address (e.g., the address of gNodeB) as the external IP destination address of the Type A packet and may include the GTP information embedded in the GTP field of the Type A packet. The internal IP packet is forwarded to the address of UE102.

[0121] Figures 8, 9A, 9B, and 9C describe the translation module 208. Similarly, the translation module 212 can perform the translation from Type A packets to Type B packets and function in a similar manner. In particular, packets traveling from UPF112 to gNodeB106 can be translated in the same manner as packets traveling from gNodeB106 to UPF112. Packets traveling from SRv6 216 to UE102 can be processed in the same manner as packets traveling from UPF112 to gNodeB106. In other words, the translation from SRv6 to GTP is performed by translation modules 208 and 212 when a packet is received from network 210, regardless of the entity sending the packet (either the other translation modules 208, 212, or routing module 216).

[0122] Figure 10 is a diagram illustrating an exemplary computing device 1000 that can be used to implement the methods and systems disclosed herein. The computing device 1000 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 1000 can be any computing device of any kind, such as a desktop computer, a laptop computer, a server computer, a portable computer, or a tablet.

[0123] The computing device 1000 includes one or more processors 1002, one or more memory devices 1004, one or more interfaces 1006, one or more mass storage devices 1008, one or more input / output (I / O) devices 1010, and a display device 1030, all of which are connected to the bus 1012. The processor 1002 includes one or more processors or control devices and executes instructions stored in the memory devices 1004 and / or mass storage devices 1008. The processor 1002 may also include various types of computer-readable media such as cache memory.

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

[0125] The mass storage device 1008 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 10, a specific mass storage device is a hard disk drive 1024. Various drives may also be included within the mass storage device 1008 to enable reading from and / or writing to various computer-readable media. The mass storage device 1008 includes removable media 1026 and / or non-removable media.

[0126] The input / output device 1010 includes various devices that enable inputting data and / or other information to or from the computing device 1000. Exemplary input / output devices 1010 include a cursor control device, a keyboard, a keypad, a microphone, a monitor or other display device, a speaker, a printer, a network interface card, a modem, a lens, a CCD or other imaging device, and the like.

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

[0128] Interface 1006 includes various interfaces that enable the computing device 1000 to exchange information with other systems, devices, or computing environments. An exemplary interface 1006 includes any number of different network interfaces 1020, 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 1018 and a peripheral device interface 1022. Interface 1006 may also include one or more user interface elements 1018. Interface 1006 may also include one or more peripheral device interfaces, such as interfaces to a printer, pointing device (mouse, trackpad, etc.), and keyboard.

[0129] Bus 1012 enables the processor 1002, memory device 1004, interface 1006, mass storage device 1008, and input / output device 1010 to communicate with each other, as well as with other devices or components connected to bus 1012. Bus 1012 represents one or more types of bus structures, such as a system bus, PCI bus, IEEE1394 bus, or USB bus.

[0130] 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 computing device 1000 and are executed by processor 1002. 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]

[0131] 100 Network Environment Route 204 206 routes 514 Message 516 Message 518 PFCP response 520 PFCP response 1000 computing devices 1012 Bus

Claims

1. A device including a network device which includes a processing unit programmed to implement a conversion module, The aforementioned conversion module is A first packet is received, formatted by a packet radio protocol and containing an Internet Protocol (IP) packet, and the first packet is destined for a User Plane Function (UPF) module. Evaluate the type of the first packet, If the first packet type is of type 1, the IP packet is encapsulated in a second packet formatted by the Internet Protocol, the routing instruction in the second packet contains first embedded data and instructs the routing of the second packet to the UPF module, the first embedded data is sufficient to generate a third packet encapsulating the IP packet, and the third packet is formatted by the Packet Radio Protocol. If the first packet type is of the second type, the IP packet is formatted by the Internet Protocol and encapsulated in a fourth packet that does not contain the first embedded data, and the routing command of the fourth packet commands the routing of the fourth packet to bypass the UPF module. The aforementioned packet radio protocol is the General-Purpose Packet Radio Service (GPRS) Tunneling Protocol (GTP), The first type is a GTP user plane (GTP-U) message, and the second type is not a GTP-U message. A device characterized by being configured in such a way.

2. The apparatus according to claim 1, wherein the second packet is further formatted by segment routing on the Internet Protocol.

3. The apparatus according to claim 2, characterized in that the routing instruction of the second packet is the segment identifier (SID) of the second packet.

4. The aforementioned conversion module is a first conversion module, and the first conversion module further, The apparatus according to claim 3, characterized in that it is programmed to transmit the second packet to the UPF module via a second conversion module located remotely from the first conversion module and connected to the first conversion module by an Internet Protocol (IP) network.

5. The apparatus according to claim 4, characterized in that the first conversion module is programmed according to a segment routing (SR) policy.

6. The apparatus according to claim 5, characterized in that the SR policy is implemented by GTP4.D and the routing instruction is SID[0] of the second packet.

7. The apparatus according to claim 6, characterized in that the first embedded data includes a GTP4.D locator, the IP destination address of the first packet, a Quality of Service Flow Identifier (QFI), and a Tunnel Destination Identifier (TEID) for a GTP tunnel connecting the gNodeB module and the UPF module.

8. The apparatus according to claim 5, characterized in that the SR policy is implemented by GTP4.E and the routing instruction includes GTP information in SID[0].

9. The apparatus according to claim 5, wherein the SR policy is implemented by GTP6.D, and the routing instruction includes SID[0] and SID[1] of the second packet.

10. The apparatus according to claim 9, wherein the first embedded data contained in SID[0] includes the IP destination address of the first packet, and the first embedded data in SID[1] includes a GTP6.D locator, a Quality of Service Flow Identifier (QFI), and a Tunnel Destination Identifier (TEID) for a GTP tunnel connecting the gNodeB module and the UPF module.

11. The apparatus according to claim 5, characterized in that the SR policy is implemented by GTP6.E, and the routing instructions include GTP information in SID[0] and SID[1].

12. The aforementioned conversion module further, Upon receiving a fifth packet formatted by the Internet Protocol, The second embedded data is extracted from the fifth packet, The second embedded data is used to convert the fifth packet into a sixth packet, and the sixth packet is formatted according to the packet radio protocol. The sixth packet is sent to the destination address of the fifth packet. The apparatus according to claim 1, characterized in that it is programmed in such a way.

13. The aforementioned conversion module is Determine the associated segment identifier (SID) associated with the interface on which the fifth packet was received, and then, A segment routing (SR) policy associated with the associated SID is applied, and the SR policy specifies the conversion of the fifth packet to the sixth packet. The apparatus according to claim 12, characterized in that it is programmed in such a way.

14. The apparatus according to claim 13, characterized in that the aforementioned SR policy is implemented by either GTP4.D or GTP4.E.

15. The apparatus according to 12, wherein the second embedded data is contained within the segment identifier (SID)[0] of the fifth packet and includes the address of the gNodeB module, the quality of service flow identifier (QFI), and the tunnel endpoint identifier (TEID).

16. The apparatus according to claim 12, wherein the second embedded data is contained within the segment identifier (SID)[0] and SID[1] of the fifth packet, and includes the address of the gNodeB module contained within SID[0], the quality of service flow identifier (QFI) and the tunnel endpoint identifier (TEID) contained within SID[1].

Images