Optional import of WE addresses from 5G networks to VRF

Abstract

Importing a UE address into a peripheral device's VRF is possible by receiving a VPN update from the peripheral device that includes the peripheral device's root target and gNodeB address. Additionally, session information is obtained by intercepting traffic between the UE address and the UPF. The session information includes the UE address and the address of the gNodeB to which the UE is connected. By matching the gNodeB addresses from the VPN update with the session information, the root target of the peripheral device to which the UE is connected can be determined. Then, the UE address can be exclusively imported into the peripheral device's VRF.

Description

Technology Field

[0001] Related applications

[0002] This application is a partial continuation of U.S. patent application serial number 17 / 488,833 filed on September 29, 2021, which is a partial continuation of U.S. patent application serial number 17 / 362,071 filed on June 29, 2021, and a partial continuation of U.S. patent application serial number 17 / 240,726 filed on April 26, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0003] Field of invention

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

[0005] Referring to FIG. 1a, in a conventional 5G cellular data communication network (100), user equipment (UE) (102) can receive packets through a radio antenna and transmit packets from a gNodeB (106) that performs functions of transmitting them 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, a UPF (112) associated with the GW (108) that initially received the packets. The UPF (112) can receive packets through a network (110), which may be an Internet Protocol (IP) network (110) between the UPF and the GW (108). The UPF (112) can forward packets to a mobile edge computing (MEC) server (116) through another IP network (114). The MEC server (116) may be a destination for the packets, for example, a server providing a service addressed by the packets, or a gateway for accessing a wider network such as the internet.

[0006] Referring to FIG. 1b, in some cases, packets may need to be redirected from an MEC server (116) associated with a UPF (112) to another MEC server (118). For example, the GW (108) may also be connected to one or more IP networks (120) coupling the MEC server (118) and the GW (108). In the event of failure of the MEC server (116), or for redirection for some other purposes, packets may be redirected to the MEC server (118). However, modern 5G protocols require that packets be routed to the UPF (112) first, which will then forward the packets to the MEC server (118) as shown in FIG. 1b. Traffic from the MEC server (118) to the UE (102) may follow the reverse path. This increases the latency of packets transmitted to and from the UE (102).

[0007] Providing an improved approach to handling packet redirection in cellular communication networks would be an advancement in this technical field. Brief explanation of the drawing

[0008] To ensure that the advantages of the present invention are easily understood, a more specific description of the invention, as briefly described above, will be provided with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings illustrate only typical embodiments of the invention and are not to be construed as limiting the scope, and that the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings. FIG. 1a is a schematic block diagram illustrating the routing of packets received through a cellular data communication network according to the prior art. FIG. 1b is a schematic block diagram illustrating the rerouting of packets received through a cellular data communication network according to the prior art. FIG. 2 is a schematic block diagram illustrating an approach for routing packets received through a cellular data communication network according to an embodiment of the present invention. FIG. 3 is a schematic block diagram of components for performing routing of packets received through a cellular data communication network according to an embodiment of the present invention. FIG. 4 is a schematic block diagram illustrating the snooping of information by a PFCP proxy and the programming of a transformation and routing module using this information according to an embodiment of the present invention. FIG. 5 is a schematic block diagram of a PFCP proxy according to one embodiment of the present invention. FIG. 6 is a schematic block diagram illustrating information exchange between a PFCP proxy and a routing / SDN controller according to an embodiment of the present invention. FIG. 7a is a schematic block diagram illustrating the propagation of external routing information to a translation module according to an embodiment of the present invention. FIG. 7b is a schematic block diagram illustrating the programming of a conversion module for routing packets to an external network according to an embodiment of the present invention. FIG. 7c is a schematic block diagram illustrating the programming of a routing module for routing packets to an external network according to an embodiment of the present invention. FIG. 7d is a schematic block diagram illustrating the programming of a conversion module for routing packets to an external network according to one embodiment of the present invention. FIG. 8 is a block diagram schematically showing the configuration of a conversion module according to one embodiment of the present invention. FIG. 9a is a schematic block diagram illustrating the conversion from GTP to SRv6 according to one embodiment of the present invention. FIG. 9b is a schematic block diagram further illustrating the operation of a conversion module according to one embodiment of the present invention. FIG. 9c is a schematic block diagram illustrating the conversion from SRv6 to GTP according to one embodiment of the present invention. FIG. 10a is a schematic block diagram of a load balancing PFCP proxy according to one embodiment of the present invention. FIG. 10b is a process flowchart of a method for performing load balancing of a PFCP session according to an embodiment of the present invention. FIG. 11 is a schematic block diagram illustrating the non-selective distribution of routing information according to one embodiment of the present invention. FIG. 12a is a schematic block diagram of a network environment for performing selective distribution of routing information according to an embodiment of the present invention. FIG. 12b illustrates an exemplary relationship between entities within a network and various labels and addresses used. FIG. 13 is a process flowchart of a method for selective distribution of routing information according to an embodiment of the present invention. FIG. 14 is a schematic block diagram of a computer system suitable for implementing methods according to embodiments of the present invention. Specific details for implementing the invention

[0009] It will be readily understood that the components of the invention, as outlined and illustrated in the drawings of this specification, can be arranged and designed in a wide variety of different configurations. Accordingly, the following more detailed description of embodiments of the invention as shown in the drawings is not intended to limit the scope of the claimed invention, but merely illustrates specific examples of embodiments currently being considered according to the invention. The embodiments currently described will be best understood by reference to the drawings, where similar parts are designated by similar numbers throughout.

