CN117529709A

CN117529709A - PFCP session load balancer

Info

Publication number: CN117529709A
Application number: CN202280041547.9A
Authority: CN
Inventors: 科约·帕特尔; 村上哲也
Original assignee: Alcus Ltd
Current assignee: Alcus Ltd
Priority date: 2021-04-26
Filing date: 2022-04-20
Publication date: 2024-02-06

Abstract

The introduction of the UE address into the VRF of the peripheral device is facilitated by receiving a VPN update from the peripheral device that includes the route target and the gmodeb address of the peripheral device. In addition, 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 gndeb to which the UE is connected. By matching the gNodeB address and session information from the VPN update, the route target of the peripheral device to which the UE is connected can be determined. The UE address may then be exclusively imported into the VRF of the peripheral device.

Description

PFCP session load balancer

Cross Reference to Related Applications

This application is a continuation of the portion of U.S. patent application Ser. No. 17/488,833 filed on month 29 of 2021, the portion of U.S. patent application Ser. No. 17/362,071 filed on month 6 of 2021, and the portion of U.S. patent application Ser. No. 17/240,726 filed on month 26 of 2021, the disclosures of which are incorporated herein by reference in their entirety.

Technical Field

The present application relates to routing of data packets (packets) to and from a cellular data communication network.

Background

Referring to fig. 1A, in a conventional 5G cellular data communication network 100, a User Equipment (UE) 102 may transmit a data packet of a gNodeB 106, and the gNodeB 106 performs a function of receiving the data packet through a radio antenna and transmitting the data packet to an IP network 110 through a Gateway (GW) 108. In a conventional cellular data communication network, data packets from the UE 102 must be forwarded to a User Plane Function (UPF) 112, i.e., the UPF 112 associated with the GW 108 that originally received the data packets. UPF 112 may receive data packets over network 110, and network 110 may be an Internet Protocol (IP) network 110 between the UPF and GW 108. The UPF 112 may forward the data packets over another IP network 114 to a Mobile Edge Computing (MEC) server 116. The MEC server 116 may be the destination of the data packets, e.g., a server providing services addressed by the data packets or a gateway for accessing a wider network (e.g., the internet).

Referring to fig. 1B, in some cases, it may be desirable to redirect a data packet from the MEC server 116 associated with the UPF 112 to another MEC server 118. For example, GW 108 may also be connected to one or more IP networks 120 that couple MEC server 118 with GW 108. When the MEC server 116 fails or is redirected for some other purpose, the data packets may be redirected to the MEC server 118. However, current 5G protocols require that the data packet be routed to the UPF 112 first, and then the UPF 112 will forward the data packet 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 data packets transmitted to the UE 102 and from the UE 102.

It would be an advance in the art to provide an improved method for handling data packet redirection in a cellular communication network.

Drawings

In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

Fig. 1A is a schematic block diagram illustrating the routing of data packets received over a cellular data communication network according to the prior art;

fig. 1B is a schematic block diagram illustrating rerouting of data packets received over a cellular data communication network in accordance with the prior art;

fig. 2 is a schematic block diagram illustrating a method for routing data packets received over a cellular data communication network in accordance with an embodiment of the present invention;

FIG. 3 is a schematic block diagram of components for performing routing of data packets received over a cellular data communications network in accordance with an embodiment of the present invention;

fig. 4 is a schematic block diagram illustrating monitoring of information by a PFCP proxy and programming of translation and routing modules using the information in accordance with an embodiment of the present invention;

figure 5 is a schematic block diagram of a PFCP proxy according to an embodiment of the present invention;

fig. 6 is a schematic block diagram illustrating information exchange between a PFCP proxy and a routing/SDN controller in accordance with an embodiment of the present invention;

FIG. 7A is a schematic block diagram illustrating the propagation of external routing information to a translation module in accordance with an embodiment of the present invention;

FIG. 7B is a schematic block diagram illustrating programming of a translation module for routing data packets to an external network in accordance with an embodiment of the present invention;

FIG. 7C is a schematic block diagram illustrating programming of a routing module for routing data packets to an external network in accordance with an embodiment of the present invention;

FIG. 7D is a schematic block diagram illustrating programming of a translation module for routing data packets to an external network in accordance with an embodiment of the present invention;

fig. 8 is a schematic block diagram showing a configuration of a conversion module according to an embodiment of the present invention;

fig. 9A is a schematic block diagram illustrating the conversion of GTP to SRv6 according to an embodiment of the present invention;

FIG. 9B is a schematic block diagram further illustrating the operation of a conversion module according to an embodiment of the present invention; and is also provided with

Fig. 9C is a schematic block diagram illustrating the conversion from SRv6 to GTP according to an embodiment of the present invention;

figure 10A is a schematic block diagram of a load balancing PFCP proxy according to an embodiment of the present invention;

fig. 10B is a flowchart of a method for performing load balancing of PFCP sessions according to an embodiment of the present invention;

FIG. 11 is a schematic block diagram illustrating non-selective distribution of routing information according to an embodiment of the present invention;

FIG. 12A is a schematic block diagram of a network environment for performing selective distribution of routing information in accordance with an embodiment of the present invention;

FIG. 12B illustrates an example relationship between entities in a network and various labels and addresses used;

Fig. 13 is a flowchart of a method of selectively distributing routing information according to an embodiment of the present invention; and is also provided with

FIG. 14 is a schematic block diagram of a computer system suitable for implementing a method according to an embodiment of the invention.

Detailed Description

It will be readily understood that the components of the present invention, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as illustrated in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout.

Embodiments according to the invention may be implemented as an apparatus, method or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module" or "system. Furthermore, the invention can take the form of a computer program product embodied in any tangible expression medium having computer-usable program code embodied in the medium.

Any combination of one or more computer-usable or computer-readable media may be utilized. 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 comprise any non-transitory medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages, and descriptive or markup languages, such as HTML, XML, JSON, may also be used. The program code may execute entirely on the computer system, on a stand-alone hardware unit, partly on a remote computer spaced apart from the computer or entirely on the remote computer or server as a stand-alone software package. 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 the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions or code. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a non-transitory computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Referring to fig. 2, in some embodiments, the data packet from the UE 102 is formatted as a general packet (packet) radio service (general packet radio service, GPRS) data packet when received by the gmodeb 106. The gNodeB 106 can control the functions of RUs (radio units, i.e., antennas), DUs (distributed units), and CUs (centralized units), and manage packet transmissions between the UE 102 and the network 110. The gNodeB 106 can then encapsulate these data packets within GPRS Tunneling Protocol (GTP) packets, which are then forwarded to the UPF 112. Path 204 shows the path of packets sent to and from the UPF 112. Path 206 illustrates a path of packets redirected, for example, to and from the MEC server 118 or other destination other than fig. 1B.

The data packets output by the gNodeB 106 may be processed by a translation module 208. In the illustrated embodiment, the translation module 208 translates back and forth between GTP and an Internet protocol (i.e., a protocol that is not suitable for use in a cellular data network and that is not GTP). In the illustrated embodiment, the internet protocol is SRv (data plane) segment routing via IPv6 data plane. In the following description, it should be understood that the transition between GTP and SRv6 may be replaced with a transition between GTP and other internet protocols.

The translation module 208 may be interposed between the gNodeB106 and the SRv network 210 (e.g., to route data planes and/or networks implemented according to SRv or other IP protocols). The UPF 112 may be connected to the SRv network 210 through another conversion module 212. Note that in some embodiments, the conversion module 208, network 210, and conversion module 208 may be part of a common computing device, i.e., mounted to a common chassis. The common computing device may be collocated with one or both of the antenna 104 and the gNodeB 106. The public computing device may also include an MEC server 116.

The network 210 may also be coupled to an external network 214, for example, through an internet protocol routing module 216. In the illustrated embodiment, the routing module 216 is a SRv router, although routers implementing other routing protocols may be used. In some embodiments, 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 to any third party server providing services to the UE 102.

In the illustrated embodiment, the portion of paths 204, 206 labeled "A" may communicate packets formatted as GTP packets (hereinafter "type A packets"). In addition to the payload data thus encapsulated, the type a data packet may include some or all of an internal Internet Protocol (IP) header, a GTP header, a UDP (user datagram protocol) header, and an external IP header. The inner IP header may be an IP header according to an IP protocol generated at the UE 102. The external IP header may be an IP header according to an IP protocol or a different IP protocol, which is generated by the gmodeb 106 and defines information for routing the type a data packet through the network 210 to the UPF 112, the MEC server 116, the MEC server 118, or the external network 214.

The portion of the paths 204, 206 labeled "B" may carry packets formatted as internet protocol packets, such as SRv packets (hereinafter "B-packets"). Such data packets may include an inner IP header as defined above, a segment routing header (SRH'), and an internet routing header (e.g., an IPv6 header). The SRH' of each B-type packet may be populated by the conversion module 208, 212 that generated the B-type packet that was converted from the a-type packet to include information from some or all of the GTP header, UDP header, and outer IP header of the a-type packet. In particular, the information stored in the SRH' may include data sufficient to convert B-type packets into a-type packets (GTP packets) by the other of the conversion modules 208, 212. The Ipv6 field may be a data packet formatted according to an Internet Protocol (IP) such as Ipv6 and includes information sufficient to route the data packet through an IP network such as network 210, including the source IP address, destination IP address, and other fields defined by Ipv6 or other internet protocols. This information may be obtained from the outer IP header of the type a packet from which the type B packet is obtained. The IPv6 packet may also include payload data from a type a packet.

The portion of path 206 labeled "C" may carry "C-type" packets formatted as internet protocol packets including the same field definitions as B-type packets, but where the SRH does not store information from the GTP header of the a-type packets and/or subsequently converted to B-type packets without using the information in the SRH field. As shown in fig. 2, packets sent from the MEC server 118 to the UE 102 may traverse the network 210 as B-type packets, while packets sent from the UE 102 to the MEC server 118 traverse the network 210 as C-type packets.

The portion of path 206 labeled "D" may carry a "D" packet formatted as an internet protocol packet including the inner IP header and payload data of a C-type packet from which the D-type packet was derived. In particular, the D-type data packets may include IP data packets received by the gNodeB 106 from the UE 102, from the MEC servers 116, 118, or from the external network 214.

The "direct inbound data packet" may be a data packet that passes through the gNodeB 106 and is not redirected, such as a data packet that moves from left to right along path 204 in FIG. 2. Direct inbound data packets are transmitted from the UE 102 to the gNodeB. The direct inbound data packet may be a D-type data packet, such as IPv4 or IPv6, when received by the gNodeB. When output by the gNodeB 106, the direct inbound data packet may be a type A data packet transmitted by the gNodeB 106 to the translation module 208. In particular, the type a packet may be a GTP packet encapsulating an IP packet received from the UE 102.

The conversion module 208 converts the type a direct inbound data packet to a type B data packet and transmits the type B direct inbound data packet to the UPF112 over the network 210 using information included in the outer IP header of the type a direct inbound data packet. As described above, information from the GTP field of the type a packet may be included in the SRH' field of the type B packet obtained from the type a packet so as to be able to be converted back to the type a packet. However, the type B packet itself may be a SRv packet instead of a GTP packet. The type B packet further includes an inner IP header and payload data from the type a packet.

The type B direct inbound packets may be routed to a conversion module 212, which conversion module 212 converts the direct inbound packets from the type B packets back to the type a packets using information stored in the SRH' of the type B packets. Specifically, the data in the SRH' field of the B-type packet is used to generate a GTP header of a GTP packet that includes the internal IP field of the B-type packet and payload data, the GTP packet being a-type direct inbound packet for the B-type direct inbound packet.

After conversion by the conversion module 212, the type a direct inbound packets are transmitted to the UPF112. The UPF112 may then decapsulate the direct inbound data packet to obtain an internal IP data packet (e.g., a D-type data packet received from the UE 102) and forward the D-type direct inbound data packet to the MEC server 116.

The "redirected inbound data packet" may be a data packet originating from the UE 102 as a D-type data packet and transmitted through the gmodeb 106, but which is redirected away from the MEC server 116, e.g., to the external network 214 and/or another MEC server 118 or a third party server. The redirected inbound data packet may traverse path 206 from top left to bottom right in fig. 2. When output by the gNodeB 106, the redirected inbound data packet may be a type A data packet transmitted by the gNodeB 106 to the translation module 208. The conversion module 208 converts the type a redirected inbound data packet into a type C data packet such that the type C redirected inbound data packet does not include information from the GTP or UDP header of the type a redirected inbound data packet. The conversion module 208 transmits the inbound data packets redirected to the MEC server 118 in the C-type, and the data packets are redirected to the MEC server 118, for example, through the routing module 216. The routing module 216 converts the C-type redirected inbound data packets into D-type data packets and sends the D-type redirected inbound data packets to the MEC server 118. As described above, the conversion may include decapsulating the D-packets encapsulated in the C-packets.

A "direct outbound packet" may be a packet that passes through UPF 112 and is transmitted to UE 102 through the gmodeb without responding to a redirected inbound packet or a portion of the same network flow as the redirected inbound packet. For example, packets from the MEC server 116 may be transmitted as directly outbound packets through the UPF 112. The direct outbound data packet may traverse path 204 from right to left along path 204 in fig. 2. The packets received by the UPF 112 from the MEC server 116 can be D-packets. When output by the UPF 112, the direct outbound packet may be an A-type packet encapsulating a D-type packet and transmitted by the UPF 112 to the conversion module 212. The conversion module 212 converts the type a direct outbound data packet to a type B data packet and transmits the type B direct outbound data packet to the gmodeb 106 over the network 210 using the information included in the IPv6 field of the type B data packet. The conversion may include converting the GTP packet to a SRv packet, the SRv packet including data from the GTP header of the GTP packet in the SRH' field of the SRv packet, the SRv packet further including the inner IP header of the GTP packet and the payload data of the GTP packet.

The type B direct outbound data packet may be routed by the conversion module 212 to the conversion module 208, where the conversion module 208 converts the type B direct outbound data packet back to the type a direct outbound data packet using information stored in the SRH' of the type B data packet. This may include converting the SRv packet to a GTP packet that encapsulates the inner IP header and payload data of the B-mode packet and includes data from the SRH' field in the GTP header.

After conversion via the conversion module 208, the type a direct outbound data packet is transmitted to the gNodeB 106. The gNodeB 106 can then decapsulate the type A data packet to obtain a type D direct outbound data packet and forward the type D direct outbound data packet to the UE 102. Decapsulation may involve extracting the inner IP header and payload data from the GTP data packet.

The "redirected outbound data packets" may be data packets originating from locations in the external network 214 to which the MEC server 118 or redirected inbound data packets are routed. The redirected outbound data packet may be sent in response to the redirected inbound data packet or as part of the same network flow of the redirected inbound data packet. For example, the redirected outbound data packet may be sent to the UE 102 by the MEC server 118 or a third party server. The redirected outbound data packet may traverse path 206 from bottom right to top left in fig. 2. The redirected outbound data packets may traverse paths to the translation module 208, for example, through some or all of the external network 214, the routing module 216, and the network 210. The redirected outbound data packet may be a D-type data packet that is converted to a B-type redirected outbound data packet by routing module 216 when received by routing module 216, and the B-type redirected outbound data packet is forwarded to conversion module 208 via network 210. The conversion may include encapsulating an inner IP header and payload data of the IP packet into a GTP packet.

The conversion module 208 converts the type B redirected outbound data packets into type a data packets and transmits the type a redirected outbound data packets to the gNodeB 106. The conversion from type B to type a may include using information stored in the SRH' of the type B packet. This may include converting the SRv packet to a GTP packet that encapsulates the inner IP header and payload data of the B-mode packet and includes data from the SRH' field in the GTP header. The gNodeB 106 can then decapsulate the type D redirected outbound data packet (inner IP header and payload data) from the type B redirected outbound data packet and transmit the type D redirected outbound data packet to the UE 102.

In some embodiments, the user plane message (user plane message) is a message for establishing and maintaining a session between the UPF 112 and the UE 102. The user plane messages may also include those messages transmitted by the UPF 112 to indicate routing of data packets to the UE 102 and the MEC server 116 and routing of data packets from the UE 102 and the MEC server 116 or redirecting of data packets to the external network 214. The user plane message may also convey 5G user plane messages such as echo requests, echo replies, error indications, or other user plane messages.

Inbound user plane messages may be routed as direct inbound data packets. The user plane messages transmitted from the UPF 112 may be considered in each case as direct outbound packets. When redirection occurs as indicated by the UPF 112, subsequent inbound data packets, i.e., non-user plane message packets, may be routed by the conversion module 208 bypassing the UPF 112 as redirected inbound data packets. The translation module 208 may identify the user plane message by performing a deep packet inspection of the inbound packet. Systems and methods for performing this routing are described in detail below.

Referring to fig. 3, the network path between the UE 102 and the external network 214 may be understood in terms of a control plane 300 and a data plane 302. Control plane 300 includes a number of modules and communications between these modules, and control plane 300 configures the modules of data plane 302 to transmit data packets in a predetermined manner. The data plane 302 includes modules and communications between the modules, and the data plane 302 transmits packets of payload data between the UE 102 and the external network 214. The modules of control plane 300 and data plane 302 may be implemented within a single device, within multiple devices coupled to a common circuit board or chassis, or within multiple devices connected to each other through one or more network connections. The illustrated components may run on a server, cloud computing platform, or other location, or be distributed across a combination of one or more of these components.

Control plane 300 and data plane 302 may also be divided into sections 304 and 306. Portion 304 may be understood as communicating data packets according to a protocol suitable for use in packet radio type communications ("packet radio portion 304"), i.e., communications using GPRS, GTP, or other cellular data communication protocols. In the illustrated embodiment, portion 304 implements a third generation partnership project (3 GPP) protocol for cellular data communications, although other cellular data communications protocols may be used.

Portion 306 may be understood as communicating data packets according to an internet protocol, such as the IPv6 protocol or other internet protocol ("IP portion 306") that is not suitable for use in packet radio type communications.

The control plane 300 of the packet radio section 304 may include the following components:

home subscriber server (HSS UDM) 308 with unified data management or other components for managing some or all of authentication, handover, IP Multimedia Subsystem (IMS) and Simple Message Service (SMS).

Policy Control Function (PCF) and/or Policy and Charging Rules Function (PCRF) 310 for managing access to the cellular data communication network according to a user subscription.

Access and mobility management function (AMF) and/or Mobility Management Entity (MME) 312 or other components for managing connections and mobility management tasks (e.g., handovers).

Session Management Functions (SMFs) and/or service and data packet gateways (SPGWs), such as SPGW-C) 312 (also referred to herein as "SMFs 314") or other components for managing user sessions with UPFs and for facilitating connection of packet radio networks to internet protocol networks.

SMF 314 may manage GTP session information and provide it to AMF 312.AMF 312 may program components in data plane 302 (gNodeB 106, described below) to route data packets according to GTP session information.

The data plane 302 of the packet radio portion 304 may include the following components:

gNodeB 106 or other hardware components that communicate directly with UE 102 through an antenna and encapsulate data packets from UE 102 into GTP data packets and may also implement user plane control protocols.

A translation module 208 for translating data packets back and forth between GTP and SRv6 as the data packets pass between packet radio portion 304 and IP portion 306.

The control plane 300 of the IP portion 306 may include the following components:

packet Forwarding Control Protocol (PFCP) proxy 322, described in more detail below.

Border Gateway Protocol (BGP) module 324 or for receiving and/or transmitting to fig. 3

Other components shown and/or other components of routing paths of other devices of any network described herein.

A user plane function control module (UPF N4) 326 or other components for terminating GTP connections and managing data packet transmissions between the packet radio network and the internet protocol network. UPF N4 326 facilitates establishing sessions with UPF 112.

The data plane 302 of the IP portion 306 may include the following components:

UPF 112 as described above.

The conversion module 208 operates in the sections 304 and 306.

Network 210.

A routing module 216.

The conversion module 212 is used to convert traffic sent to the UPF 112, as described above.

In the illustrated embodiment, packet forwarding associations according to PFCP may be coordinated between SMF 314 and UPF control module 326 through PFCP proxy 322. The SMF 314 and the UPF control module 326 may thus exchange session information through the PFCP proxy 322. The PFCP proxy 322 may snoop this information and provide it to the BGP module 324. Accordingly, the PFCP agent 322 may be associated with a PFCP implementation of the UPF control module 326 and with the SMF 314. BGP module 324 may use the snooped information to program data plane 302 (e.g., translation modules 208, 212, routing module 216) to perform conversions from GTP to IP protocol (e.g., SRv) and from IP protocol to GTP using the information snooped by PFCP proxy 322, as described below.

Existing software packages implementing PFCP are proprietary and not easily altered. Some open source software packages for implementing PFCP are available, but exist only as packages that must be incorporated into an application. In addition, the network stack of the UPF control module 326 can be implemented by a third party or open source software that is not easily modified, such as upg-vpp (user plane gateway vector packet processor).

In some embodiments, PFCP proxy 322, BGP module 324, and internal routing module 216 may be modified with respect to conventional implementations of such components in order to perform some or all of the following:

an association is established between the SMF 314 and the PFCP implementation of the UPF control module (UPF N4) 326.

Messages are transferred between the PFCP implementations of the SMF 314 and the UPF control module 326.

Snooping session messages of BGP module 324 to obtain information such as the address of UE 102, remote/local Tunnel Endpoint (TEP) address, tunnel Endpoint Identifier (TEID), and other information.

Fig. 4 further illustrates an example implementation of the PFCP proxy 322 and BGP module 324. In a conventional 5G mobile network, an association, such as a control channel, would be established between the AMF MME 312 and the UPF N4 326. A session, e.g., user plane information, will be established between the SMF SPGW 314 and the UPF N4 326. Once a session is established between the SMF SPGW 314 and the UPF N4 326, the UE 102 may begin transmitting payload traffic. The gNodeB 106 can then encapsulate the data packet from the UE 102 into a GTP data packet and forward the GTP data packet 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 from which the requests were received.

In conventional systems, it is difficult to optimize the path between the gNodeB 106 and the UPF 112 for the reasons described above: all UE traffic must be encapsulated into GTP packets and forwarded through UPF 112.

In some embodiments, the limitations of conventional 5G mobile networks are overcome by inserting a PFCP proxy 322 between the SMF SPGW 314 and the UPF N4326 such that the PFCP proxy 322 forwards 400 traffic between these components. Thus, PFCP proxy 322 receives PFCP messages from SMF SPGW 314 and forwards them to UPF N4 326. Likewise, PFCP agent 322 receives PFCP messages from UPF N4326 and forwards them to SMF SPGW 314. When it does so, the PFCP proxy 322 may parse the PFCP message in both directions to retrieve the user plane information.

The PFCP proxy 322 may then provide 402 user plane information to a routing/Software Defined Network (SDN) controller running outside the PFCP proxy 322. In the illustrated embodiment, the routing/SDN controller is implemented using 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 different computing devices. The PFCP proxy and route/SDN controller 324 may implement the route described above with respect to fig. 2 without further modification of the control plane 300, particularly the SMF SPGW-C314 and UPF N4 326. Specifically, SMF SPGW-C314 and UPF N4326 can exchange information to establish a 5G session through PFCP proxy 322 such that the operation of PFCP proxy 322 is not perceived by SMF SPGW-C314 and UPF N4 326.

BGP module 324 may program 404a conversion module 208 in the data plane based on the user plane information. The conversion module 208 may then bypass the UPF 112 to forward 406 the redirected packets to a redirected destination, such as the MEC server 118 or the external network 214, based on the path received from the BGP module 324, which is more optimized relative to conventional methods in which the packets were first routed through the UPF 112. The BGP module 324 may also program 404b the conversion module 212 to route control packets to the UPF 112 and program 404c the routing module 216 to route packets to and from the MEC server 118 or other devices connected to the routing module 216 through the external network 214.

For programming 404a, bgp module 324 provides the conversion module 208 with a route towards UPF 112 and also provides rules regarding how to convert GTP packets to SRv packets (i.e., type a packets to type B packets as described above). Thus, when the conversion module 208 receives a GTP data packet destined for the UPF 112, the conversion module 208 will apply the rules received from the BGP module 324 to perform the conversion.

For programming 404b, bgp module 324 may provide similar or identical rules to conversion module 212. Based on the rules, the conversion module 212 may convert SRv packets into GTP packets and recreate the original GTP packets that were sent to the UPF 112. BGP module 212 may also provide a route to translation module 212 towards enodebs 106. When UPF112 issues a GTP packet destined for gmodeb 106, conversion module 212 may convert the GTP packet to a SRv6 packet based on the rules described above and then forward the resulting SRv packet to conversion module 208. Conversion module 208 may convert SRv packets back to GTP packets based on the same rules and forward the resulting GTP packets to the gndeb 106.

For packets sent by the UE 102 to the external network 214 or the external MEC server 118, the routing module 216 may issue external routes to the external MEC server 118 and/or the external routing module 214 to the translation module 208. This may be done based on the standard L3VPN SRv6 approach. Thus, the translation module 208 may perform standard SRv encapsulation based on the UE-generated internal data packets.