[0010] Embodiments according to the present invention may be implemented as devices, methods, or computer program products. Accordingly, the present invention may take the form of an embodiment that is entirely hardware-based, entirely software-based (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a "module" or "system." Additionally, the present invention may take the form of a computer program product implemented on any tangible representation medium having computer-usable program code implemented on the medium.

[0011] Any combination of one or more computer-usable or computer-readable media may be used. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. In selected embodiments, a computer-readable medium may include any non-transient medium capable of containing, storing, communicating, propagating, or transmitting a program for use by or in connection with an instruction execution system, device, or device.

[0012] Computer program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages, and may also use technical or markup languages ​​such as HTML, XML, JSON, etc. The program code may be executed entirely as a standalone software package 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 latter scenario, the remote computer may be connected to the computer through any type of network including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer may be made (e.g., via the Internet using an Internet service provider).

[0013] The present invention is described below with reference to flowchart examples and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present invention. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer program instructions or code. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that instructions executed through the processor of the computer or other programmable data processing device create means for implementing specific functions / operations in the blocks of the flowcharts and / or block diagrams.

[0014] These computer program instructions may also be stored in a non-transient computer-readable medium capable of instructing a computer or other programmable data processing device to function in a specific manner, so that the instructions stored in the computer-readable medium produce a manufactured article comprising instruction means for implementing a specific function / operation in a block or in blocks of a flowchart and / or block diagram.

[0015] Computer program instructions can also be loaded onto a computer or other programmable data processing device to create a computer implementation process by causing a series of operational steps to be performed on the computer or other programmable device, so that the instructions executed on the computer or other programmable device provide processes for implementing specific functions / operations in blocks or blocks of a flowchart and / or block diagram.

[0016] Referring to FIG. 2, in some embodiments, packets from the UE (102) are formatted as General Packet Radio Service (GPRS) packets when received by the gNodeB (106). The gNodeB (106) controls the functions of the Radio Unit (RU), Distributed Unit (DU), and Centralized Unit (CU) and can manage the transmission of packets between the UE (102) and the network (110). Then, the gNodeB (106) can encapsulate these packets within GPRS Tunneling Protocol (GTP) packets and then forward them to the UPF (112). Path (204) illustrates the path of packets sent to and from the UPF (112). The path (206) illustrates the path of packets redirected to and from a different MEC server (118), as in FIG. 1b or another destination.

[0017] Packets output by gNodeB (106) can be processed by a translation module (208). In the illustrated embodiment, the translation module (208) converts back and forth between GTP and the Internet Protocol, that is, a protocol that is not suitable for use in a cellular data network and is not GTP. In the illustrated embodiment, the Internet Protocol is SRv6 (segment routing over the IPv6 data plane). In the following description, it will be understood that references to translations between GTP and SRv6 may be replaced with translations between GTP and other Internet Protocols.

[0018] A translation module (208) may be interposed between the gNodeB (106) and the SRv6 network (210), for example, a network having routing implemented according to the data plane and / or SRv6 or other IP protocols. The UPF (112) may be connected to the SRv6 network (210) by another translation module (212). Note that in some embodiments, the translation module (208), the network (210), and the translation module (208) may be part of a common computing device, that is, may be mounted on a common chassis. The common computing device may be placed in the same location as either or both of the antenna (104) and the gNodeB (106). The common computing device may also include an MEC server (116).

[0019] The network (210) may also be coupled to an external network (214), for example, by an Internet Protocol routing module (216). In the illustrated embodiment, the routing module (216) is an SRv6 router, but routers implementing other routing protocols may also be used. In some embodiments, the routing module (216) does not implement the GTP protocol. The external network (214) may be a WAN such as the Internet and may connect the network (210) to another MEC server (118) or any third-party server providing services to the UE (102).

[0020] In the illustrated embodiment, parts of the paths (204, 206) labeled as "A" may carry packets formatted as GTP packets (hereinafter, "A-type packets"). A-type packets may include, in addition to the encapsulated payload data, an internal Internet Protocol (IP) header, a GTP header, a UDP (User Datagram Protocol) header, and some or all of an external IP header. The internal IP header may be an IP header according to an IP protocol generated on the UE (102). The external IP header may be an IP header according to an IP protocol generated by the gNodeB (106) and defining information for routing the A-type packet through the network (210) to a UPF (112), MEC server (116), MEC server (118), or an external network (214), or a different IP protocol.

[0021] Parts of the paths (204, 206) labeled "B" may carry packets formatted as Internet Protocol packets, such as SRv6 packets (hereinafter "B-type packets"). These packets may include Internet routing headers such as the internal IP header, SRH' (segment routing header), and IPv6 header defined above. The SRH' of each B-type packet may be populated by the conversion module (208, 212) that generated the B-type packet to include information from some or all of the GTP header, UDP header, and external IP header of the A-type packet to which the B-type packet was converted. In particular, the information stored in the SRH' may contain sufficient data to convert the B-type packet into an A-type packet (GTP packet) by another of the conversion modules (208, 212). The IPv6 field may be a packet formatted according to an Internet Protocol (IP) such as IPv6, and may contain sufficient information to route the packet through an IP network, such as a network (210), which includes data regarding the source IP address, the destination IP address, and other fields defined by IPv6 or other Internet Protocols. This information may be obtained from the external IP header of an A-type packet from which the B-type packet was obtained. The IPv6 packet may also contain payload data from the A-type packet.

[0022] Parts of the paths (206) labeled "C" may contain the same field definitions as B-type packets, but may transmit "C-type" packets formatted as Internet Protocol packets that are not subsequently converted into B-type packets using information within the SRH fields, and / or information from the GTP header of an A-type packet. As illustrated in FIG. 2, packets sent from the MEC server (118) to the UE (102) may traverse the network (210) as B-type packets, whereas packets sent from the UE (102) to the MEC server (118) traverse the network (210) as C-type packets.

[0023] Parts of the paths (206) labeled "D" can transmit "D-type" packets formatted as Internet Protocol packets containing internal IP header and payload data of a C-type packet obtained as a D-type packet. In particular, the D-type packet may include an IP packet received by gNodeB (106) from a UE (102), from an MEC server (116, 118), or from an external network (214).

[0024] "Direct inbound packets" may be packets that pass through gNodeB (106) without being redirected, such as packets moving from left to right along the path (204) of FIG. 2. Direct inbound packets are transmitted from UE (102) to gNodeB. Direct inbound packets received by gNodeB may be D-type packets, for example, IPv4 or IPv6. Direct inbound packets output by gNodeB (106) may be A-type packets transmitted by gNodeB (106) to the conversion module (208). In particular, A-type packets may be GTP packets that encapsulate IP packets received from UE (102).

[0025] The conversion module (208) converts A-type direct inbound packets into B-type packets and transmits the B-type direct inbound packets to the UPF (112) through the network (210) using information included in the external IP header of the A-type direct inbound packets. As previously described, information from the GTP field of the A-type packet may be included in the SRH' field of the B-type packet obtained therefrom to enable reverse conversion to the A-type packet. However, the B-type packet itself may be an SRv6 packet rather than a GTP packet. The B-type packet further includes payload data and an internal IP header from the A-type packet.

[0026] B-type direct inbound packets can be routed to a conversion module (212), which converts the direct inbound packets back from B-type packets to A-type packets using information stored in the SRH' of the B-type packets. In particular, the data within the SRH' field of the B-type packet is used to generate a GTP header of a GTP packet containing an internal IP field and payload data of the B-type packet, and the GTP packet is an A-type direct inbound packet for the B-type direct inbound packet.

[0027] After conversion by the conversion module (212), A-type direct inbound packets are transmitted to the UPF (112). Then, the UPF (112) decapsulates the direct inbound packets to obtain internal IP packets (e.g., D-type packets received from the UE (102)) and can forward the D-type direct inbound packets to the MEC server (116).

[0028] "Redirected inbound packets" may be packets that originate from the UE (102) as D-type packets and are transmitted through the gNodeB (106), but are redirected away from the MEC server (116), for example, to an external network (214) and / or another MEC server (118) or a third-party server. The redirected inbound packets may traverse the path (206) from the upper left to the lower right of FIG. 2. The redirected inbound packets output by the gNodeB (106) may be A-type packets transmitted by the gNodeB (106) to the conversion module (208). The conversion module (208) converts A-type redirected inbound packets into C-type packets so that the C-type redirected inbound packets do not contain information from the GTP or UDP headers of the A-type redirected inbound packets. The conversion module (208) transmits the C-type redirected inbound packets to the MEC server (118) to which the packets are redirected, for example by the routing module (216). The routing module (216) converts the C-type redirected inbound packets into D-type packets and sends the D-type redirected inbound packets to the MEC server (118). As mentioned above, the conversion may include decapsulating the D-type packets encapsulated in the C-type packets.

[0029] "Direct outbound packets" may be packets that pass through the UPF (112) and are transmitted to the UE (102) via the gNodeB without responding to a redirected inbound packet or a part of the same network flow as the redirected inbound packet. For example, packets from the MEC server (116) may be transmitted through the UPF (112) as direct outbound packets. Direct outbound packets may traverse the path (204) of FIG. 2 from right to left along the path (204). The packets received by the UPF (112) from the MEC server (116) may be D-type packets. Direct outbound packets output by the UPF (112) may be A-type packets that encapsulate D-type packets and are transmitted by the UPF (112) to the conversion module (212). The conversion module (212) converts A-type direct outbound packets into B-type packets and transmits B-type direct outbound packets to gNodeB (106) through the network (210) using information included in the IPv6 field of the B-type packets. The conversion may include converting a GTP packet into an SRv6 packet containing data from the GTP header of the GTP packet within the SRH' field of the SRv6 packet, and the SRv6 packet further includes the internal IP header of the GTP packet and the payload data of the GTP packet.

[0030] B-type direct outbound packets can be routed to a conversion module (208) by a conversion module (212), which converts the B-type direct outbound packets back into A-type direct outbound packets using information stored in the SRH' of the B-type packets. This may include converting an SRv6 packet into a GTP packet that encapsulates the internal IP header and payload data of the B-type packet and includes data from the SRH' field in the GTP header.

[0031] After conversion by the conversion module (208), A-type direct outbound packets are transmitted to gNodeB (106). Then, gNodeB (106) can decapsulate the A-type packets to obtain D-type direct outbound packets and forward the D-type direct outbound packets to UE (102). Decapsulation may include extracting payload data and internal IP headers from GTP packets.

[0032] "Redirected outbound packets" may be packets originating from a location within the external network (214) or from the MEC server (118) where the redirected inbound packets were routed. The redirected outbound packets may be transmitted in response to the redirected inbound packets, or on a part of the same network flow as the redirected inbound packets. For example, the redirected outbound packets may be transmitted to the UE (102) by the MEC server (118) or a third-party server. The redirected outbound packets may traverse the path (206) from the lower right to the upper left of FIG. 2. The redirected outbound packets may traverse the path to the conversion module (208) by, for example, the external network (214), the routing module (216), and part or all of the network (210). A redirected outbound packet received by the routing module (216) may be a D-type packet that is converted into a B-type redirected outbound packet by the routing module (216), and the B-type redirected outbound packet is forwarded to a conversion module (208) through the network (210). The conversion may include encapsulating the internal IP header and payload data of the IP packet into a GTP packet.

[0033] The conversion module (208) converts a B-type redirected outbound packet into an A-type packet and transmits the A-type redirected outbound packet to gNodeB (106). The conversion from B-type to A-type may involve using information stored in the SRH' of the B-type packets. This may involve converting the SRv6 packet into a GTP packet that encapsulates the internal IP header and payload data of the B-type packet and includes data from the SRH' field in the GTP header. Then, gNodeB (106) may decapsulate the D-type redirected outbound packet (internal IP header and payload data) from the B-type redirected outbound packet and transmit the D-type redirected outbound packet to the UE (102).

[0034] In some embodiments, user plane messages are messages used to establish and maintain a session between the UPF (112) and the UE (102). User plane messages may also include messages sent by the UPF (112) to direct the routing of packets to and from the UE (102) and the MEC server (116) or the redirection of packets to an external network (214). User plane messages may also convey 5G user plane messages such as echo requests, echo responses, error indications, or other user plane messages.

[0035] Inbound user plane messages can be routed as direct inbound packets. User plane messages transmitted from the UPF (112) can be treated as direct outbound packets in all instances. When redirection occurs as commanded by the UPF (112), subsequent inbound data packets, i.e., non-user plane message packets, can bypass the UPF (112) and be routed by the conversion module (208) as redirected inbound packets. The conversion module (208) can identify user plane messages by performing deep packet inspection of the inbound packets. Systems and methods for performing such routing are described in detail below.

[0036] Referring to FIG. 3, the network path between the UE (102) and the external network (214) can be understood with respect to a control plane (300) and a data plane (302). The control plane (300) includes modules and includes communication between modules that constitute the modules of the data plane (302) to transmit packets in a predetermined manner. The data plane (302) includes modules and includes communication between modules that transmit packets of payload data between the UE (102) and the external network (214). The modules of the control plane (300) and the data plane (302) may be implemented within a single device, within a plurality of devices coupled to a common circuit board or chassis, or within a plurality of devices connected to one another by one or more network connections. The illustrated components may be executed on a server, a cloud computing platform, or other location, or distributed across one or more of these.

[0037] The control plane (300) and the data plane (302) may also be divided into parts (304 and 306). Part (304) may be understood as transmitting data packets according to communication using protocols suitable for use in packet radio type communication ("packet radio part (304)"), namely GPRS, GTP, or other cellular data communication protocols. In the illustrated embodiment, part (304) implements 3GPP (3rd-generation partnership project) protocols for cellular data communication, but other cellular data communication protocols may also be used.

[0038] Part (306) can be understood as transmitting data packets according to an Internet protocol, such as an IPv6 protocol or other Internet protocols that are not adapted for use in packet radio type communication ("IP part (306)").

[0039] The control plane (300) of the packet radio portion (304) may include the following components:

[0040] HSS UDM (Home Subscriber Server with Unified Data Management) (308) or other components for managing some or all of authentication, handover, IMS (IP Multimedia Subsystems) and SMS (Simple Message Service).

[0041] A policy control function (PCF) and / or a policy and charging rules function (PCRF) (310) for managing access to a cellular data communication network according to user subscription.

[0042] An Access and Mobility Management Function (AMF) and / or a Mobility Management Entity (MME) (312) or other component for managing connectivity and mobility management tasks (e.g., handovers).

[0043] A session management function (SMF) for managing user sessions with UPF and enabling interfacing between an Internet Protocol network and a packet radio network and / or a serving and packet gateway (SPGW, e.g., SPGW-C) (312) (also referred to as “SMF (314)” in this specification) or other components.

[0044] The SMF (314) can manage GTP session information and provide it to the AMF (312). The AMF (312) can program components within the data plane (302) (gNodeB (106) described below) to route packets according to the GTP session information.

[0045] The data plane (302) of the packet radio portion (304) may include the following components:

[0046] A gNodeB (106) or other hardware component capable of communicating directly with the UE (102) via an antenna, encapsulating packets from the UE (102) into GTP packets, and also implementing user plane control protocols.

[0047] A conversion module (208) for switching packets back and forth between GTP and SRv6 when traversing between the packet radio section (304) and the IP section (306).

[0048] The control plane (300) of the IP portion (306) may include the following components:

[0049] A packet forwarding control protocol (PFCP) proxy (322) which will be described in more detail below.

[0050] A boundary gateway protocol (BGP) module (324) or other component for receiving and / or transmitting routing paths to other devices of any of the networks described herein and / or other components shown in FIG. 3 and / or other devices of any network.

[0051] A flat function control module (UPF N4) (326) or other component for terminating the GTP connection and managing the transmission of packets between the packet radio network and the Internet Protocol network. The UPF N4 (326) enables session setup with the UPF (112).

[0052] The data plane (302) of the IP portion (306) may include the following components:

[0053] The aforementioned UPF (112).

[0054] The conversion module (208) operates on both parts (304 and 306).

[0055] Network (210).

[0056] Routing module (216).

[0057] A conversion module (212) for converting traffic sent to the aforementioned UPF (112).

[0058] In the illustrated embodiment, packet forwarding associations according to PFCP can be coordinated between the SMF (314) and the UPF control module (326) by a PFCP proxy (322). Thus, the SMF (314) and the UPF control module (326) can exchange session information through 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 form associations with the PFCP implementation of the UPF control module (326) and associations with the SMF (314). The BGP module (324) may use the snooped information to program the data plane (302) (e.g., conversion modules (208, 212), routing module (216)) to perform conversions from GTP to IP protocol (e.g., SRv6) and from IP protocol to GTP using the information snooped by the PFCP proxy (322) as described below in this specification.

[0059] Existing software packages for implementing PFCP are proprietary and do not change easily. Some open source software packages for implementing PFCP are available but exist only as packages that must be integrated into the application. Additionally, the network stack of the UPF control module (326) can be implemented by third-party or open source software (e.g., upg-vpp (User Plane Gateway Vector Packet Processor)) that is not easily modified.

[0060] In some embodiments, the PFCP proxy (322), BGP module (324), and internal routing module (216) may be modified from conventional implementations of these components to perform some or all of the following:

[0061] Establish associations between the PFCP implementation of the UPF control module (UPF N4) (326) and the SMF (314).

[0062] Messages are transmitted between the PFCP implementation of the UPF control module (326) and the SMF (314).

[0063] Snooping session messages for the BGP module (324) to obtain information such as the address of the UE (102), remote / local tunnel endpoint (TEP) addresses, tunnel endpoint identifier (TEID: Tunnel Endpoint Identifier), and other information.

[0064] FIG. 4 further illustrates an exemplary implementation of a PFCP proxy (322) and a BGP module (324). In a conventional 5G mobile network, an association, for example, a control channel, will be established between an AMF MME (312) and a UPF N4 (326). A session, for example, user plane information, will be established between an SMF SPGW (314) and a UPF N4 (326). Once a session is established between the SMF SPGW (314) and the UPF N4 (326), the UE (102) can begin sending payload traffic. Subsequently, the gNodeB (106) can encapsulate packets from the UE (102) into GTP packets and forward the GTP packets to the UPF (112). In a typical 5G implementation, association and session requests are sent to the UDP port (8805) of the UPF N4 (326), and responses to requests from the UPF N4 (326) will be sent to the source UDP port where the requests were received.

[0065] In a conventional system, it is difficult to optimize the path between gNodeB (106) and UPF (112) for the reasons mentioned above: all UE traffic must be encapsulated in GTP packets and forwarded through UPF (112).

[0066] In some embodiments, the limitations of conventional 5G mobile networks are overcome by interposing a PFCP proxy (322) between the SMF SPGW (314) and the UPF N4 (326), allowing the PFCP proxy (322) to forward 400 traffic between these components. Thus, the PFCP proxy (322) receives PFCP messages from the SMF SPGW (314) and forwards them to the UPF N4 (326). Likewise, the PFCP proxy (322) receives PFCP messages from the UPF N4 (326) and forwards them to the SMF SPGW (314). By doing so, the PFCP proxy (322) can parse PFCP messages bidirectionally to retrieve user plane information.

[0067] Then, the PFCP proxy (322) can provide user plane information to a routing / software-defined network (SDN) controller running outside the PFCP proxy (322) (402). In the illustrated embodiment, the routing / SDN controller is implemented using a BGP module (324), but other implementations may be used. The PFCP proxy (322) and the routing / SDN controller (324) may run on the same computing device or on separate computing devices. The PFCP proxy and the routing / SDN controller (324) can achieve the routing described in FIG. 2 without further modification of the control plane (300), in particular the SMF SPGW-C (314) and UPF N4 (326). In particular, SMF SPGW-C (314) and UPF N4 (326) can exchange information to establish a 5G session through PFCP proxy (322) so that the operation of PFCP proxy (322) is not recognizable by SMF SPGW-C (314) and UPF N4 (326).

[0068] The BGP module (324) can program the conversion module (208) in the data plane according to user plane information (404a). Then, the conversion module (208) can forward the redirected packets according to the path received from the BGP module (324) by bypassing the UPF (112) to a redirection target such as a MEC server (118) or an external network (214) (406), and the path is more optimized compared to the conventional approach where packets are first routed through the UPF (112). The BGP module (324) can also program the conversion module (212) (404b) to route control packets to the UPF (112), and program the routing module (216) (404c) to route packets to and from the MEC server (118) or other device connected to the routing module (216) by the external network (214).

[0069] In relation to programming (404a), the BGP module (324) provides the conversion module (208) with a route toward the UPF (112) and also provides rules regarding how to convert GTP packets into SRv6 packets, that is, A-type packets into B-type packets, as described above. Thus, when the conversion module (208) receives a GTP packet whose destination is the UPF (112), the conversion module (208) will apply the rules received from the BGP module (324) to perform the conversion.

[0070] In relation to programming (404b), the BGP module (324) may provide similar or identical rules to the conversion module (212). Based on these rules, the conversion module (212) may convert SRv6 packets into GTP packets and regenerate the original GTP packet sent to the UPF (112). The BGP module (212) may also provide the conversion module (212) with a route toward the gNodeB (106). When the UPF (112) sends a GTP packet with the destination gNodeB (106), the conversion module (212) may convert the GTP packets into SRv6 packets based on the above rules and then forward the resulting SRv6 packets to the conversion module (208). The conversion module (208) can convert SRv6 packets back into GTP packets based on the same rules and forward the resulting GTP packets to gNodeB (106).

[0071] For packets sent by the UE (102) toward an external network (214) or an external MEC server (118), the routing module (216) may announce an external route to the external MEC server (118) and / or the external routing module (214) to the conversion module (208). This may be done based on the standard L3VPN SRv6 method. Thus, the conversion module (208) may perform standard SRv6 encapsulation based on internal packets generated by the UE.

[0072] In relation to programming (404c), the routing module (216) may implement a standard SRv6 router that may lack the ability to process GTP packets. Accordingly, programming (404c) may include generating a special service SID for SRv6 containing GTP information (e.g., some or all of the GTP information that may be embedded in the SRH' header of a B-type packet) by the BGP module (324). As previously mentioned, redirected inbound packets traversing the network (210) may be formatted as B-type packets. Accordingly, programming (404c) may program the routing module (216) to fill additional GTP information into the SRH' field of the Srv6 header that encapsulates each packet received from the MEC server (118) or the external network (214) and addressed to gNodeB (106).

[0073] For responses received from an external network (214) or an external MEC (118) and directed to the UE (102), the routing module (216) can encapsulate the response packet (an IP packet such as IPv4 or IPv6) into SRv6 packets. In this case, the routing module (216) can use a special service SID provided by BGP (324). This SID contains the necessary GTP information that can be included in the SRH' header. Thus, the conversion module (208) can convert the SRv6 packets into GTP packets and send the resulting GTP packets to the gNodeB (106).

[0074] FIG. 5 illustrates an exemplary implementation of a PFCP proxy (322). The PFCP proxy (322) can parse PFCP messages to retrieve 5G session information, process the messages as schematically shown below, and forward the PFCP messages to their 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 may be assigned to listen or transmit from a specific port of the PFCP proxy (322). The operation of each component is described as follows.

[0075] When forwarding PFCP messages to UPF N4 (326), the PFCP proxy (322) may rewrite the IP source address of the forwarded message to the address of the PFCP proxy and rewrite the IP destination address to the address of UPF N4 (326). The PFCP proxy (322) may rewrite the UDP source port of the forwarded request to the port number of the PFCP proxy. The PFCP request rewritten by the PFCP proxy (322) can then be sent to UPF N4 (326).

[0076] When forwarding a PFCP message to SMF SPGW-C (314), the PFCP proxy (322) rewrites the IP source address to the address of the PFCP proxy, rewrites the IP destination address to the address of SMF SPGW-C (314), and rewrites the UDP source port to the local port number of the PFCP proxy. Then, the PFCP proxy sends the rewritten PFCP response to SMF SPGW-C (314).

[0077] By rewriting the messages (514, 516) in this manner, SMF SPGW-C (314) and UPF N4 (326) are communicating with the PFCP proxy (322). However, the PFCP proxy (322) can overwrite the IP source / destination addresses and UDP source ports so that MF SPGW-C (314) and UPF N4 (326) cannot recognize the PFCP proxy (322) at all.

[0078] The PFCP proxy (322) intercepts PFCP messages by listening to the UDP port (8805). The UDP port (8805) is a port defined by 3GPP for receiving PFCP messages. Therefore, the UDP port (8805) may be replaced with another port throughout the following description if a different configuration is used. The operation of the components of the PFCP proxy (322) may be as follows:

[0079] The PFCP request receiver (500) listens on the port allocated to receive PFCP request messages (514, 516), i.e., PFCP messages, addressed to UDP port (8805) from SMF SPGW-C (314) or UPF N4 (326), and records the source port (Port A in the illustrated example) of the PFCP request (514) from SMF SPGW-C (314). The PFCP request receiver (500) may additionally record the source port (Port B in the illustrated example) of the PFCP request (516) from UPF N4 (326). The source ports for the messages (514, 516) may be pre-configured (Port X and Y individually).

[0080] The SMF request forwarder (502) forwards the request (516) to the SMF SPGW-C (314). The SMF request forwarder (502) is configured by the PFCP request receiver (500) to use X as the source port for the forwarded request (516) sent to the SMF SPGW-C (314) 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-C (314) and rewriting the IP source address to the IP address of the PFCP proxy (322).

[0081] The UPF request forwarder (504) forwards the request (514) to the UPF N4 (326). The UPF request forwarder (504) is configured by the PFCP request receiver (500) to use Y as the source port for the forwarded request (516) sent to the 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 the UPF N4 (326) and rewriting the IP source address to the IP address of the PFCP proxy (322).

[0082] The SMF response receiver (506) is configured to detect PFCP responses (518) from the SMF SPGW-C (314) addressed to Port X, and to provide the detected PFCP responses (518) to the UPF response forwarder (512).

[0083] The UPF response receiver (508) is configured to detect PFCP responses (520) from the UPF N4 (326) addressed to Port Y and to provide the detected PFCP responses (520) to the SMF response forwarder (510).

[0084] The SMF response forwarder (510) is programmed to forward PFCP responses (518) to the SMF SPGW-C (314), and the source of the forwarded PFCP responses (518) is set to UDP port (8805) and the destination is set to port A (the previously recorded source port of the request (514)). The SMF response forwarder (510) further modifies the forwarded responses (518) by rewriting the IP destination address to the IP address of the SMF SPGW-C (314) and rewriting the IP source address to the IP address of the PFCP proxy (322).

[0085] The UPF response forwarder (512) is programmed to forward PFCP responses (520) to port Y of the UPF N4 (326), and the source of the forwarded PFCP responses (520) is set to UDP port (8805) and the destination is set to port B (the previously recorded source port of the request (516)). The UPF response forwarder (512) also further modifies the forwarded response (518) by rewriting the IP destination address to the IP address of the UPF N4 (326) and rewriting the IP source address to the IP address of the PFCP proxy (322).

[0086] Referring to FIG. 6, when the PFCP proxy (322) forwards messages as summarized above in relation to FIG. 4, the PFCP proxy (322) may also snoop on information regarding associations and sessions created using the messages. Then, this snooped information may be provided to the routing / SDN controller (324) (BGP module (324)). In the illustrated embodiment, the transmission of information between the PFCP proxy (322) and the routing / SDN controller (324) is performed using inter-process communication (IPC) (600). For example, gRPC (an open source remote procedure call system). The SDN controller (324) may program the routing table (602) according to the snooped information.

[0087] The snooped information may include some or all of the following:

[0088] Remote Tunnel Endpoint (TEP), e.g., the address of UPF (112)

[0089] Local TEP, e.g., address of gNodeB(106)

[0090] Tunnel Endpoint Identifier (TEID)

[0091] QFI (Quality of Service (QoS) Flow Identifier)

[0092] UE address (address of UE(102))

[0093] Access Network Instance

[0094] Core network instance

[0095] Upon receiving this information, the routing / SDN controller (324) may create router entries in the routing table (602) based on this information. These routing entries may be used to control routing of the conversion modules (208, 212) and possibly the routing module (216) to implement the routing described above in relation to FIGS. 2 and 4.

[0096] Referring again to FIG. 2, the desired routing may include receiving an internal IP packet from the UE (102) by gNodeB (106), which generates a Type A (GTP) packet containing the internal IP packet. gNodeB (106) transmits the Type A packet to UPF (112) through a GTP tunnel between gNodeB (106) and UPF (112). The parameters defining this GTP tunnel are included in the previously listed snooped information, specifically the remote TEP referencing UPF (112) and the local TEP referencing gNodeB (106).

[0097] As described above in relation to FIG. 2, rather than simply routing A-type packets through a GTP tunnel, A-type packets are converted into B- or C-type packets and routed through an IP network (210), such as an SRv6 network (210). The conversion between the IP network (210) and the GTP tunnel is managed by conversion modules (208, 212). Additionally, the routing module (216) may also need to route packets by referring to parameters defining the GTP tunnel. Snooped information obtained by the PFCP proxy (322) may be provided to the routing / SDN controller (324). Then, the routing / SDN controller (324) may program the conversion modules (208, 212) and the routing module (216) to achieve the routing described in relation to FIG. 2. Various examples of how the conversion modules (208, 212) and routing module (216) can be programmed by the routing / SDN controller (324) are described below.

[0098] In the first example, the routing / SDN controller (324) receives the remote TEP and creates and distributes a route toward the UPF (112). In particular, this route may be provided to the translation module (208). The route may be provided in addition to the programming (404a) described above to perform translation between GTP and SRv6.

[0099] In the second example, the routing / SDN controller (324) receives the local TEP and UE address and generates and distributes a service SID based on this information according to SRv6. In particular, the service SID may be provided to the routing module (216). The service SID advertises a route to the UE (102) through the network (210) by the gNodeB (106) referenced by the local TEP. A QFI may be used by the routing / SDN controller (324) when generating the service SID. This second example may be implemented when performing programming (404c) as described above.

[0100] In the third example, gNodeB (106) can send Type A (GTP) packets into a GTP tunnel established with UPF (112) by setting the destination of Type A packets to a remote TEP (tunnel endpoint address of UPF (112)). A PFCP proxy (322) obtains this remote TEP address by snooping on control packets between gNodeB (106) and UPF (112) when setting up the GTP tunnel. The PFCP proxy (322) can provide the remote TEP address to a routing / SDN controller (324).

[0101] Then, the routing / SDN controller (324) can generate a routing entry for this remote TEP and program the conversion module (208) with this routing entry. In some embodiments, the routing / SDN controller (324) can use a function such as GTP4.D to generate the routing entry. The routing entry defines a conversion from Type A to Type B packet, including encoding of GTP header information into an SRH' header, and can define routing to the conversion module (212) through the network (210) in the form of one or more SIDs according to a segment routing protocol such as SRv6.

[0102] In the fourth example, the routing of traffic from the ingress premise equipment (PE) to the egress PE is managed based on snooped information as described below. The ingress PE may be, for example, a conversion module (208), while the egress PE is a routing module (216) for interfacing with an external network (214) or an MEC server (118). In the reverse direction, the routing module (216) is the ingress PE and the conversion module (208) is the egress PE.

[0103] In a standard virtual private network (VPN) such as L3VPN SRv6, the ingress PE sends an SRv6 packet, which is an internal packet received from an IP network. The destination address of the SRv6 packet can be set to an IP address, such as an IPv6 address assigned to the egress PE (e.g., a segment identifier (SID)). The egress PE receives the SRv6 packet, decapsulates the internal packet, and forwards the internal packet to the destination address of the internal packet. In the example given, the destination address of the internal packet may be in the form of an IPv6 destination (e.g., a SID). Thus, the egress PE can determine where to forward the internal packet based on the destination address of the internal packet, which may be a third-party server or UE (102), depending on the direction in which the packet is traveling through the network (210).

[0104] In the illustrated embodiment, the egress PE (e.g., the translation module (208)) may need to determine the gNodeB (106) of the set of available gNodeB instances to which an internal packet must be forwarded to reach a specific UE (102). Accordingly, the egress PE may receive a routing entry from the routing / SDN controller (324) mapping the IP address of the UE (102) to the local TEP of the gNodeB (106) to which the UE (102) is connected (e.g., to which a TCP or other session has been established). The association between the IP address of the UE (102) and the local TEP may be determined from the snooped information listed above.

[0105] The routing entry can instruct the egress PE to use the local TEP of gNodeB (106) when performing a packet conversion from a C-type packet to an A-type packet and sending the resulting A-type packet to gNodeB (106) over the GTP connection. For example, if GTP4.D (IPv4 GTP) is used, the routing / SDN controller (324) can provide the following IPv6 addresses to the egress PE:

[0106] SRv6 Locator (<56 bits) + TEID (32 bits) + QFI (8 bits) + Local TEP Address (32 bits)

[0107] The "SRv6 locator" may refer to a configuration on the routing / SDN controller (324). Based on the SRv6 locator, the translation modules (208, 212) can recognize the translation functions they will perform. For example, BGP (324) may assign 2001:db8:: / 48 as the SRv6 locator for translation between GTP and SRv6. In this case, when the translation module (208, 212) generates an SRv6 packet from a GTP packet, it will use 2001:db8:: / 48 as the SRv6 locator and embed the TEID, QFI, and TEP addresses of the GTP packet in the SRH' field. When the conversion module (208, 212) receives an SRv6 packet whose destination matches 2001:db8:: / 48, the conversion module (208, 212) can understand that the SRv6 packet needs to be converted into GTP. The conversion module (208, 212) can obtain the TEID, QFI, and TEP addresses from the SRH' field and then reconstruct the original GTP packet. Then, the GTP packet can be sent to either the UPF (112) or the gNodeB (106) to which it is addressed.

[0108] In the case of Multipath Label Switching (MPLS) in L3VPN, an SRv6 locator can be used to identify a given VPN. In the case of SRv6 L3VPN, an SRv6 locator can identify the Service SID (IPv6 address format) and can be used to identify a given VPN instead of the label for MPLS L3VPN.

[0109] The local TEP address can be embedded in the IPv6 address. This address can also be notified to the ingress PE as a service SID. When the egress PE receives a packet whose destination matches this IPv6 address, the egress PE can determine the gNodeB instance to forward the packet to, obtain the local TEP address of the BBU, and generate a GTP packet (Type A packet) to send to the gNodeB instance. The routing / SDN controller (324) can program the egress PE with a routing rule, such as the GTP4.D routing rule, which instructs the egress PE to perform the conversion from the IPv6 address to the GTP packet.

[0110] To convert from SRv6 to GTP, the egress PE can use the following information: the local TEP address (address of gNodeB (106)), the TEID (tunnel identifier), and the QFI (QoS identifier). The local TEP address is the destination address of the GTP packet. The TEID and QFI are values ​​that need to be embedded in the GTP header. Thus, this information can be embedded in the IPv6 destination address (see the exemplary address above) of packets routed from the ingress PE to the egress PE to enable the conversion from SRv6 to GTP to be returned to the IPv6 destination address.

[0111] This information (local TEP address, TEID, QFI) is obtained by the PFCP proxy (322), provided to the routing / SDN controller (324), and then used by the routing / SDN controller (324) to embed the information as previously described and to program the ingress PE and egress PE to perform transformations using the information. The routing / SDN controller (324) can do so by notifying VPNv4 / v6 routes using the IPv6 address included in the embedded information as the service SID provided to the ingress PE. The routing / SDN controller (324) can also program this information to the egress PE in the form of an SRv6 locator generated using the GTP4.E function.

[0112] When an ingress PE receives a packet from an IP network, the ingress PE can encapsulate the packet from the IP network into SRv6. In this case, the external IPv6 destination address is the above-mentioned service SID containing embedded information. When an egress PE receives a packet having an external IPv6 destination matched to the service SID, the egress PE can decide to execute the GTP4.E function on the received packet to convert it into a GTP (Type A) packet using the TEID, QFI, and local TEP embedded in the IPv6 destination address.

[0113] In the fifth example, the routing module (216) can receive packets addressed to the IP address of the UE (102) from an external network (214). The snooped information provides an association to the local TEP of the gNodeB (106). Thus, the routing / SDN controller (324) can notify the routing module (216) of a route instructing the routing module (216) to route traffic addressed to the IP address of the UE (102) to the gNodeB (106). The packets can then be routed by the routing module (216) to the UE (102) by the gNodeB (106) according to the path (206) of FIG. 2, in accordance with the conversions between the D, C, and A-type packets described above.

[0114] In the sixth example, the snooped information may include a core network instance. This value can be used for network slicing in a 5G core network. Based on this value, the routing / SDN controller (324) can determine which virtual routing and forwarding (VRF) table a UE address should be imported from and which VPN (VRF) to use when creating a route to the UE (102) when performing programming (404c). The access network instance within the snooped information can be used to filter specific UE addresses from a given VRF table. Thus, the routing / SDN controller (324) can specify import and / or filter rules based on the core network instance and access network instance specified in the snooped information.

[0115] Referring to FIGS. 7a and 8, the conversion module (208) manages the conversion of packets from SRv6 to GTP. In a typical 5G network, GTP packets are received from gNodeB (106) by the UPF (112), internal IP packets are obtained from GTP packets by the UPF (112), and the internal IP packets are subsequently processed by an SRv6 component to manage the routing of internal IP packets according to SRv6, which may include using routing according to a virtual routing function (VRF). The SRv6 component may be a target for inbound packets addressed to the UE (102), manages routing according to SRv6, and forwards the received packets to the UPF (112) for encapsulation into GTP packets and forwarding to gNodeB (106).

[0116] In the approach described herein, packets are routed to and from the conversion module (208) through the SRv6 network (210) and the external network (214). Accordingly, the conversion module (208) can also manage the routing of packets according to SRv6, including managing VRFs.

[0117] The approach described in this specification refers to SRv6. However, it can be implemented with labels according to Multi-Protocol Label Switching (MPLS).

[0118] Specifically, referring to FIG. 7a, the routing module (216) may include a route reflector client (700), such as a BGP route reflector client, or may function as a route reflector client. The BGP module (324) (also referred to herein as the routing / SDN controller (324)) may function as a route reflector and may receive routing information (702) broadcast by the route reflector client (700). Then, the BGP module (324) may reflect this routing information to the conversion module (208) by performing, for example, standard route reflector functions (704). In some embodiments, the routing module (216) sends a VPNv4 / v6 update to the BGP (324) for an external route, that is, a route to an external IP address in an external network (214). A BGP (324) acting as a route reflector having a routing module (216) as a client reflects VPNv4 / v6 updates from the routing module (216) to the translation module (208). Based on this, the translation module (208) can obtain a route to an external network (214) through the routing module (216).

[0119] For example, the routing module (216) can update routes such as VPNv4 / v6 routes having a service SID. The routes can describe routing to an external network (214), and the service SID can command the execution of a segment, including performing VPNv4 / v6 functions on packets labeled with the service SID. The route can provide an SR policy that specifies the routing module (216) as the next hop for one or more addresses in the external network (214), or commands the addition of a prefix SID to packets containing one or more addresses, and the prefix SID refers to a segment that commands the routing of packets to the routing module (216). Thus, when this route is provided to the translation module (208), it becomes possible to receive GTP packets (Type A packets of FIG. 7a) and decapsulate internal IP packets.

[0120] The translation module (208) obtains the destination IP address of an internal IP packet and determines that the root specifies that packets addressed to the destination IP address should be forwarded to the routing module (216). Then, the translation module (208) forwards the internal IP packet as an SRv6 packet (a C-type packet in FIG. 7a) having a SID specified by the root (e.g., a prefix SID of the routing module (216)). The C-type packet can be forwarded to the routing module (216) through the network (210), which can be implemented as a Level 3 (L3) VPN having SRv6 in the embodiments of FIG. 7a through 7d.

[0121] The routing module (216) receives a C-type packet, decapsulates the internal IP packet (D-type packet of FIG. 7a), and forwards the internal IP packet to a destination IP address through an external network (214).

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

[0123] FIG. 7b illustrates an approach for using a BGP module (324) and a translation module (208) to manage the routing of traffic from the UE (102) to the UPF (112) through the 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 the gNodeB (106) and the UPF (112). Other GTP-U messages include an Echo request and an Echo reply to detect whether this data path is healthy. GTP-U messages can also be used to communicate error indications in response to errors on the data path. GTP-U messages may include an end marker to indicate the end of data packet transmission (e.g., when a handover occurs). In the case of user data traffic addressed to an external network (214), the conversion module (208) can strip off the GTP header, encapsulate the internal IP packet into an SRv6 packet (C-type packet), and then forward the C-type packet directly to the conversion module (212).

[0124] As in other embodiments described herein, the BGP module (324) obtains information from the PFCP proxy (322) and / or CLI controller (708) (706). The information related to the function of FIG. 7b may include the remote TEP address of the GTP tunnel, the VRF ID (or root identifier RD), and VPN information (VPNv4 / v6 information).

[0125] To enable the processing of GTP-U messages by the UPF (112) and / or gNodeB (106), the conversion module (208) may forward the GTP-U messages to the UPF (112). As previously mentioned, this may involve the use of a second conversion module (212) between the network (210) and the UPF (112). The conversion module (212) may convert the packets from SRv6 to GTP before forwarding the GTP packets to the UPF (112). To do this, GTP information may be embedded in the SRH field of the SRv6 packets, e.g., B-type packets, that are forwarded to the conversion module (212).

[0126] Accordingly, the BGP module (324) may provide VPNv4 / v6 updates to the translation module (208) to provide a route to the UPF (112) (710). The BGP module (324) may also provide the translation module (208) with an SR policy that commands the translation module (208) to translate GTP packets addressed to the UPF (112) (712), and such translation includes encoding GTP information within the SRH field as described above. The VPNv4 / v6 updates and GTP information may be obtained by the BGP module (324) from information received from the PFCP proxy (322) as described above. Programming (710) may include providing the translation module (208) with VPNv4 / v6 updates containing a route to the UPF (112). Programming (710) may include programming the translation module (208) to this route from a specific VRF. Based on this programming (710), the conversion module (208) can route packets from gNodeB (106) to UPF (112).

[0127] The programming (710) provided to the UPF (112) by the conversion module (208) can further manage routing according to the VRF routing distinguisher (RD) to which the gNodeB (106) is connected and the 5G network instance (access) to which the gNodeB (106) belongs. The CLI controller (708) can provide a mapping between the first VRF RD to which the gNodeB (106) is connected and the 5G network instance (access) to which the gNodeB (106) belongs, as well as the second VRF RD for the destination IP address of an internal IP packet (e.g., an internal IP packet encapsulated by a GTP packet). The PFCP proxy (322) can provide the address of the 5G network instance (access) to which the gNodeB (106) belongs and the UPF.

[0128] Using this information, the BGP module (324) determines which VRF RD is matched to a 5G network instance (access, i.e., a network including UPF (112)) provided by the PFCP proxy (322). Then, the BGP module (324) may perform the following actions: send a VPNv4 / v6 update to the translation module (208) for the route to the UPF for the first VRF RD matched to the 5G network instance (access); and send an SR policy to the translation module (208) to inform the second VRF RD associated with the destination address of the internal IP packet and the aforementioned translation rule (defining the translation from GTP to SRv6 with embedded GTP information).

[0129] The SR policy and VPNv4 / v6 can program the conversion module (208) to perform the following functions:

[0130] Received a GTP packet whose destination address is the address of UPF (112);

[0131] Check the packet type of the GTP packet;

[0132] If the packet type of the GTP packet is user data traffic, strip off the GTP header to obtain the internal IP packet and forward the internal IP packet using the routing table for the VRF RD provided by the BGP module (324) (e.g., perform standard L3VPN SRv6 forwarding).

[0133] If the GTP packet is a GTP-U message, a conversion from GTP to SRv6 (e.g., a conversion into a B-type packet containing GTP information embedded in the SRH' field) is performed based on a conversion rule provided by the BGP controller (e.g., GTP4 / 6.D rule).

[0134] In some embodiments, the VPNv4 / v6 update for a UPF address has a binding SID value as a prefix SID. Thus, the VPNv4 / v6 update is coupled to a specific SR policy, namely an SR policy received from the BGP module (324). The SR policy received from the BGP module (324) may also include the same binding SID and may also include a VRF RD for an internal IP packet. Based on this, when the translation module (208) receives a GTP packet whose destination matches a UPF address, the translation module (208) may apply the SR policy to the GTP packet.

[0135] In some embodiments, the SR policy may instruct the translation module (208) to evaluate whether the destination address of an internal IP packet is an IPv6 link-local address. If so, the translation module (208) may perform the same translation from GTP to SRv6 according to the SR policy as described above, and then forward it to the translation module (212). However, since link-local addresses are not globally routable, only the UPF (112) can process such packets. Therefore, the translation module (208) needs to send the translated SRv6 packet to the UPF (112). For each GTP packet, the SR policy may instruct the translation module to check whether the destination address of the internal IP packet is link-local, and if so, to convert the GTP packet into an SRv6 packet, simultaneously embed GTP-related information in the SRH field of the SRv6 packet, and forward the SRv6 packet to the translation module (212). Then, the conversion module uses the built-in information to convert the SRv6 packet back into a GTP packet and forwards the GTP packet to the UPF (112).

[0136] Based on the VPNv4 / v6 update (710) provided by the BGP module (324), the translation module can be programmed with a routing entry for a UPF address in a routing table associated with the first VRF RD (external VRF for the network to which gNodeB (106) is connected). The SR policy provided in step (712) can associate the second VRF RD (internal VRF for the network to which UPF (112) is connected) with a binding SID. The binding SID can call the application of the SR policy to internal IP packets addressed by the UPF address and the second VRF RD. The binding SID can be used as a service SID for the VPNv4 / v6 update for the UPF address. The binding SID can also be returned to the SR policy. The SR policy can return the internal VRF RD used to route internal IP packets. Therefore, from the perspective of this programming, the GTP packet received from gNodeB (106) can be processed by the conversion module (208) as follows:

[0137] Perform a routing lookup based on the destination address (UPF address) of the routing table associated with the VRF RD associated with the incoming interface where the GTP packet was received;

[0138] Obtain an SR policy based on the binding SID used as the service SID for VPNv4 / v6 updates for UPF addresses;

[0139] Check message type;

[0140] If the message type is G-PDU, the conversion module (208) strips the GTP header to obtain an internal IP packet, encapsulates the internal IP packet into an SRv6 packet, and routes the SRv6 packet according to the standard SRv6 L3VPN using the second VRF RD (internal VRF for the destination IP address of the internal IP packet) as specified by the SR policy.

[0141] If the message type is GTP-U, the conversion module (208) generates a special service SID that returns GTP-related information such as a UPF address, QFI, and TEID, and an SRv6 locator according to the SR policy; encapsulates the internal IP packet of the GTP packet into an SRv6 packet containing the special service SID and sends the SRv6 packet to the conversion module (212).

[0142] The special service SID can be formatted as [destination SRv6 locator][UPF address + QFI + TED], where GTP4.D is used. Where GTP6.D is used, the special service SID can be in the form [destination SRv6 locator][QFI + TEID + sid0], where sid0 is the UPF address.

[0143] FIG. 7c illustrates the functions of a BGP module (324) for configuring a routing module (216) to route packets received from an external network (214) and addressed to a UE (102). When a packet is received by the routing module (216) from the external network (214) and addressed to a UE (102), the routing module may use a route associated with the address of the UE (102). This route may be provided to the routing module (216) by the BGP module (324) using the approach illustrated in FIG. 7c.

[0144] The CLI controller (708) can provide a mapping between the VRF RD and the VRF RD defined for the 5G network instance (core), for example, the network (210) (714). The PFCP proxy (322) can provide the 5G network instance (core) including the gNodeB (106) and the UE address.

[0145] Based on this information, the BGP module (324) can determine which VRF to import the packets addressed to the UE address based on the 5G network instance (core) where the packets were received. After importing the UE address to the VRF identified by the VRF RD (i.e., the route to the UE address), the BGP (324) generates a VPNv4 / v6 update (716) to inform the routing module (216) of the route to the UE (102).

[0146] When sending this VPNv4 / v6 update for the UE route, the BGP module (324) may assign a service SID to the UE route. Accordingly, in response to the VPNv4 / v6 update, the routing module (216) will receive internal IP packets containing the UE address from the external network (214). In response to receiving the internal IP packets containing the UE address, the routing module (216) will encapsulate the internal IP packets into an SRv6 packet containing this service SID as the destination, as commanded by the updated VPNv4 / v6. This service SID will command the intervening components to route the packets to the UE according to the route, including the translation module (208) and gNodeB (206).

[0147] When the conversion module (208) receives an SRv6 packet from the network (210), the conversion module (208) may need to convert the SRv6 packet into a GTP packet because the GTP packet needs to be forwarded to the UE through the gNodeB (106). The service SID may be encoded by the BGP module (324) to return GTP-related information such as the address, TEID, and QFI of the gNodeB.

[0148] IPv6 addresses are 128 bits. Therefore, in the case of GTP4.E (where the gNodeB address is IPv4), all GTP-related information can be embedded in a single IPv6 address as follows: SRv6 locator + gNodeB IPv4 address + QFI + TEID. If the maximum SRv6 locator length is 56 bits and the gNodeB address is a 32-bit IPv4 address, this leaves 8 bits for the QFI and 32 bits for the TEID. In the case of GTP6.E where gNodeB (106) has an IPv6 address, it may not be possible to embed the address of gNodeB (106) along with GTP information in a single IPv6 address. In that case, SRv6 can return multiple segments (IPv6 addresses) to the SRH. Therefore, the last SID of the SRH (SID[0]) may be the IPv6 address of gNodeB (106), and the second-to-last (penultimate) SID (SID[1]) may be the SRv6 locator, QFI, and TEID.

[0149] FIG. 7d illustrates the functions of a BGP module (324) for configuring a conversion module (208) to route packets received from an external network (214) and addressed to a UE (102). These packets may be received by the conversion module (208) from a routing module (216) through the network (210). The BGP module (324) may further configure the conversion module (208) to convert these packets from SRv6 to GTP.

[0150] The BGP module (324) can receive information such as an external VRF connected to gNodeB for each VRF into which an SRv6 locator and UE address for GTP4 / 6.E are imported from the CLI controller (708) (718).

[0151] The BGP module (324) may provide an SRv6 locator that identifies a function to be applied by a translation module (208), such as a GTP4 / 6.E or GTP4.D function that performs translation as described above. The SRv6 locator and the corresponding translation function may be provided to the translation modules (208, 212) by the BGP module (324). Such an SRv6 locator may be included in the service SID as described above. The BGP module (324) generates an SR policy and transmits it to the translation module (208) (720). The SR policy includes various commands.

[0152] The SR policy may 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 position of the gNodeB address, QFI, and TEID embedded in the service SID (or SIDs) included in the SRH field as described above in relation to FIG. 7c (e.g., whether items of this information are in SID[0] or SID[1]). The SR policy may also return a function such as GTP4.E or GTP6.E, which instructs the translation module (208) to use the last segment of the SRH header to locate the gNodeB address and perform a translation from SRv6 to GTP using the embedded GTP information. The SR policy generated by the BGP module (324) can additionally provide an external VRF for the UE address used to route the GTP packet to the UE (102) after the GTP packet is acquired by converting the SRv6 packet to GTP according to the SR policy.

[0153] FIG. 8 illustrates an exemplary configuration of a conversion module (208). A conversion module (212) may have a similar configuration. In the illustrated embodiment, packets (e.g., GTP-U messages) received from gNodeB (106) and transmitted to UPF (112) may 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 (e.g., non-GTP-U messages) received from gNodeB (106) and transmitted to the routing module (216) can be processed by the FIB lookup module (800), the GTP 4.6.D module (802), the third FIB lookup module (808), the SRv6 encapsulation module (810), and the fourth FIB lookup module (812).

[0154] The first FIB lookup module (800) can evaluate the interface (IP address and VRF RD) where the packet was received. If the interface is associated with a binding SID, the SR policy associated with the binding SID calls the processing of the packet by the GTP4 / 6.D module (802). Programming of the first FIB lookup module (808), generation of the binding SID and SR policy, and programming of the GTP4 / 6.d module can be performed by the BGP module (324) as described above.

[0155] The GTP4 / 6.D module (802) can be programmed as a function called 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 the packet from a GTP packet (Type A) into an SRv6 packet containing embedded GTP information (Type B). Further details regarding how this encapsulation is performed may be described below in relation to FIG. 9a. The SRv6 packets generated by the SRv6 encapsulation module (804) can be processed by the second FIB lookup module (806). The second FIB lookup module (806) can evaluate the destination address of the SRv6 packet (i.e., the address of the GTP / SRv6 (212) ahead of the UPF (112)) and determine where to route the SRv6 packet. This may include using information from a VPNv4 / v6 update to determine the next hop, VPN tunnel information, VRF RD, or other information to use to route the SRv6 packet to the UPF (112). As previously mentioned, the VPNv4 / v6 update may be received from the BGP module (324). Then, the translation module (208) transmits the SRv6 packet according to the routing information obtained from the second FIB lookup module (806).

[0156] If the GTP 4 / 6.D module determines that the GTP packet is not a GTP-U message, the GTP packet may be processed by a third FIB lookup module (808) after stripping the GTP / UDP / external IP header. The third FIB lookup module (808) may look up information for encapsulating the internal IP packet of the GTP packet into an SRv6 packet. This may include, for example, looking up a VPNv4 / v6 route associated with the destination address of the internal IP packet and determining these SIDs to encapsulate the internal IP packet into an SRv6 packet. The SIDs may define the routing of the SRv6 packet encapsulating the internal IP packet through the network (210) and may be generated according to routing information received from the BGP module (324). The internal IP packet and SID may be provided to an SRv6 encapsulation module (810) that encapsulates the internal IP packet and SID into an SRv6 packet. The SRv6 packet may be processed by a fourth FIB lookup module (812).

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

[0158] FIG. 9a illustrates a process of converting a GTP (Type A) packet received by a conversion module (208) into an SRv6 packet having embedded GTP information (Type B) packet. As previously described, the Type A packet may include an internal IP packet (e.g., a destination address in an external network), a GTP header, and an external IP header (e.g., a destination address of a UPF (112)). In the case of GTP4.D, the SIDs included in the SRH' field of the Type B packet may be as illustrated. In the case of GTP4.D, a single SID (SID[0] or the first SID in the SRH' field) includes the aforementioned GTP4.D locator, an external IP address (address of a UPF (112)), and GTP information such as QFI, TEID, and sequence ID used in 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 quality of service (QoS) flow identifier defined by 3GPP. R is a reflective QoS indication (RQI) defined by 3GPP. The U bit is used to specify the protocol data unit (PDU) type for the GTP-U packet. For GTP6.D, two SIDs (SID[0], SID[1]) may be used. SID[0] may include an external IP address (address of UPF(112)), and SID[1] may include embedded GTP information such as QFI, TEID, and sequence ID.

[0159] FIG. 9b illustrates the function of a conversion module (208) when processing SRv6 (B-type packets) having embedded GTP information received from a routing module (216). The FIB lookup module (812) receives the packet and determines the binding SID associated with the interface (source address and VRF RD) on which the packet was received. The SR policy associated with the binding SID may call the GTP4 / 6.E module (814). The GTP4 / 6.E module (814) may convert the SRv6 packet into a GTP (A-type) packet using the embedded GTP information. As for programming of the GTP4 / 6.E module (814), the binding SID and SR policy may be received from the BGP module (324) as described above.

[0160] GTP packets can be processed by an FIB lookup module (800) that determines a VRF RD associated with a destination address (e.g., gNodeB (106) address or UPF address) and routes the GTP packets according to a routing table for the corresponding VRF RD. Routing performed by the FIB lookup module (800) may follow VPNv4 / v6 updates received from the BGP module (324) as described above. FIG. 9b illustrates a packet flow for a downlink (an external network (214) to the UE (102) or a UPF (112) to the UE (100)). For such a packet flow, the FIB lookup module (812) can be programmed to determine a routing entry pointing to the GTP4 / 6.E module (814). Then, the GTP4 / 6.E module (814) can convert each SRv6 packet into a GTP packet. This GTP packet can then be routed to the FIB lookup module (800).

[0161] FIG. 9c illustrates a conversion from a B-type packet to an A-type packet. Information embedded in the SRH' field is obtained. As previously mentioned, in the case of GTP4.E, this information will be included in SID[0]. In the case of GTP6.E, this information will be included in SID[1]. The GTP4.E locator in the SRH' field is associated with a GTP4.E function that performs a conversion using an external IPv4 destination address and embedded GTP information (QFI, TEID / SequenceID). The conversion may include using an external IPv4 destination address (e.g., the address of gNodeB) as the external IP destination address of the A-type packet and including GTP information embedded in the GTP field of the A-type packet. The internal IP packet may be forwarded to the address of the UE (102).

[0162] FIGS. 8, 9a, 9b, and 9c are described in relation to the conversion module (208). The conversion module (212) likewise performs conversion between Type A and Type B packets and can function in a similar manner. In particular, packets traveling from UPF (112) to gNodeB (106) can be converted in the same way as packets traveling from gNodeB (106) to UPF (112). Packets traveling from SRv6 (216) to UE (102) can be processed in the same way as packets traveling from UPF (112) to gNodeB (208). In other words, conversion from SRv6 to GTP can be performed by the conversion module (208, 212) when receiving packets from the network (210), regardless of the entity sending the packets (other conversion modules (208, 212) or routing module (216)).

[0163] Referring to FIG. 10a, the approaches described herein may use a PFCP proxy (322) to obtain information describing a GTP tunnel that can be embedded in SRv6 packets. To interface with the SMF (314) and UPF (112), the PFCP proxy (322) may implement an N4 interface. The N4 interface may be an interface between a 5G network and a user plane such as the UPF (112). In previous approaches, an N4 interface is created for each UE (102). Thus, since the PFCP proxy (322) implements an interface for both the SMF (314) and the UPF (112), when used according to previous approaches, the PFCP proxy (322) may create 2X N4 interfaces, where X is the number of UEs (102). The given UPF (112) can manage thousands of UEs (102), so the load placed on the PFCP proxy (322) can be very large.

[0164] In some embodiments, on the side of the SMF (314), a PFCP session load balancer (1000) distributes traffic to a plurality of N4 controllers (1002). On the side of the UPF (112), another PFCP session load balancer (1004) distributes traffic to a plurality of N4 controllers (1002). Each of the N4 controllers (1002) may implement a PFCP proxy (322). In particular, each N4 controller (1002) may perform the functions given herein for the PFCP (322) for traffic routed to it. Traffic routed from the load balancers (1000, 1004) to the N4 controllers (1002) may include the PFCP requests and responses described above in relation to FIGS. 1 through 5. Thus, the N4 controllers (1002) may snoop on the aforementioned session information. This snooped information may include the address of gNodeB (106) for the GTP tunnel, the address of UPF (112), the address of UE (102), TEID, QFI, some or all of the access network instance and core network instance.

[0165] The load balancers (1000, 10004) and N4 controllers (1002) may be running on the same computing device, on different virtual machines or containers on the same computing device, or on separate computing devices connected by a network.

[0166] FIG. 10b illustrates a method (1006) that can be executed using load balancers (1000, 1004) and N4 controllers (1002). The method (1008) may include the step (1008) of an ingress load balancer receiving an input packet, such as a GTP packet. For input packets received from SMF (314) and addressed to UPF (112), the ingress load balancer may be a load balancer (1000). For input packets received from UPF (112) and addressed to SMF (314), the ingress load balancer may be a load balancer (1004).

[0167] Then, the ingress load balancer can extract a tuple from the input packet (1010). The tuple may be a set of values ​​used to distribute packets among multiple N4 controllers. The tuple may include some or all of the following items of information from the input packet: an IP source address, an IP destination address, a session identifier (SEID), and a fully qualified session identifier (FQ-SEID). The IP source address and the IP destination address may, individually, be the address of either the SMF (314) or the UPF (112) to which the input packet was received or to which the input packet is addressed. In some embodiments, multiple SMFs (314) and UPFs (112) may send packets to the ingress load balancer. In these embodiments, load balancing may be performed using only the IP source address and the IP destination address. If a single SMF (314) and a single UPF (112) exist, SEID and / or F-SEID may be used and source and IP source and IP destination addresses may be ignored.

[0168] Then, the ingress load balancer can select one of the N4 controllers (1002) corresponding to the tuple (1012). For example, the tuple can be input to a hash function, and the output of the hash function is an identifier of one of the N4 controllers (1002). Then, the input packet can be sent to the selected N4 controller (1002) (1014). Then, the selected N4 controller (1002) can process the input packet (1016). This may include snooping on session information and performing any of the other functions of the PFCP proxy, such as those described for FIG. 5, and any of the other functions described herein for the PFCP proxy (322). The N4 controller (1002) can generate an output packet in response to the input packet. Then, the output packet can be sent to the egress load balancer by the N4 controller (1002) (1018). For input packets received from SMF (314) and addressed to UPF (112), the egress load balancer may be a load balancer (1004). For packets received from UPF (112) and addressed to SMF (314), the egress load balancer may be a load balancer (1000). Then, the egress load balancer may forward the output packet to the destination address of the output packet, which may be the same as the destination address of the input packet.

[0169] Referring to FIG. 11, the aforementioned approach can be executed in an illustrated network environment in which a plurality of gNodeBs (106a-106c) and a plurality of conversion modules (208a-28c) exist. Each conversion module (208a-208c) can connect a region (1104a-1104c) of a cellular data network to the network (210). Each gNodeB (106a-106c) can be connected to one of the conversion modules (208a-208c) by one of the regions (1104a-1104c).

[0170] Using the aforementioned approach, the BGP module (324) transmits a first SID (SID1) to a conversion module (208a) to enable the conversion of packets received from and transmitted to all UEs (102) connected to the gNodeB (106a) (1100). The BGP module (324) transmits a second SID (SID2) to a conversion module (208b) to enable the conversion of packets received from and transmitted to all UEs (102) connected to the gNodeB (106b) (1102). The BGP module (324) transmits a third SID (SID3) to a conversion module (208c) to enable the conversion of packets received from and transmitted to all UEs (102) connected to the gNodeB (106c) (1104). Each SID may have a corresponding SR policy that defines the conversion of packets as described above.

[0171] The BGP module (324) may also send VPNv4 / v6 updates corresponding individually to each gNodeB (106a, 106b, 106c) (1106, 1108, 1110). A VPNv4 / v6 update for a given gNodeB (106a-106c) may include the SID assigned to that gNodeB (106a-106c). The VPNv4 / v6 update may be sent to one or more routing modules (216) connected to the network (210). The routing module (216) may be a provider edge router (PE).

[0172] In some embodiments, each translation module (208a-208c) is assigned its own VRF by the BGP module (324). The VRF can be used to implement each GTP tunnel translated by the translation modules (208a-208c). The root identifier (RD) of each VRF allows the routing module (216) to determine where to send packets. When the UE (102) connects to the gNodeB (106) and the PFCP proxy (322) obtains the UE address for the UE (102), the BGP module (324) can determine the VRF (i.e., VRF table) into which the UE address should be imported. In some embodiments, the PFCP proxy (322) obtains an access network instance, and the VRF is selected as corresponding to that access network instance.

[0173] In some implementations, the BGP module (324) has separate VRF tables for each translation module (208a-208c). However, in some implementations, the routing module (216) has a single VRF, because the routing module (216) must be reachable to any translation module (208a-208c). Thus, when the BGP module (324) imports routes for each UE (102) into all VRFs (each VRF is associated with one of the translation modules (208a, 208b, or 208c)), the BGP module (324) will provide three VPN v4 / v6 updates to the routing module SRv6 (216) for each UE (102), namely, one for the translation module (208a), another for the translation module (208b), and yet another for the translation module (208c). In a typical implementation, there may be more translation modules (208). Then, the routing module (216) will import routes from all VPN v4 / v6 updates into a single VRF (each route has the same prefix (UE address) but has different next hop and SID corresponding to different translation modules (208a, 208b, 208c)).

[0174] When the translation module (216) receives a packet from the external network (214), the routing module (216) needs to select a route for the packet. However, the routing module (216) may not know which gNodeB (106) is connected to the UE (102) referenced by the UE address in the packet. Therefore, the routing module (216) may not be able to forward the packet correctly. Additionally, there is excessive memory usage from the routing module (216) storing updates for each translation module (208a, 208b, 208c) for each UE address.

[0175] In some embodiments, these problems are resolved by a PFCP proxy (322) and / or BGP (324) that determines which gNodeB (106) is connected to a given UE (102). Thus, BGP (324) can generate a single VPN v4 / v6 update for a VRF corresponding to the gNodeB (106) to which the UE (102) is connected, that is, which routing module (208a, 208b, 208c) is connected to the gNodeB (106). This resolves the problems identified above because the routing module (216) receives and stores only one route for each UE address from the single VPN v4 / v6 update.

[0176] As described below, the BGP module (324) receives PFCP information (gNB address, UE address) as described above and can receive VPN v4 / v6 updates for gNodeB addresses from each PE (1202a, 1202b, 1202c). Based on this, the BGP module (324) can determine which gNodeB (106) a given UE (102) is connected to. The BGP module can determine the route target (RT) value for each gNodeB address from the VPN v4 / v6 updates. Based on the RT value, the BGP module (324) can determine which VRF the UE route should be imported into.

[0177] FIG. 12a illustrates a network environment (1200). The illustrated network environment (1200) illustrates elements in addition to those illustrated in the network environment (100) and omits some of the elements illustrated in the network environment (100). In practice, the network environment may include all the elements illustrated in the network environments (100, 1200). The illustrated network environment (1200) may be used to more efficiently distribute routing information for traversing the network (210).

[0178] A UE (102) can be connected to any of the gNodeBs (106a-106c). Each gNodeB (106a-106c) can be connected to a provider edge router (PE) (1202a-1202c). Multiple gNodeBs (106a-106c) can also be connected to a single PE (1202a-1202c). Each PE (1202a-1202c) can be connected to a corresponding area (1104a-1104c). Each area (1104a-1104c) can be part of a network. Each area (1104a-1104c) can be a packet radio network, such as a GTP network, such that the packets transmitted through each area (1104a-1104c) are GTP packets as described above. Each PE (1202a-1202c) may have an associatively combined unique root target (RT), such as RT 1:1, RT 2:2, and RT X:X in the illustrated embodiments. The root targets are used to identify each PE (1202a-1202c) and to determine which routes to import into a given VRF. In particular, a VPN route may be labeled with one or more root targets, so that only routers or other network components labeled with one or more root targets will import the corresponding VPN route into their VRF.

[0179] Each area (1104a-1104c) can be connected to a conversion module (208a-208c). Each conversion module (208a-208c) can function as a conversion module (208), receive traffic from gNodeB (106), convert GTP packets into SRv6 packets, and transmit packets through the SRv6 network (210). Each conversion module (208a-208c), as described above, can also receive packets from the SRv6 network (210), convert packets into GTP packets using embedded information and / or SR policy, and forward the converted packets to gNodeB through the area (1104).

[0180] During operation, for each UE (102) connected to gNodeB (106a), for example, PE (1202a) (used to represent any of PEs (1202a-1202c)) transmits a VPNv4 / v6 update (1204). The VPNv4 / v6 update may include information such as the address of gNodeB (106a) (e.g., network layer reachability information (NLRI)). The VPNv4 / v6 update may further include the RT of PE (1202a). In some embodiments, the VPNv4 / v6 update may list the N4 access network instances to which PE (1202a) is connected. The VPNv4 / v6 update may be transmitted via a route reflector (RR). The root reflector (1206) can forward VPNv4 / v6 updates to a conversion module (208a) connected to the same area (1104a) as the PE (1202a) (1208). The root reflector (1206) can also forward VPNv4 / v6 updates to a PFCP proxy (322) (1210).

[0181] In some embodiments, the root reflector (1206) forwards the VPNv4 / v6 update to the UPF (112) (1210). The PFCP proxy (322) intercepts the VPNv4 / v6 update when snooping on session information for packets to / from the UPF (112). The PFCP proxy (322) may hold each VPNv4 / v6 update. This may even be the case where the VRF of the VRF corresponding to the RT of the PE (1202a) received with the VPNv4 / v6 update is not configured (or the PFCP proxy (322) has not been notified of the configuration).

[0182] FIG. 12b illustrates an exemplary relationship between entities within a network (1200) and various labels and addresses used. BGP (324) may maintain a VPN table (1220) and a VRF table (1222). The VPN table (1220) stores data received as VPNv4 / v6 updates. The VPN table (1222) may include, for example, a hierarchy of root identifiers (1224) for VPNs identified in VPNv4 / v6 updates. One or more root identifiers (1224) may have a routing information base (RIB) (1226) associated with them. The RIB (1226) may list gNodeB addresses associated with the root identifier (1226) for the root identifier (1226), for example, due to the gNodeB address (1228) and root identifier (1226) received in a VPNv4 / v6 update. An entry in the VPN table (1220) for each gNodeB address (1228) may include one or more path attributes, such as NLRI root and / or address, next hop information, priority information (e.g., MED information), etc. The path attributes for each gNodeB address (1228) may further include one or more root targets (1230). For example, a VPNv4v6 update containing a gNodeB address (1228) may further include the root target (1230) of the PE that sent the VPNv4 / v6 update. Accordingly, RT (1230) can be associated with the corresponding gNodeB address (1228) and stored in the RIB (1226). In some embodiments, the root target sent with the VPNv4 / v6 update may include information describing an extended root target community including the PE (1202a-1202c) that sent the VPNv4 / v6 update.Accordingly, each RT (1230) of the VPN table (1220) may contain information describing an extended root target community.

[0183] The VRF table (1222) may include entries (1232) describing VRFs identified in VPNv4 / v6 updates received from PEs (1202a-1202c). For example, as mentioned above, the VPNv4 / v6 update may include the gNodeB address and RT of one of the PEs (1202a-1202c). In some embodiments, the VPNv4 / v6 may include an N4 access network instance to which the PEs (1202a-1202c) are connected. Accordingly, each entry (1232) may list the gNodeB address and RT for each VRF. In some embodiments, each VRF corresponds to an N4 access network instance, and the entry (1232) may identify this N4 access network instance. Multiple VRFs may exist for a given N4 access network instance. For example, each VRF table may correspond to a given N4 access network instance.

[0184] FIG. 13 illustrates a method (1300) that can be performed by a PFCP proxy (322) and a BGP module (324) associated therewith. The method (1300) may include a step (1302) of obtaining a gNodeB address and an associated UE address from PFCP session information. As previously described, the PFCP session may further identify an N4 access network instance. Then, the method (1300) may include a step (1304) of looking up a gNodeB address in a VPN table (1220) and a step (1306) of obtaining a path identifier (1224) of the VPN mapped to the gNodeB address in the VPN table (1220). The method (1300) may further include a step (1308) of obtaining a root target (1230) mapped to the gNodeB address in the VPN table (1220). The method (1300) may include the step (1310) of obtaining a VRF table corresponding to an N4 access network instance identified in PFCP session information. The method (1300) may include the step (1312) of identifying a VRF matched to a root target (1230) from step (1308). Then, the method (1300) may include the step (1314) of importing a UE address into the VRF identified in step (1312). The step (1314) of importing a UE address into the VRF may involve the BGP module (324) sending a VPN v4 / v6 update for the VRF to the routing module (216) to indicate a route to the UE address.

[0185] In this way, UE addresses are not unnecessarily imported into each VRF of the N4 access network instance to which gNodeB (106) is connected. This reduces the size of VRF tables on the routing modules (216) and the number of corresponding SR policies and SIDs that need to be sent to the translation modules (208a-208c).

[0186] Note that in some embodiments, once the VRF for the UE address is obtained, other operations may be performed, such as generating an SR policy and a corresponding binding SID for the translation module (208a-208c) to which the gNodeB (106) corresponding to the gNodeB address is connected. The SR policy and the binding SID may be generated according to the approach described above.

[0187] FIG. 14 is a block diagram illustrating an exemplary computing device (1400) that may be used to implement the system and method disclosed herein. The computing device (1400) may function as a server, a client, or any other computing entity. The computing device may perform various functions as discussed herein and may execute one or more application programs, such as the application programs described herein. The computing device (1400) may be any of a wide variety of computing devices, such as a desktop computer, a notebook computer, a server computer, a handheld computer, a tablet computer, etc.

[0188] The computing device (1400) includes one or more processor(s) (1402), one or more memory device(s) (1404), one or more interface(s) (1406), one or more mass storage device(s) (1408), one or more input / output (I / O) device(s) (1410), and a display device (1430), all of which are coupled to a bus (1412). The processor(s) (1402) include one or more processors or controllers that execute instructions stored in the memory device(s) (1404) and / or mass storage device(s) (1408). The processor(s) (1402) may also include various types of computer-readable media, such as cache memory.

[0189] The memory device(s) (1404) include various computer-readable media such as volatile memory (e.g., random access memory (RAM) (1414)) and / or non-volatile memory (e.g., read-only memory (ROM) (1416)). The memory device(s) (1404) may also include rewritable ROM such as flash memory.

[0190] Mass storage device(s) (1408) include various computer-readable media such as magnetic tape, magnetic disk, optical disk, solid-state memory (e.g., flash memory). As illustrated in FIG. 14, a specific mass storage device is a hard disk drive (1424). Various drives may also be included in the mass storage device(s) (1408) to enable reading from and / or writing to various computer-readable media. The mass storage device(s) (1408) include removable media (1426) and / or non-removable media.

[0191] I / O device(s) (1410) include various devices that enable data and / or other information to be input into or retrieved from the computing device (1400). Exemplary I / O device(s) (1410) 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 image capture device, etc.

[0192] The display device (1430) includes any type of device capable of displaying information to one or more users of the computing device (1400). Examples of the display device (1430) include a monitor, a display terminal, a video projection device, etc.

[0193] Interface(s) (1406) include various interfaces that enable the computing device (1400) to interact with other systems, devices, or computing environments. An exemplary interface(s) (1406) includes any number of different network interfaces (1420), such as interfaces for a local area network (LAN), a wide area network (WAN), a wireless network, and the Internet. Other interface(s) include a user interface (1418) and a peripheral device interface (1422). Interface(s) (1406) may also include one or more user interface elements (1418). Interface(s) (1406) may also include one or more peripheral interfaces, such as interfaces for a printer, a pointing device (a mouse, a trackpad, etc.), a keyboard, etc.

[0194] The bus (1412) enables processor(s) (1402), memory device(s) (1404), interface(s) (1406), mass storage device(s) (1408), and I / O device(s) (1410) to communicate with each other, as well as with other devices or components coupled to the bus (1412). The bus (1412) represents one or more of several types of bus structures, such as a system bus, a PCI bus, an IEEE 1394 bus, a USB bus, etc.

[0195] For the purposes of illustration, programs and other executable program components are illustrated herein as individual blocks, but it is understood that these programs and components may reside in different storage components of the computing device (1400) at various times and are executed by the processor(s) (1402). Alternatively, the systems and procedures described herein may be implemented in hardware, or a combination of hardware, software, and / or firmware. For example, one or more application-specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and procedures described herein.

Claims

Claim 1 A method comprising: receiving session information including a component address, a user device address, and a virtual routing function (VRF) identifier by a computing device, wherein the component address is the address of a first component of a radio packet network connected by a cellular wireless network to a user device having the user device address; receiving a virtual private network (VPN) update including the component address and a route target for the component address by the computing device; matching the route target to the VRF identifier using the component address by the computing device; and importing the user device address to the VRF identified by the VRF identifier in response to matching the route target to the VRF identifier by the computing device. Claim 2 A method according to claim 1, further comprising the step of preventing the computing device from importing the user equipment address into any VRF other than the VRF identified by the VRF identifier. Claim 3 A method according to claim 1, further comprising the step of providing a plurality of peripheral equipment components each coupled to one or more of a plurality of cellular data network components, wherein the first component is one of the plurality of cellular data network components, and the step of importing the user equipment address to the VRF identified by the VRF identifier in response to matching the root target to the VRF identifier includes the step of importing the UE address to one or more peripheral equipment components connected to the first component. Claim 4 A method according to paragraph 3, wherein one or more peripheral equipment components are translation modules programmed to convert packets between a packet radio protocol and an internet protocol. Claim 5 In paragraph 4, the above packet radio protocol is a GTP (GPRS (general packet radio service) Tunneling Protocol) packet, a method. Claim 6 In paragraph 5, the method wherein the internet protocol is SRv6 (Segment Routing over Internet Protocol v6). Claim 7 In paragraph 3, the step of receiving the VPN update includes the step of receiving the VPN update from one or more peripheral equipment components. Claim 8 In claim 7, the step of receiving session information includes receiving session information intercepted by a Packet Forwarding Control Protocol (PFCP) module. Claim 9 In claim 8, the step of receiving the session information comprises the step of receiving the session information from a Border Gateway Protocol (BGP) module. Claim 10 A method according to claim 1, wherein the first component is a gNodeB of a 5G cellular data network. Claim 11 A system comprising one or more computing devices, wherein each computing device comprises one or more processing devices and one or more memory devices coupled to said one or more processing devices, said one or more computing devices are programmed to perform a method, said method comprising: receiving session information including a component address, a user device address, and a virtual routing function (VRF) identifier, wherein the component address is the address of a first component of a radio packet network connected by a cellular wireless network to a user device having a user device address; receiving a virtual private network (VPN) update including said component address and a root target for said component address; matching said root target to said VRF identifier using said component address; and in response to matching said root target to said VRF identifier, importing said user device address into a VRF identified by said VRF identifier. Claim 12 A system according to claim 11, wherein the one or more computing devices are further programmed to perform the method by preventing the user equipment address from being imported into any VRF other than the VRF identified by the VRF identifier. Claim 13 A system according to claim 11, further comprising the step of providing a plurality of boundary equipment components each coupled to one or more of a plurality of cellular data network components, wherein the first component is one of the plurality of cellular data network components, and the one or more computing devices are further programmed to perform the method by importing the user equipment address into the VRF identified by the VRF identifier in response to matching the root target to the VRF identifier, and the importing the user equipment address into the VRF includes importing the UE address to one or more peripheral equipment components connected to the first component. Claim 14 In paragraph 13, the system wherein one or more of the peripheral equipment components are conversion modules programmed to convert packets between the packet radio protocol and the internet protocol. Claim 15 In paragraph 14, the above packet radio protocol is a system in which the packet radio protocol is a GTP (GPRS (general packet radio service) tunneling protocol) packet. Claim 16 In paragraph 15, the above internet protocol is a system that is segment routing via internet protocol v6 (SRv6). Claim 17 In paragraph 13, the system receiving the VPN update includes receiving the VPN update from one or more peripheral equipment components. Claim 18 A system according to claim 17, wherein receiving the session information includes receiving session information intercepted by a packet forwarding control protocol (PFCP) module. Claim 19 In paragraph 18, the system receiving the session information includes receiving the session information from a Border Gateway Protocol (BGP) module. Claim 20 In paragraph 11, the system, wherein the first component is a gNodeB of a 5G cellular data network.

Images