For programming 404c, routing module 216 may implement a standard SRv router that may lack the ability to process GTP packets. Thus, programming 404c may include generating, by BGP module 324, a special service SID for SRv6 that contains GTP information (e.g., some or all of the GTP information that may be embedded in the SRH' header of the B-type packet). As described above, the redirected inbound data packets traversing the network 210 may be formatted as type B data packets. Thus, the programming 404c may program the routing module 216 to populate the SRH' field of the Srv6 header with GTP information, encapsulating each data packet received from the MEC server 118 or the external network 214 and addressed to the gNodeB 106.

For a response received from the external network 214 or the external MEC 118 and directed to the UE 102, the routing module 216 may encapsulate a response packet (IP packet, such as IPv4 or IPv 6) into a SRv packet. At this point, routing module 216 may use the special service SID provided by BGP 324. The SID contains the required GTP information that may be included in the SRH' header. Thus, the conversion module 208 may convert SRv6 packets into GTP packets and send the resulting GTP packets to the gNodeB 106.

Fig. 5 illustrates an example embodiment of a PFCP proxy 322. PFCP proxy 322 may parse the PFCP message to retrieve the 5G session information and process the message and forward the PFCP message to their destination as shown below. In some embodiments, the go-PFCP packet is used to parse the PFCP message. For example, in the illustrated embodiment, PFCP proxy 322 includes PFCP-request receiver 500, SMF-request forwarder 502, UPF-request forwarder 504, SMF-response receiver 506, UPF-response receiver 508, SMF-response forwarder 510, and UPF-response forwarder 512. Each of these components may be assigned to listen to a particular port of PFCP proxy 322 or transmit from a particular port of PFCP proxy 322. The operation of each component is described below.

When forwarding the PFCP message to UPF N4 326, PFCP agent 322 may overwrite the IP source address of the forwarded message with the address of the PFCP agent and overwrite the IP destination address as the IP destination 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, which is overwritten by the PFCP proxy 322, may then be sent to the UPF N4 326.

When forwarding the PFCP message to the SMF SPGW-C314, the PFCP proxy 322 rewrites the IP source address to the PFCP proxy's address, rewrites the IP destination address with the SMF SPGW-C314 IP destination address, and rewrites the UDP source port to the PFCP proxy's local port number. The PFCP proxy then sends the rewritten PFCP response to the SMF SPGW-C314.

By overwriting the messages 514, 516 in this manner, the SMF SPGW-C314 and UPF N4 326 communicate with the PFCP proxy 322. However, the PFCP proxy 322 may override the IP source/destination address and UDP source port such that the MF SPGW-C314 and UPF N4 326 cannot identify the PFCP proxy 322 at all.

The PFCP proxy 322 intercepts the PFCP message by listening on the UDP port 8805. UDP port 8805 is a port defined by 3GPP for receiving PFCP messages. Thus, when a different configuration is used, a different port may be substituted for the UDP port 8805 throughout the following description. The components of the PFCP proxy 322 may operate as follows:

The PFCP request receiver 500 listens for PFCP request messages 514, 516 sent from the SMF SPGW-C314 or UPF N4 326 to the UDP port 8805 (i.e., the port allocated for receiving PFCP messages) and records the source port (port a in the example shown) of the PFCP request 514 from the SMF SPGW-C314. The PFCP request receiver 500 may further record the source port (port B in the example shown) of the PFCP request 516 from the UPF N4 326. The source ports (ports X and Y, respectively) of messages 514, 516 may be preconfigured.

The SMF request forwarder 502 forwards the request 516 to the SMF SPGW-C314. The SMF request forwarder 502 is configured by the PFCP request receiver 500 to use X as a source port for forwarding the request 516 transmitted by the SMF request forwarder 502 to the SMF SPGW-C314. The SMF request forwarder 502 further modifies the forwarding request 516 by rewriting the IP destination address to the IP address of the SMF-SPGW-C314 and rewriting the IP source address to the IP address of the PFCP proxy 322.

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 forwarding request 516 transmitted by the UPF request forwarder 504 to the UPF N4 326. The UPF request forwarder 504 further modifies the forwarding request 514 by overwriting the IP destination address with the IP address of UPF N4 326 and the IP source address with the IP address of PFCP proxy 322.

The SMF response receiver 506 is configured to detect a PFCP response 518 from the SMF SPGW-C314 that is addressed to port X and provide the detected PFCP response 518 to the UPF response forwarder 512.

The UPF response receiver 508 is configured to detect a PFCP response 520 from UPF N4 326 that is posted to port Y and provide the detected PFCP response 520 to the SMF response repeater 510.

The SMF response forwarder 510 is programmed to forward the PFCP response 518 to the SMF SPGW-C314, wherein the source of the forwarded PFCP response 518 is set to UDP port 8805 and the destination is set to port a (the previously recorded source port of request 514). SMF response forwarder 510 further modifies forwarding response 518 by rewriting the IP destination address to the IP address of SMF SPGW-C314 and rewriting the IP source address to the IP address of PFCP proxy 322.

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

Referring to fig. 6, when the PFCP agent 322 forwards a message as described above with reference to fig. 4, the PFCP agent 322 may also listen for information about associations and sessions created using the message. This snooped information may then be provided to route/SDN controller 324 (BGP module 324). In the illustrated embodiment, inter-process communication (IPC) 600 is used to perform information transfer between PFCP proxy 322 and route/SDN controller 324. Such as the gRPC (an open source Remote Procedure Call (RPC) system). SDN controller 324 may program routing table 602 based on the monitored information.

The information that is monitored may include some or all of the following:

far Cheng Suidao endpoint (TEP), e.g. address of UPF 112

Local TEP, e.g. address of gNodeB 106

Tunnel Endpoint Identifier (TEID)

QFI (quality of service (QoS) flow identifier)

UE address (address of UE 102)

Access network instance

Core network instance

Upon receiving this information, the routing/SDN controller 324 may then generate a routing entry in the routing table 602 based on the information. These routing entries may be used to control the routing of the conversion modules 208, 212 and possibly the routing module 216 in order to implement the routing described above with reference to fig. 2 and 4.

Referring again to fig. 2, the desired routing may include receiving an internal IP packet from the UE 102 by the gmodeb 106, the gmodeb 106 generating a type a (GTP) packet including the internal IP packet. The gNodeB 106 transmits the type A data packet to the UPF 112 via a GTP tunnel between the gNodeB 106 and the UPF 112. Parameters defining the GTP tunnel are included in the above-listed monitored information, in particular the remote TEP referencing UPF 112 and the local TEP referencing gmodeb 106.

As described above with reference to fig. 2, rather than simply routing a type data packet through a GTP tunnel, a type a data packet is converted to a type B or C data packet and routed through IP network 210 (e.g., SRv network 210). The transition between the IP network 210 and the GTP tunnel is managed by the translation modules 208, 212. In addition, routing module 216 may also need to refer to parameters defining the GTP tunnel to route packets. The monitored information obtained by PFCP agent 322 may be provided to routing/SDN controller 324. The route/SDN controller 324 may then program the conversion modules 208, 212 and the routing module 216 to implement the routing described with reference to fig. 2. Various examples of how the routing/SDN controller 324 programs the conversion modules 208, 212 and the routing module 216 are described below.

In a first example, the route/SDN controller 324 receives the remote TEP and generates and distributes routes towards the UPF 112. In particular, the route may be provided to the translation module 208. In addition to programming 404a as described above, routing may also be provided to perform conversion between GTP and SRv 6.

In a second example, the route/SDN controller 324 receives the local TEP and UE address and generates and distributes a service SID based on this information according to SRv. In particular, the service SID may be provided to the routing module 216. The service SID publishes the route to the UE 102 via the local TEP-referenced gNodeB 106 over the network 210. The 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.

In a third example, the gNodeB 106 can send out a type A (GTP) packet within a GTP tunnel established with the UPF 112 by setting the destination of the packet to a remote TEP (tunnel endpoint address of the UPF 112). The PFCP proxy 322 obtains the remote TEP address by listening for control packets between the gmodeb 106 and the UPF 112 when setting up the GTP tunnel. The PFCP proxy 322 may give the remote TEP address to the route/SDN controller 324.

The route/SDN controller 324 may then generate a route entry for the remote TEP and program the conversion module 208 with the route entry. In some embodiments, route/SDN controller 324 may use a function such as gtp4.D to generate the route entry. The routing entry may define the conversion of a type a to B type packet, including encoding GTP header information into an SRH' header, and define the route through network 210 to conversion module 212, e.g., in the form of one or more SIDs according to a segment routing protocol (e.g., SRv).

In a fourth example, traffic routing from an ingress head end (PE) to an egress PE is managed based on the monitored information, as described below. The ingress PE may be, for example, a translation module 208 and the egress PE is a routing module 216 for connecting with an external network 214 or MEC server 118. In the opposite direction, the routing module 216 is an ingress PE and the conversion module 208 is an egress PE.

In a standard Virtual Private Network (VPN), such as L3VPN SRv6, the ingress PE issues SRv packets, SRv packets are packets received from the IP network. The destination address of the SRv packet may be set to an IP address assigned to the egress PE, such as an IPv6 address (e.g., a Segment Identifier (SID)). The egress PE receives SRv the packet, decapsulates the internal packet, and forwards the internal packet to the internal packet's destination address. In the illustrated example, the destination address of the internal data packet may be in the form of an IPv6 destination (e.g., SID). Thus, the egress PE may determine where to forward the internal data packet based on the destination address of the internal data packet, which may be a third party server or UE 102, depending on the direction in which the data packet is traveling through the network 210.

In the illustrated embodiment, the egress PE (e.g., translation module 208) may need to determine the gNodeB106 to which an internal packet in a set of available gNodeB instances should be forwarded in order to reach a particular UE 102. Thus, the egress PE may receive a routing entry from the routing/SDN controller 324 that maps the IP address of the UE 102 to the local TEP of the gNodeB106 to which the UE 102 is connected (e.g., TCP or other session is established). The association between the IP address of the UE 102 and the local TEP may be determined from the monitored information listed above.

The routing entry may instruct the egress PE to use the local TEP of the gmodeb 106 when performing a packet conversion from a C-type packet to an a-type packet and transmitting the resulting a-type packet to the gmodeb 106 over a GTP connection. For example, in the case of using GTP4.D (IPv 4 GTP), the routing/SDN controller 324 may provide the following IPv6 address to the egress PE:

SRv6 locator (< 56 bits) +TEID (32 bits) +QFI (8 bits) +local TEP Address (32 bits)

The "SRv6 locator" may refer to a configuration on the route/SDN controller 324. Based on the SRv locator, the conversion modules 208, 212 can identify the conversion function they are to perform. For example, BGP 324 may allocate 2001:db8:48 as SRv6 locator for conversion between GTP and SRv. In this case, when the translation module 208, 212 generates SRv packets from GTP packets, it will use 2001:db8:48 as SRv locator and embed the TEID, QFI, TEP address of the GTP packet in the SRH' field. When the conversion module 208, 212 receives a SRv packet with a destination matching 2001:db8:48:48, the conversion module 208, 212 may understand SRv that the packet needs to be converted to GTP. The translation modules 208, 212 may obtain TEID, QFI, TEP addresses from the SRH' field and then regenerate the original GTP data packet. The GTP packet may then be sent to either the UPF 112 or the gmodeb 106 to which it is addressed.

For multi-path label switching (MPLS) in an L3VPN, a SRv locator may be used to designate a given VPN. In the case of SRv L3 VPNs, the SRv6 locator may specify the service SID (IPv 6 address format) and may be used to specify the labels of a given VPN rather than MPLS L3 VPNs.

The local TEP address may be embedded in the IPv6 address described above. The address may also be published to the ingress PE as a service SID. When the egress PE receives a packet whose destination address matches the IPv6 address, the egress PE determines to which gNodeB instance the packet is forwarded, and may also obtain the local TEP address of the BBU and generate a GTP packet (type a packet) for transmission to the gNodeB instance. routing/SDN controller 324 may program the egress PE with routing rules (e.g., GTP4.D routing rules that direct how the egress PE performs the translation of IPv6 addresses into GTP packets).

To transition from SRv to GTP, the egress PE may use the following information: a local TEP address (address of the gNodeB 106), a TEID (tunnel identifier), and a QFI (QoS identifier). The local TEP address is the destination address of the GTP packet. TEID and QFI are values that need to be embedded in the GTP header. Thus, this information may be embedded in the IPv6 destination address (see example address above) of the data packet routed from the ingress PE to the egress PE to facilitate the conversion from SRv to GTP, which is carried in the IPv6 destination address.

This information (local TEP address, TEID, QFI) is obtained by PFCP proxy 322, provided to route/SDN controller 324, and then used by route/SDN controller 324 to program ingress PE and egress PE to embed the information and use the information to translate. The route/SDN controller 324 may do so by issuing a VPNv4/v6 route with an IPv6 address including embedded information as the service SID provided to the ingress PE. The routing/SDN controller 324 may also program this information in the egress PE in the form of SRv6 locators created using gtp4.E functions.

When the ingress PE receives a data packet from the IP network, the ingress PE may encapsulate the data packet from the IP network with SRv 6. At this time, the external IPv6 destination address is the service SID containing the embedded information described above. When the egress PE receives a packet whose external IPv6 destination matches the service SID described above, the egress PE may determine to perform a GTP4.E function on the received packet to convert the packet to a GTP (type a) packet using the TEID, QFI, and local TEP embedded in the IPv6 destination address.

In a fifth example, the routing module 216 may receive data packets addressed to the IP address of the UE 102 from the external network 214. The monitored information provides an association with the local TEP of the gmodeb 106. Thus, the route/SDN controller 324 may publish routes to the routing module 216 that direct the routing module 216 to route traffic addressed to the IP address of the UE 102 to the gndeb 106. The routing module 216 may then route the packet to the UE 102 through the gmodeb 106 according to path 206 of fig. 2 by switching between D, C and type a packets as described above.

In a sixth example, the monitored information may include a core network instance. This value may be used for network slices in the 5G core network. Based on this value, the route/SDN controller 324 may determine from which Virtual Route and Forwarding (VRF) table the UE address should be imported when executing programming 404c and which VPN (VRF) to use when generating the route to the UE 102. The access network instance in the monitored information may be used to filter out specific UE addresses from a given VRF table. Thus, the routing/SDN controller 324 may specify the import and/or filter rules based on the core network instance and the access network instance specified in the monitored information.

Referring to fig. 7A-8, the conversion module 208 manages packet conversion from SRv to GTP. In a typical 5G network, UPF 112 receives GTP packets from the gNodeB 106, UPF 112 obtains internal IP packets from the GTP packets, and the internal IP packets are then processed by SRv components to manage routing of the internal IP packets according to SRv, which may include using routing according to Virtual Routing Functions (VRFs). SRv6 components may be the target of inbound packets addressed to UE 102 and manage routing according to SRv and forward received packets to UPF 112 for encapsulation into GTP packets and forwarding to gmodeb 106.

In the methods described herein, data packets are routed to the conversion module 208 and from the conversion module 208 through the SRv network 210 and the external network 214. Thus, the translation module 208 may also manage routing of data packets according to SRv, including managing VRFs.

The method described herein refers to SRv6. However, it may also be implemented using labels according to multiprotocol label switching (MPLS).

Referring specifically to fig. 7A, routing module 216 may include or act as a route reflector client 700, such as BGP route reflector client. BGP module 324 (also referred to herein as route/SDN controller 324) may act as a route reflector and receive 702 route information broadcast by route reflector client 700. BGP module 324 may then reflect 704 this routing information to conversion module 208, such as by performing a standard routing reflector function. In some embodiments, routing module 216 sends VPNv4/v6 updates for external routes (i.e., routes to external IP addresses in external network 214) to BGP 324. BGP 324, operating as a route reflector, reflects VPNv4/v6 updates from routing module 216 to conversion module 208, with routing module 216 acting as a client. Based on this, the translation module 208 may obtain a route to the external network 214 via the routing module 216.

For example, the routing module 216 may update a route, such as a VPNv4/v6 route with a service SID. The route may describe a route with respect to the external network 214 and the service SID may indicate execution of a segment comprising VPNv4/v6 functions for data packets marked with the service SID. The routing may designate the routing module 216 as the next hop for one or more addresses in the external network 214 or provide an SR policy that directs the addition of a prefix SID to a data packet that includes one or more addresses, the prefix SID referencing a segment that directs the routing of the data packet to the routing module 216. Thus, when the route is provided to conversion module 208, it is able to receive GTP packets (type A packets of FIG. 7A) and decapsulate the internal IP packets.

The translation module 208 obtains the destination IP address of the internal IP packet and determines that the routing assignment should forward the packet addressed to the destination IP address to the routing module 216. The translation module 208 then forwards the internal IP packet as a SRv packet (type C packet of fig. 7A) with a SID specified by the route (e.g., a prefix SID of the routing module 216). The type C packets may be forwarded through the network 210 to the routing module 216. In the embodiments of fig. 7A-7D, the network 210 may be implemented as a level 3 (L3) VPN with SRv 6.

The routing module 216 receives the C-type data packet, decapsulates the internal IP data packet (the D-type data packet of fig. 7A) and forwards the internal IP data packet to the destination IP address through the external network 214.

In some embodiments, the BGP module 324 may also instruct the translation module 208 to perform AVPN services associated with the service SID of the VPN (VPNv 4/v 6).

Fig. 7B illustrates a method of managing traffic routing from the UE 102 to the UPF 112 through the conversion module 212 using the BGP module 324 and the conversion module 208. For example, 5G defines a GTP-U message. GTP-U messages may be used to check and/or detect data path information between the gmodeb 106 and the UPF 112. Other GTP-U messages include echo requests and echo replies to detect whether the data path is normal. GTP-U messages may also be used to communicate error indications in response to errors on the data path. The GTP-U message may include an end flag to inform the end of packet transfer (e.g., when a handoff occurs). In the case of user data traffic addressing the external network 214, the translation module 208 may strip the GTP header and encapsulate the internal IP packet in a SRv packet (type C packet) and then forward the type C packet directly to the translation module 212.

In other embodiments as described herein, BGP module 324 obtains 706 information from PFCP proxy 322 and/or CLI controller 708. The information related to the function of fig. 7B may include a remote TEP address of the GTP tunnel, VRFID (or route discriminator RD), and VPN information (VPNv 4/v6 information).

To enable processing of GTP-U messages by UPF 112 and/or gNodeB 106, conversion module 208 may forward GTP-U messages to UPF 112. As described above, this may include using the second conversion module 212 between the network 210 and the UPF 112. The conversion module 212 may convert the data packet from SRv to GTP before forwarding the GTP data packet to the UPF 112. To do this, GTP information may be embedded in the SRH field of the SRv packet (e.g., a B-type packet) forwarded to the conversion module 212.

Thus, the BGP module 324 may provide 710VPNv4/v6 updates to the conversion module 208 to provide routes to the UPF 112. BGP module 324 may also provide 712SR policies to conversion module 208 that instruct conversion module 208 to convert GTP packets addressed to UPF 112, including encoding GTP information in the SRH field, as described above. BGP module 324 may obtain VPNv4/v6 updates and GTP information from information received from PFCP proxy 322 as described above. Programming 710 may include providing VPNv4/v6 updates including routes to the UPF 112 to the conversion module 208. Programming 710 may include programming conversion module 208 with the route in the particular VRF. Based on this programming 710, the conversion module 208 may route the data packet from the gNodeB 106 to the UPF 112.

The programming 710 provided by the translation module 208 to the UPF 112 may further manage routing based on the VRF route specifier (RD) to which the gnob 106 is connected and the 5G network instance (access) to which the gnob 106 belongs. CLI controller 708 may provide a mapping between the first VRF RD to which the gNodeB106 is connected and the 5G network instance (access) to which the gNodeB106 belongs, and a second VRF RD for a destination IP address of an internal IP packet (e.g., an internal IP packet encapsulated by a GTP packet). The PFCP proxy 322 may provide the address of the UPF and the 5G network instance (access) to which the gNodeB106 belongs.

Using this information, BGP module 324 determines which VRF RD matches the 5G network instance (access, i.e., the network that includes UPF 112) provided by PFCP agent 322. BGP module 324 may then perform the following operations: sending a VPNv4/v6 update to the UPF route for the first VRF RD matching the 5G network instance (access) to the conversion module 208; and sends SR policies to notify translation module 208 of the translation rules described above (defining the translation from GTP to SRv with embedded GTP information) and of the internal IP packets to the second VRF RD associated with the destination address.

The SR strategy and VPNv4/v6 may program the conversion module 208 to perform the following functions:

Receiving a GTP packet addressed to UPF 112;

checking the packet type of the GTP packet;

if the packet type of the GTP packet is user data traffic, the GTP header is stripped to obtain an internal IP packet, which is forwarded using the routing table for VRF RD provided by BGP module 324 (e.g., standard L3VPN SRv6 forwarding is performed).

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

In some embodiments, the VPNv4/v6 update to the UPF address takes the binding SID value as the prefix SID. Thus, the VPNv4/v6 updates are coupled to a particular SR policy, i.e., the SR policy received from the BGP module 324. The SR policy received from BGP module 324 may also include the same binding SID and also include VRF RDs for internal IP packets. Based on this, when conversion module 208 receives a GTP packet whose destination matches the UPF address, conversion module 208 may apply an SR policy to the GTP packet.

In some embodiments, the SR policy may instruct the translation module 208 to evaluate whether the destination address of the internal IP packet is an IPv6 link-local address. If so, conversion module 208 may perform the same conversion from GTP to SRv according to the SR strategy as described above, and then forward to conversion module 212. However, since the link-local address is not globally routable, only the UPF 112 can handle such packets. Thus, the conversion module 208 needs to send the converted SRv data packets to the UPF 112. The SR policy may instruct the conversion module to check for each GTP packet whether the destination address of the internal IP packet is link-local, and if so, convert the GTP packet to a SRv6 packet while embedding GTP-related information in the SRH field of the SRv6 packet and forward the SRv6 packet to the conversion module 212. The conversion module then converts the SRv packet back to a GTP packet using the embedded information and forwards the GTP packet to UPF 112.

The conversion module may be programmed with a routing entry for the UPF address in a routing table associated with the first VRF RD (external VRF of the network to which gNodeB 106 is connected) based on the VPNv4/v6 update provided 710 by the BGP module 324. The SR policy provided at step 712 may associate a second VRF RD (an internal VRF of the network to which UPF 112 is connected) with the binding SID. The binding SID may apply the SR policy to the internal IP packet addressed to the UPF address and the second VRF RD. The binding SID may be used as the service SID for VPNv4/v6 updates for UPF addresses. The bonded SID may also be carried in the SR policy. The SR policy may carry an internal VRF RD that is used to route internal IP packets. Thus, in view of this programming, GTP packets received from the gNodeB 106 may be processed by the translation module 208 as follows:

performing a route lookup based on a destination address (UPF address) in a routing table associated with a VRF RD associated with an incoming interface through which the GTP packet is received;

obtaining an SR policy based on the binding SID, which is used as the service SID of the VPNv4/v6 update of the UPF address;

checking the message type;

if the message type is G-PDU, conversion module 208 strips the GTP header to obtain an internal IP packet, encapsulates the internal IP packet in a SRv packet, and routes SRv the 6 packet (internal VRF of the destination IP address of the internal IP packet) according to standard SRv L3VPN using a second VRF RD specified by the SR policy; and is also provided with

If the message type is GTP-U, the translation module 208 generates a special service SID carrying GTP related information such as UPF address, QFI, TEID, and SRv locator according to SR policy; the internal IP packet of the GTP packet is encapsulated in a SRv6 packet including the special service SID and SRv packets are sent to the translation module 212.

The special service SID may be formatted as [ SRv6 locator of destination ] [ UPF address+qfi+ted ], using gtp4.D. In the case of gtp6.D, the special service SID may be in the form of [ SRv locator of destination ] [ qfi+teid+sid0], where sid0 is the UPF address.

Fig. 7C illustrates the functionality of the BGP module 324, which BGP module 324 is configured to configure the routing module 216 to route data packets received from the external network 214 and addressed to the UE 102. When a packet is received by the routing module 216 from the external network 214 and addressed to the UE 102, the routing module may use a route associated with the address of the UE 102. The route may be provided to the routing module 216 by the BGP module 324 using the method illustrated in fig. 7C.

CLI controller 708 may provide 714 a mapping between VRF RD and 5G network instances (cores), such as VRF RD defined for network 210. The PFCP proxy 322 may provide the UE address and 5G network instance (core) including the gNodeB 106.

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

The BGP module 324 may assign a service SID for a UE route when issuing a VPNv4/v6 update for the UE route. Thus, in response to the VPNv4/v6 update, the routing module 216 will receive an internal IP packet from the external network 214 that includes the UE address. In response to receiving the internal IP packet including the UE address, the routing module 216 encapsulates the internal IP packet in a SRv packet including the service SID as the destination according to the indication of the updated VPNv4/v 6. The service SID will instruct the intervening component to route the data packet to the UE according to the route, which will include a translation module 208 and a gmodeb 206.

When the translation module 208 receives SRv the data packet from the network 210, the translation module 208 may need to translate SRv the data packet to a GTP data packet because the GTP data packet needs to be forwarded to the UE through the gndeb 106. The service SID may be encoded by BGP module 324 to carry GTP-related information, such as the address of the gmodeb, TEID, and QFI.

The IPv6 address is 128 bits. Thus, for GTP4.E (gNodeB address is IPv 4), 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, then 8 bits are left for QFI and 32 bits are left for TEID. In the case of GTP6.E, where the gndeb 106 has an IPv6 address, it may not be possible to embed the address of the gndeb 106 in a single IPv6 address along with GTP information. In this case, SRv6 can carry multiple segments (IPv 6 addresses) in the SRH. Thus, the last SID (SID [0 ]) in the SRH may be the IPv6 address of the gNodeB 106, and the penultimate SID (SID [1 ]) may carry the SRv locator, QFI, and TEID.

Fig. 7D illustrates the functionality of the BGP module 324, which BGP module 324 is configured to configure the translation module 208 to route data packets received from the external network 214 and addressed to the UE 102. These data packets may be received by the conversion module 208 from the routing module 216 via the network 210. BGP module 324 may further configure conversion module 208 to convert such packets from SRv to GTP.

BGP module 324 may receive 718 information from CLI controller 708, such as the SRv locator of GTP4/6.E and the external VRFs connected to the gNodeB for each VRF from which the UE address was imported.

BGP module 324 may provide SRv6 locator SRv6 locator identifying a function to be applied by conversion module 208, such as GTP4/6.E or GTP4.D functions that perform conversion as described above. SRv6 locators and corresponding translation functions may be provided to the translation modules 208, 212 by the BGP module 324. The SRv locator may be included in the service SID, as described above. BGP module 324 generates and transmits 720 the SR policy to conversion module 208. The SR policy contains various instructions.

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 location of the gNodeB address, QFI, TEID (e.g., whether these information items are located in SID [0] or SID [1 ]) in the service SID (or SIDs) embedded in the SRH field as described above with reference to fig. 7C. The SR policy may also carry a function such as a GTP4.E or GTP6.E function that instructs the translation module 208 to use the last segment of the SRH header to find the gmodeb address and perform the translation from SRv to GTP using the embedded GTP information. The SR policy generated by BGP module 324 may further provide an external VRF of the UE address for routing GTP packets to UE 102 after obtaining GTP packets by converting SRv packets to GTP according to the SR policy.

Fig. 8 shows an example configuration of the conversion module 208. The conversion module 212 may have a similar configuration. In the illustrated embodiment, data packets (e.g., GTP-U messages) received from the gNodeB 106 and transmitted to the UPF 112 may be processed by a first Forwarding Information Base (FIB) lookup module 800, GTP4/6.D processing modules 802, SRv, encapsulation module 804, and a second FIB lookup module 806. Data packets (e.g., non-GTP-U messages) received from the gndeb 106 and transmitted to the routing module 216 may be processed by the FIB lookup module 800, the GTP 4.6.D module 802, the third FIB lookup module 808, SRv encapsulation module 810, and the fourth FIB lookup module 812.

The first FIB lookup module 800 may evaluate the interface (IP address and VRF RD) on which the data packet was received. If the interface is associated with a bonded SID, then the SR policy associated with the bonded SID activates the processing of the GTP4/6.D module 802 for the data packet. Programming of the first FIB lookup module 808, generation of binding SIDs and SR policies, and programming of the GTP4/6.d module may be performed by the BGP module 324 as described above.

GTP4/6.D module 802 may be programmed with functions activated by SR policies. The function may evaluate the packet type of the GTP packet. If the packet is a GTP-U message, the packet is sent to SRv encapsulation module 804. SRv6 encapsulation module 804 may be programmed to convert the data packets from GTP data packets (type a) to SRv data packets with embedded GTP information (type B). Further details regarding how this encapsulation is performed are described below with reference to fig. 9A. SRv6 data packets generated by SRv encapsulation module 804 may be processed by second FIB lookup module 806. The second FIB lookup module 806 may evaluate SRv the destination address of the packet (i.e., the address of GTP/SRv6 212 preceding the UPF 112) and determine where to route the SRv6 packet. This may include using information from the VPNv4/v6 update to determine a next hop, VPN tunnel information, VRF RD, or other information for routing SRv data packets to UPF 112. As described above, VPNv4/v6 updates may be received from the BGP module 324. The conversion module 208 then transmits SRv the data packet according to the routing information obtained from the second FIB lookup module 806.

When the GTP 4/6.D module determines that the GTP data packet is not a GTP-U message, the GTP data packet may be processed by third FIB lookup module 808 after stripping the GTP/UDP/outer IP header. The third FIB lookup module 808 may lookup information for encapsulating the internal IP packet of the GTP packet in a SRv6 packet. This may include, for example, looking up a VPNv4/v6 route associated with the destination address of the internal IP packet and deciding on such SID to encapsulate the internal IP packet in a SRv6 packet. The SID may define the routing of SRv packets encapsulating the internal IP packets through the network 210 and may be generated based on routing information received from the BGP module 324. The internal IP packet and SID may be provided to SRv encapsulation module 810, and srv6 encapsulation module 810 encapsulates the internal IP packet and SID in SRv packets. SRv6 data packets may be processed by the fourth FIB lookup module 812.

The fourth FIB lookup module 812 can evaluate SRv the destination address of the packet (i.e., the address of the routing module 216) and determine where to route SRv the packet 6. This may include using information from the VPNv4/v6 update to determine a next hop, VPN tunnel information, VRF RD, or other information for routing SRv data packets to routing module 216 in order to reach an external address. As described above, VPNv4/v6 updates may be received from the BGP module 324. The conversion module 208 then transmits SRv the data packet according to the routing information obtained from the fourth FIB lookup module 812.

Fig. 9A illustrates a process for converting a GTP (type a) packet received by conversion module 208 into a SRv packet (type B) packet with embedded GTP information. As described above, 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 UPF 112). For gtp4.D, the SID contained in the SRH' field of the B-type packet may be as shown. In the case of GTP4.D, the single SID (SID 0 or first SID in SRH' field) includes a GTP4.D locator as described above, an external IP address (address of UPF 112), and GTP information, e.g., QFI, TEID, a sequence ID for certain GTP-U messages (e.g., GTP-U echo request/reply messages). In some embodiments, additional padding bits may be included. The QFI information may include QFI, R, and U values. QFI is a QoS (quality of service) flow identifier defined in 3 GPP. R is RQI (reflection QoS indication) defined in 3 GPP. The U bit is used to specify the PDU (protocol data unit) type of the GTP-U packet. For GTP6.D, two SIDs (SID [0] and SID [1 ]) may be used. SID [0] may include an external IP address (the address of UPF 112) and SID [1] may include embedded GTP information, e.g., QFI, TEID, sequence ID.

Fig. 9B illustrates the functionality of the conversion module 208 when processing SRv (type B packet) with embedded GTP information received from the routing module 216. FIB lookup module 812 receives the packet and determines the binding SID associated with the interface (source address and VRF RD) through which the packet was received. The SR policy associated with the bonded SID may invoke GTP4/6.E module 814.GTP4/6.E module 814 may convert SRv data packets to GTP (type a) data packets using the embedded GTP information. Programming of GTP4/6.E module 814 and binding SID and SR policies may be received from BGP module 324 as described above.

GTP packets may be processed by FIB lookup module 800, FIB lookup module 800 determining a VRF RD associated with a destination address (e.g., a gNodeB 106 address or a UPF address) and routing the GTP packets according to a routing table of the VRF RD. The FIB lookup module 800 may perform routing based on VPNv4/v6 updates received from the BGP module 324 as described above. Fig. 9B shows the packet flow for the downlink (external network 214 to UE 102 or UPF 112 to UE 100). For such packet flows, FIB lookup module 812 may be programmed to determine a routing entry that points to GTP4/6.E module 814.GTP4/6.E module 814 may then convert each SRv6 packet into a GTP packet. The GTP packet may then be routed to FIB lookup module 800.

Fig. 9C illustrates the conversion from a type B packet to a type a packet. The embedded information in the SRH' field is obtained. As described above, with respect to gtp4.E, this information will be contained in SID [0 ]. In the case of GTP6.E, this information will be contained in SID [1 ]. The GTP4.E locator in the SRH' field is associated with a GTP4.E function that performs translation using the external IPv4 destination address and embedded GTP information (QFI, TEID/sequence ID). The translation may include using an external IPv4 destination address (e.g., an address of a gmodeb) as an external IP destination address for the type a packet and including the embedded GTP information in the GTP field of the type a packet. The internal IP data packet may be forwarded to the address of the UE 102.

Fig. 8, 9A, 9B, and 9C are described with respect to the conversion module 208. The conversion module 212 also performs conversion between type a and type B packets and may function in a similar manner. Specifically, packets moving from the UPF 112 to the gNodeB106 may be converted in the same manner as packets from the gNodeB106 to the UPF 112. Packets moving from SRv, 216 to UE 102 may be processed in the same manner as packets from UPF 112 to gNodeB 208. In other words, when a packet is received from the network 210, the conversion module 208, 212 may perform a conversion from SRv to GTP regardless of the entity that is sending the packet (the other conversion module 208, 212 or the routing module 216).

Referring to fig. 10A, the method described herein may utilize PFCP proxy 322 to obtain information describing the GTP tunnel, which may then be embedded in SRv data packets. To connect 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 UPF 112. In existing approaches, an N4 interface is created for each UE 102. Thus, when used according to existing methods, the PFCP proxy 322 may create 2X N4 interfaces, where X is the number of UEs 102, because the PFCP proxy 322 implements connections to both the SMF 314 and the UPF 112. A given UPF 112 may manage thousands of UEs 102 such that the load placed on the PFCP proxy 322 may be very large.

In some embodiments, on the SMF 314 side, the PFCP session load balancer 1000 distributes traffic to multiple N4 controllers 1002. On the UPF 112 side, another PFCP session load balancer 1004 distributes traffic to multiple N4 controllers 1002. Each of the N4 controllers 1002 may implement a PFCP proxy 322. Specifically, each N4 controller 1002 may perform the functions attributed herein to PFCP 322 for traffic routed thereto. Traffic routed from the load balancers 1000, 1004 to the N4 controller 1002 may include PFCP requests and responses as described above with respect to fig. 1-5. The N4 controller 1002 may thus listen for session information as described above. The monitored information may include some or all of the address of the gNodeB 106, the address of the UPF 112, the address of the UE 102, the TEID, QFI, the access network instance, and the core network instance of the GTP tunnel.

The load balancer 1000, 10004, and N4 controller 1002 can execute on the same computing device, in different virtual machines or containers on the same computing device, or on different computing devices connected through a network.

Fig. 10B illustrates a method 1006 that may be performed using the load balancers 1000, 1004 and the N4 controller 1002. The method 1008 may include the ingress load balancer receiving 1008 an incoming data packet, such as a GTP data packet. For incoming packets addressed to the UPF 112 and received from the SMF 314, the ingress load balancer may be the load balancer 1000. For incoming packets addressed to the SMF 314 and received from the UPF 112, the ingress load balancer may be the load balancer 1004.

The ingress load balancer may then extract 1010 a tuple (tuple) from the incoming data packet. The tuple may be a set of values for distributing the data packet among the plurality of N4 controllers. The tuple may include some or all of the following information items from the incoming data packet: an IP source address, an IP destination address, a session identifier (SEID), and a fully qualified session identifier (fully qualified session identifier, FQ-SEID). The IP source address and IP destination address may be addresses of one of the SMF 314 and UPF 112, respectively, from which the incoming packet is received or to which the incoming packet is addressed. In some implementations, the plurality of SMFs 314 and UPFs 112 may transmit data packets to the ingress load balancer. In such an embodiment, load balancing may be performed using only the IP source address and the IP destination address. In the case where there is a single SMF 314 and a single UPF 112, SEID and/or F-SEID may be used and the source address may be ignored as well as the IP source address and IP destination address.

The ingress load balancer may then select 1012 one of the N4 controllers 1002 corresponding to the tuple. For example, the tuple may be input to a hash function, the output of which is an identifier of one of the N4 controllers 1002. The incoming data packet may then be transmitted 1014 to the selected N4 controller 1002. The selected N4 controller 1002 may then process 1016 the incoming data packet. This may include listening for session information and performing other functions of the PFCP proxy, such as those described above with reference to fig. 5, as well as any other functions attributed herein to the PFCP proxy 322. The N4 controller 1002 may generate an output packet in response to an input packet. The output data packet may then be transmitted 1018 by the N4 controller 1002 to the egress load balancer. For incoming packets addressed to the UPF 112 and received from the SMF 314, the egress load balancer may be the load balancer 1004. For packets addressed to the SMF 314 and received from the UPF 112, the egress load balancer may be the load balancer 1000. The egress load balancer may then forward the outgoing packet to the destination address of the outgoing packet, which may be the same as the destination address of the incoming packet.

Referring to FIG. 11, the above-described method may be practiced in the network environment shown where there are multiple gNodeBs 106a-106c and multiple conversion modules 208a-28c. Each conversion module 208a-208c may connect a region 1104a-1104c of the cellular data network with the network 210. Each gNodeB 106a-106c may be coupled to one of the conversion modules 208a-208c by means of one of the regions 1104a-1104 c.

Using the method described above, BGP module 324 transmits 1100 the first SID (SID 1) to one translation module 208a to effect translation of data packets received from and transmitted to all UEs 102 connected to the gmodeb 106 a. The BGP module 324 transmits 1102 a second SID (SID 2) to the translation module 208b to effect translation of data packets received from and transmitted to all UEs 102 connected to the gmodeb 106 b. The BGP module 324 transmits 1104 the third SID (SID 3) to the translation module 208c to effect translation of data packets received from and transmitted to all UEs 102 connected to the gmodeb 106 c. Each SID may have a corresponding SR policy defining packet transitions as described above.

The BGP module 324 may also transmit 1106, 1108, 1110 VPNv4/v6 updates corresponding to each gNodeB106a, 106b, 106c, respectively. The VPNv4/v6 update for a given gNodeB106 a-106c can include the SIDs assigned to that gNodeB106 a-106 c. The VPNv4/v6 update may be transmitted to one or more routing modules 216 connected to the network 210. Routing module 216 may be a provider edge router (PE).

In some implementations, the BGP module 324 allocates each of the conversion modules 208a-208c its own VRF. The VRF may be used to implement each GTP tunnel converted by conversion modules 208a-208c. The routing specifier (RD) of each VRF enables routing module 216 to determine where to send the packet. When the UE 102 connects to the gnob 106 and the PFCP proxy 322 obtains the UE address of the UE 102, the BGP module 324 may determine the VRF (i.e., VRF table) to which the UE address should be imported. In some embodiments, the PFCP proxy 322 obtains an access network instance and the VRF is selected to correspond to the access network instance.

In some implementations, the BGP module 324 has a different VRF table for each of the conversion modules 208a-208c. However, in some embodiments, routing module 216 has a single VRF, as routing module 216 must be able to reach any of conversion modules 208a-208c. Thus, if the BGP module 324 introduces routes for each UE 102 to all VRFs (each VRF associated with one of the conversion modules 208a, 208b, or 208 c), the BGP module 324 will provide three VPN v4/v6 updates to the routing module SRv6 216 for each UE 102, e.g., one for the conversion module 208a, another for the conversion module 208b, and yet another for the conversion module 208c. In a typical implementation, there may be more conversion modules 208. The routing module 216 will then import routes from all VPN v4/v6 updates into a single VRF (each route having the same prefix (UE address) but a different next hop and SID corresponding to a different translation module 208a, 208b, 208 c)).

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 involved in the UE address in the packet. Thus, the routing module 216 may not be able to forward the data packet correctly. In addition, the routing module 216 has excessive memory usage due to the update of each translation module 208a, 208b, 208c storing for each UE address.

In some embodiments, these problems are solved by the PFCP proxy 322 and/or BGP 324 determining which gNodeB 106 is connected to a given UE 102. Thus, BGP 324 may generate a single VPN v4/v6 update corresponding to the gnob 106 to which UE 102 is connected, i.e., a VRF for any of the routing modules 208a, 208b, 208c connected to that gnob 106. This solves the above problem, as the routing module 216 will only receive and store one route from each UE address of a single VPN v4/v6 update.

As described below, the BGP module 324 may receive PFCP information (gNB address, UE address) as described above, and VPN v4/v6 updates for the gndeb address from each PE 1202a, 1202b, 1202 c. Based on this, the BGP module 324 can find which gNodeB 106 a given UE 102 is connected to. The BGP module may determine a Route Target (RT) value for each gNodeB address based on VPN v4/v6 updates. Based on the RT value, BGP module 324 may determine to which VRF the UE route should be directed.

Fig. 12A illustrates a network environment 1200. The illustrated network environment 1200 illustrates elements other than 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 of the elements shown in the network environments 100, 1200. The network environment 1200 shown may be used to more efficiently distribute routing information for traversing the network 210.

The UE 102 may be connected to any one of the gnodebs 106a-106 c. Each gNodeB106a-106c may be connected to a provider edge router (PE) 1202a-1202c. Multiple gNodeBs 106a-106c may also be connected to a single PE 1202a-1202c. Each PE 1202a-1202c can be coupled to a corresponding region 1104a-1104c. Each of the regions 1104a-1104c may be part of a network. Each region 1104a-1104c may be a packet radio network, such as a GTP network, such that the data packets transmitted through each region 1104a-1104c are GTP data packets as described above. Each PE 1202a-1202c may have a unique Routing Target (RT) associated with it, such as RT 1:1, RT 2:2, and RT X:X in the illustrated embodiment. The route targets identify each PE 1202a-1202c and are used to determine which routes to import into a given VRF. In particular, a VPN route may be tagged with one or more route targets such that only routers or other network components tagged with one or more route targets will import the VPN route into their VRFs.

Each region 1104a-1104c may be connected to a conversion module 208a-208c. Each conversion module 208a-208c may function as a conversion module 208 and receive traffic from the gNodeB 106, convert GTP packets into SRv packets, and transmit the packets over the SRv network 210. As described above, each conversion module 208a-208c may also receive packets from the SRv network 210, convert the packets to GTP packets using embedded information and/or SR policies, and forward the converted packets to the gNodeB via the region 1104.

In operation, for each UE 102 connected to the gNodeB 106a, for example, the PE 1202a (acting as a representative of any of the PEs 1202a-1202 c) transmits 1204 a VPNv4/v6 update. The VPNv4/v6 update may include information such as the address of the gNodeB 106a (e.g., network Layer Reachability Information (NLRI)). The VPNv4/v6 update may further include the RT of PE 1202 a. In some embodiments, the VPNv4/v6 update may list the N4 access network instance to which the PE 1202a is connected. The VPNv4/v6 update may be transmitted through the Route Reflector (RR). The route reflector 1206 may forward 1208 the VPNv4/v6 update to the translation module 208a connected to the same region 1104a as the PE 1202 a. The routing reflector 1206 may also forward 1210 the VPNv4/v6 update to the PFCP proxy 322.

In some embodiments, the routing reflector 1206 forwards 1210 the VPNv4/v6 update to the UPF 112. The PFCP proxy 322 intercepts VPNv4/v6 updates while listening for session information about packets coming in and out of the UPF 112. The PFCP proxy 322 may keep every VPNv4/v6 update. This may be the case even if the VRF has not been configured by a VRF corresponding to the RT of PE 1202a received with the VPNv4/v6 update (or has not yet notified the PFCP proxy 322 of the configuration).

Fig. 12B illustrates an example relationship between entities in the network 1200 and various tags and addresses used. BGP 324 may maintain VPN table 1220 and VRF table 1222. The VPN table 1220 stores the received data as VPNv4/v6 updates. VPN table 1222 may include, for example, a hierarchy of route specifiers 1224 for VPNs identified in VPNv4/v6 updates. One or more of the route specifiers 1224 may have a Route Information Base (RIB) 1226 associated therewith. The RIB 1226 may list the gnob address associated with the route identifier 1226 for the route identifier 1226, e.g., due to the route identifier 1226 and the gnob address 1228 received in the VPNv4/v6 update. The entries in VPN table 1220 for each gndeb address 1228 may include one or more path attributes, such as NLRI route and/or address, next hop information, priority information (e.g., MED information), and so forth. The path attributes of each gNodeB address 1228 may further include one or more routing targets 1230. For example, a VPNv4v6 update including a gNodeB address 1228 can further include a route target 1230 of the PE that sent the VPNv4/v6 update. Thus, RT 1230 may be stored in RIB 1226 associated with the gNodeB address 1228. In some embodiments, the route targets sent with the VPNv4/v6 update may include information describing an extended route target group including the PE 1202a-1202c sending the VPNv4/v6 update. Thus, each RT 1230 of VPN table 1220 may include information describing an extended route target group.

VRF table 1222 may include an entry 1232 describing the VRF identified in the VPNv4/v6 update received from PEs 1202a-1202 c. For example, as described above, the VPNv4/v6 update can include a gNodeB address and an RT for one of the PEs 1202a-1202 c. In some embodiments, VPNv4/v6 can include an N4 access network instance to which PEs 1202a-1202c are connected. Thus, 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 entry 1232 may identify the N4 access network instance. There may be multiple VRFs for a given N4 access network instance. For example, each VRF table may correspond to a given N4 access network instance.

Fig. 13 illustrates a method 1300 that may be performed by the PFCP proxy 322 and the BGP module 324 associated therewith. Method 1300 may include obtaining 1302gNodeB address and associated UE address from PFCP session information. As described above, the PFCP session may further identify the N4 access network instance. Method 1300 may then include looking up 1304 the gNodeB address in VPN table 1220 and obtaining 1306 a route specifier 1224 for the VPN mapped to the gNodeB address in VPN table 1220. The method 1300 may further include obtaining 1308 a routing target 1230 mapped to the gNodeB address in the VPN table 1220. Method 1300 may then include obtaining 1310 a VRF table corresponding to the N4 access network instance identified in the PFCP session information. Method 1300 may include identifying 1312 a VRF that matches the routing target 1230 from step 1308. Method 1300 may then include importing 1314 the UE address into the VRF identified at step 1312. Importing 1314 the UE address into the VRF may be accompanied by BGP module 324 sending VPN v4/v6 updates of the VRF to routing module 216 indicating the route to the UE address.

In this way, it is not necessary to import a UE address into each VRF of the N4 access network instance to which the gNodeB 106 is connected. This reduces the size of the VRF table on the routing module 216 and the number of SIDs and corresponding SR policies that need to be sent to the conversion modules 208a-208 c.

Note that in some embodiments, once the VRF of the UE address is obtained, other actions may be performed, such as generating an SR policy and the corresponding bonded SID of the translation module 208a-208c to which the corresponding gndeb 106 is connected. The SR policy and the bonded SID may be generated according to the method described above.

Fig. 14 is a block diagram illustrating an example computing device 1400 that may be used to implement the systems and methods disclosed herein. Computing device 1400 may act 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 applications, such as those described herein. Computing device 1400 may be any of a variety of computing devices such as the following: desktop computers, notebook computers, server computers, hand-held computers, tablet computers, and the like.

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

The memory device 1404 includes various computer-readable media such as volatile memory (e.g., random Access Memory (RAM) 1414) and/or nonvolatile memory (e.g., read Only Memory (ROM) 1416). The memory device 1404 may also include a rewritable ROM such as flash memory.

Mass storage device 1408 includes a variety of computer-readable media such as magnetic tape, magnetic disk, optical disk, solid state memory (e.g., flash memory), and so forth. As shown in fig. 14, a particular mass storage device is hard disk drive 1424. Various drives may also be included in the mass storage device 1408 to allow reading from and/or writing to various computer-readable media. The mass storage device 1408 includes removable media 1426 and/or non-removable media.

I/O devices 1410 include a variety of devices that allow data and/or other information to be input to computing device 1400 or retrieved from computing device 1400. Example I/O devices 1410 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, etc.

Display device 1430 includes any type of device capable of displaying information to one or more users of computing device 1400. Examples of display device 1430 include a monitor, a display terminal, a video projection device, and the like.

The interface 1406 includes various interfaces that allow the computing device 1400 to interact with other systems, devices, or computing environments. Example interfaces 1406 include any number of different network interfaces 1420, such as interfaces to Local Area Networks (LANs), wide Area Networks (WANs), wireless networks, and the internet. Other interfaces include a user interface 1418 and a peripheral interface 1422. The interface 1406 may also include one or more user interface elements 1418. Interface 1406 may also include one or more peripheral interfaces, such as interfaces for printers, pointing devices (mice, touch pads, etc.), keyboards, etc.

The bus 1412 allows the processor 1402, memory device 1404, interface 1406, mass storage device 1408, and I/O device 1410 to communicate with each other and other devices or components coupled to the bus 1412. Bus 1412 represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.

For purposes of illustration, programs and other executable program components are illustrated herein as discrete blocks, although it is understood that such programs and components may reside at various times in different storage components of the computing device 1400, and are executed by the processor 1402. Alternatively, the systems and processes 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 or processes described herein.

Claims

1. A method, comprising:

receiving, by a first load balancer from a first entity, a first request referencing a second entity, the first load balancer running on a computer system comprising one or more processing devices;

selecting, by the first load balancer, a selected controller of a plurality of controllers running on the computer system;

transmitting, by the first load balancer, the first request to a selected controller;

implementing, by the selected controller, a Packet Forwarding Control (PFCP) session with respect to the request;

transmitting, by the selected controller, a second request corresponding to the first request to a second load balancer, the second load balancer running on the computer system; and is also provided with

Forwarding, by the second load balancer, the second response to the second entity.

2. The method of claim 1, wherein the computer system comprises a plurality of computing devices connected by a network.

3. The method of claim 2, wherein the first load balancer is running on a first computing device of the plurality of computing devices, the second load balancer is running on a second computing device of the plurality of computing devices, and the plurality of controllers is running on one or more third computing devices of the plurality of computing devices.

4. The method of claim 1, further comprising:

receiving, by the second load balancer, a first response to the second request from the second entity;

forwarding, by the second load balancer, the first response to a selected controller;

processing, by the selected controller, the first response according to the PFCP;

transmitting, by the selected controller, a second response corresponding to the first response to the first load balancer; and is also provided with

Forwarding, by the first load balancer, the second response to the first entity.

5. The method of claim 4, wherein the first request and first response are packets according to General Packet Radio Service (GPRS) tunneling protocol (GTP) packets.

6. The method of claim 5, wherein the first request is a session initiation request.

7. The method of claim 6, wherein processing the first request comprises extracting session information from the first request.

8. The method of claim 7, wherein the session information comprises a user equipment address.

9. The method of claim 7, wherein the session information comprises a tunnel endpoint identifier.

10. The method of claim 7, wherein processing the first request further comprises transmitting the session information.

11. The method of claim 10, wherein processing the first request comprises transmitting the session information to a Border Gateway Protocol (BGP) controller.

12. The method of claim 5, wherein the first entity is a Session Management Function (SMF).

13. The method of claim 5, wherein the second entity is a User Plane Function (UPF).

14. The method of claim 1, wherein selecting the selected controller comprises:

extracting information from the first request; and is also provided with

Selecting the selected controller corresponding to the information.

15. The method of claim 14, wherein the information comprises one or more of an Internet Protocol (IP) source address, an IP destination address, a session identifier (SEID), and a full defined session identifier (F-SEID).

16. The method of claim 14, wherein selecting the selected controller corresponding to the information comprises:

generating a hash according to the information; and is also provided with

The selected controller is identified as mapped to the hash.

17. A system, comprising:

one or more computing devices, each computing device comprising one or more processing devices and one or more memory devices coupled to the one or more processing devices, the one or more computing devices programmed to perform a method comprising:

receiving, by the first load balancer, a first request from the first entity referencing the second entity;

selecting, by the first load balancer, a selected controller from a plurality of controllers based on a hash generated from address information in the first request;

transmitting, by the selected controller, a second request corresponding to the first request to a second load balancer; and is also provided with

18. The system of claim 17, wherein the one or more computing devices further program the method by:

19. The system of claim 18, wherein the first request and first response are packets according to General Packet Radio Service (GPRS) tunneling protocol (GTP) packets; and is also provided with

Wherein processing the first request comprises:

extracting session information from the first request, the session information including a user equipment address and a tunnel endpoint identifier; and is also provided with

The session information is transmitted to a Border Gateway Protocol (BGP) controller.

20. The system of claim 17, wherein the address information comprises one or more of an Internet Protocol (IP) source address, an IP destination address, a session identifier (SEID), and a full-defined session identifier (F-SEID).