A service flow transmission method and device

Abstract

A method and apparatus for traffic flow transmission are disclosed. An egress router receives a first packet destined for an anycast address of an application server from an initial ingress router. The egress router sends the first packet to the application server. The egress router receives a second packet from the application server. The second packet is destined for the initial ingress router. The egress router inserts a sticky destination sub type length value (Sticky-Dst-SubTLV) into a destination option header of the second packet. The egress router sends the second packet with the Sticky-Dst-SubTLV to the ingress router.

Description

[0001] Cross-referencing related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 104,293, filed October 22, 2020, entitled “Network Layer Support For 5G Edge Computing Sticky Services,” and U.S. Provisional Patent Application No. 63 / 125,187, filed December 14, 2020, entitled “Network Layer Methods to ANYCAST Sticky Services,” both of which are incorporated herein by reference. Technical Field

[0003] This invention generally relates to telecommunications, and more specifically to a mechanism for consistent routing of flows between mobile devices moving between fifth-generation (5G) mobile network sites and application servers in data centers that are communicatively connected to the 5G network via Internet Protocol (IP) networks. Background Technology

[0004] Many modern mobile devices include those that support wireless internet connectivity. For example, mobile devices can access the internet through the 3G Partnership Program (3GPP). rd The latest generation of mobile networks is called fifth-generation (5G) mobile networks, which communicate using interfaces standardized by the Generation Partnership Project (3GPP). Mobile networks are used to enable mobile devices to move between locations by allowing them to exchange connections between mobile network towers. Generally, this movement can be accomplished without affecting connectivity. However, in some cases, certain types of wireless communication may encounter connectivity problems when mobile devices move between mobile network towers. Summary of the Invention

[0005] In one embodiment, the present application includes a method implemented by a user equipment (UE), wherein the method comprises: the UE sending a first packet to an anycast address of a server, the first packet associated with a sticky traffic flow; the UE receiving a second packet of the flow from the server, the second packet of the flow including an Internet Protocol extension header having a sticky destination sub type length value (Sticky-Dst-SubTLV), the Sticky-Dst-SubTLV including an address of an egress router connected to the server; the UE copying the Sticky-Dst-SubTLV into an IP extension header of a third packet of the flow; the UE sending the third packet with the Sticky-Dst-SubTLV.

[0006] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a communication from a UE, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to pointing to an IP address of a specific computer on the Internet. One problem with this approach is that certain services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), it is desirable to maintain the traffic of a communication flow between the UE and a particular application server, which is referred to herein as sticky traffic.

[0007] This embodiment includes mechanisms to support sticky traffic that connects to edge computing application servers sharing the same anycast address for different instances in different data centers. The disclosed mechanisms operate on ingress routers and egress routers. In one example, sticky traffic can be managed by relying on functionality at the UE. The UE sends a packet to an application server as part of a flow. The packet is forwarded through an initial ingress router and the egress router to the application server. The application server sends a response packet to the UE through the egress router. The egress router is preconfigured to identify the anycast address as being associated with sticky traffic. For example, an Edge Computing (EC) sticky traffic management system can configure various routers in the network with an anycast address and / or a sticky traffic identifier (ID) for sticky traffic. The egress router inserts a sticky destination sub type length value (Sticky-Dst-SubTLV) in a header of the response packet. The packet includes an additional destination address field that includes a destination address for forwarding the packet. The header can be a destination options header (or destination extension header), such as an IPv6 destination options header defined by the IPv6 protocol. The Sticky-Dst-SubTLV includes the IP address of the egress router. The egress router then forwards the packet to the UE through the initial ingress router. The UE copies the Sticky-Dst-SubTLV into subsequent packets belonging to the flow. In other words, the UE extracts the Sticky-Dst-SubTLV and inserts the extracted Sticky-Dst-SubTLV into subsequent packets belonging to the flow. The UE can extract the Sticky-Dst-SubTLV from each packet of the flow that it receives so that the UE can insert it into the next packet of the same flow. The UE can store the extracted Sticky-Dst-SubTLV for sending subsequent packets belonging to the same flow. The act of storing the extracted Sticky-Dst-SubTLV can not be required for every packet received from the server, can be performed when the UE receives a packet that responds to the first packet sent by the UE, or when the UE receives an updated egress router address specified in the Sticky-Dst-SubTLV. When the UE moves between 5G sites, the subsequent ingress router uses the egress router address in the Sticky-Dst-SubTLV to forward subsequent packets to the correct egress router.For example, the subsequent ingress router can use the egress router address to establish an IP tunnel with the egress router. All packets sent by the UE to the server can include the UE address as the source address specified in the fixed header and the server address (e.g., an anycast address) as the destination address specified in the fixed header. Correspondingly, all packets sent by the server to the UE can include the UE address as the destination address specified in the fixed header and the server address (e.g., an anycast address) as the source address specified in the fixed header.

[0008] Optionally, in any of the preceding aspects, in a possible implementation of the aspect, the IP extension header of the second packet is an Internet Protocol version six (IPv6) Destination Options header, and the Sticky-Dst-SubTLV is included in the IPv6 Destination Options header.

[0009] Optionally, in any of the preceding aspects, in a possible implementation of the aspect, the first packet, the second packet, and the third packet are sent by the UE to a first Protocol Data Unit (PDU) Session Anchor (PSA) in a first mobile network site, and the method further includes: copying, by the UE, the Sticky-Dst-SubTLV into an IP extension header of a fourth packet of the flow; and sending, by the UE, the fourth packet with the Sticky-Dst-SubTLV to a second PSA in a second mobile network site for delivery of the fourth packet to the server via the egress router specified in the Sticky-Dst-SubTLV.

[0010] Optionally, in any of the preceding aspects, in a possible implementation of the aspect, the Sticky-Dst-SubTLV includes a sticky type.

[0011] Optionally, in any of the preceding aspects, in a possible implementation of the aspect, the Sticky-Dst-SubTLV includes a flow label.

[0012] In one embodiment, the present application includes a method implemented by an ingress router, wherein the method comprises: the ingress router receiving, from a user equipment (UE), a first packet destined for an anycast address of a server, wherein the first packet is associated with a sticky traffic flow and includes an Internet Protocol extension header having a sticky destination sub type length value (Sticky-Dst-SubTLV), the Sticky-Dst-SubTLV including an address of an egress router; the ingress router determining that a destination of the first packet matches an access control list (ACL) for sticky traffic; and the ingress router sending the first packet according to the Sticky-Dst-SubTLV extracted from the first packet.

[0013] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, the UE receives the same traffic no matter which data center receives the UE’s communications. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in communications, and the network can use the anycast address to route the communications to the nearest application server. This is in contrast to pointing to an IP address of a specific computer on the Internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), traffic that wishes to maintain a flow of communications between the UE and a particular application server is referred to herein as sticky traffic.

[0014] This embodiment includes mechanisms to support sticky traffic that connects to edge computing application servers sharing the same anycast address for different instances in different data centers. The disclosed mechanisms operate on ingress routers and egress routers. In one example, sticky traffic can be managed by relying on functionality at the UE. The UE sends a packet to an application server as part of a flow. The packet is forwarded through an initial ingress router and the egress router to the application server. The application server sends a response packet to the UE through the egress router. The egress router is preconfigured to identify the anycast address as being associated with sticky traffic. For example, an Edge Computing (EC) sticky traffic management system can configure various routers in the network with an anycast address and / or a sticky traffic identifier (ID) for sticky traffic. The egress router inserts a sticky destination sub type length value (Sticky-Dst-SubTLV) in a header of the response packet. The packet includes an additional destination address field that includes a destination address for forwarding the packet. The header can be a destination options header (or destination extension header), such as an IPv6 destination options header defined by the IPv6 protocol. The Sticky-Dst-SubTLV includes the IP address of the egress router. The egress router then forwards the packet to the UE through the initial ingress router. The UE copies the Sticky-Dst-SubTLV into subsequent packets belonging to the flow. In other words, the UE extracts the Sticky-Dst-SubTLV and inserts the extracted Sticky-Dst-SubTLV into subsequent packets belonging to the flow. The UE can extract the Sticky-Dst-SubTLV from each packet of the flow that it receives so that the UE can insert it into the next packet of the same flow. The UE can store the extracted Sticky-Dst-SubTLV for sending subsequent packets belonging to the same flow. The act of storing the extracted Sticky-Dst-SubTLV can not be required for every packet received from the server, can be performed when the UE receives a packet that responds to the first packet sent by the UE, or when the UE receives an updated egress router address specified in the Sticky-Dst-SubTLV. When the UE moves between 5G sites, the subsequent ingress router uses the egress router address in the Sticky-Dst-SubTLV to forward subsequent packets to the correct egress router.For example, the subsequent ingress router can use the egress router address to establish an IP tunnel with the egress router. All packets sent by the UE to the server can include the UE address as the source address and the server address (e.g., an anycast address) as the destination address in the fixed header. Correspondingly, all packets sent by the server to the UE can include the UE address as the destination address and the server address (e.g., an anycast address) as the source address in the fixed header.

[0015] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the Sticky-Dst-SubTLV comprises a sticky type.

[0016] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the IP extension header of the second packet is an Internet Protocol version six (IPv6) Destination Options header, and the Sticky-Dst-SubTLV is inserted in the IPv6 Destination Options header.

[0017] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, prior to sending the first packet, the method further comprises: encapsulating, by the ingress router, the first packet in a tunnel with an outer destination address set to the egress address extracted from the Sticky-Dst-SubTLV.

[0018] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the method further comprises: sending, by the ingress router, a sticky traffic entry to a neighboring ingress router in a neighboring ingress group to support routing of subsequent packets to the server when the UE moves between mobile network sites, wherein the sticky traffic entry comprises the address of the egress router.

[0019] In one embodiment, the present application includes a method implemented by a server, the method comprising: receiving, by the server, a first packet from a user equipment (UE) over a data network, wherein the first packet includes an anycast address of the server and is associated with a sticky traffic flow; inserting, by the server, a sticky destination sub type length value (Sticky-Dst-SubTLV) in an Internet Protocol extension header of a second packet of the flow, wherein the Sticky-Dst-SubTLV includes an address of an egress router connected to the server; and sending, by the server, the second packet with the Sticky-Dst-SubTLV to the UE over the data network.

[0020] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a communication from a UE, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to pointing to an IP address of a specific computer on the Internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), traffic that wishes to maintain a flow of communications between the UE and a particular application server is referred to herein as sticky traffic.

[0021] This embodiment includes mechanisms to support sticky traffic that connects to edge computing application servers sharing the same anycast address for different instances in different data centers. The disclosed mechanisms operate on ingress routers and egress routers. In one example, sticky traffic can be managed by relying on functionality at the UE. The UE sends a packet to an application server as part of a flow. The packet is forwarded through an initial ingress router and the egress router to the application server. The application server sends a response packet to the UE through the egress router. The egress router is preconfigured to identify the anycast address as being associated with sticky traffic. For example, an Edge Computing (EC) sticky traffic management system can configure various routers in the network with an anycast address and / or a sticky traffic identifier (ID) for sticky traffic. The egress router inserts a sticky destination sub type length value (Sticky-Dst-SubTLV) in a header of the response packet. The packet includes an additional destination address field that includes a destination address for forwarding the packet. The header can be a destination options header (or destination extension header), such as an IPv6 destination options header defined by the IPv6 protocol. The Sticky-Dst-SubTLV includes the IP address of the egress router. The egress router then forwards the packet to the UE through the initial ingress router. The UE copies the Sticky-Dst-SubTLV into subsequent packets belonging to the flow. In other words, the UE extracts the Sticky-Dst-SubTLV and inserts the extracted Sticky-Dst-SubTLV into subsequent packets belonging to the flow. The UE can extract the Sticky-Dst-SubTLV from each packet of the flow that it receives so that the UE can insert it into the next packet of the same flow. The UE can store the extracted Sticky-Dst-SubTLV for sending subsequent packets belonging to the same flow. The act of storing the extracted Sticky-Dst-SubTLV can not be required for every packet received from the server, can be performed when the UE receives a packet that responds to the first packet sent by the UE, or when the UE receives an updated egress router address specified in the Sticky-Dst-SubTLV. When the UE moves between 5G sites, the subsequent ingress router uses the egress router address in the Sticky-Dst-SubTLV to forward subsequent packets to the correct egress router.For example, the subsequent ingress router can use the egress router address to establish an IP tunnel with the egress router. All packets sent by the UE to the server can include the UE address as the source address and the server address (e.g., an anycast address) as the destination address in the fixed header. Correspondingly, all packets sent by the server to the UE can include the UE address as the destination address and the server address (e.g., an anycast address) as the source address in the fixed header.

[0022] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the Sticky-Dst-SubTLV comprises a sticky type.

[0023] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the IP extension header of the second packet is an Internet Protocol version six (IPv6) Destination Options header, and the Sticky-Dst-SubTLV is inserted in the IPv6 Destination Options header.

[0024] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, before sending the first packet, the method further comprises: the ingress router encapsulating the first packet in a tunnel with an outer destination address set to the egress address extracted from the Sticky-Dst-SubTLV.

[0025] In one embodiment, the present application comprises a method implemented by an egress router, the method comprising: the egress router receiving, from a first ingress router, a first packet from a user equipment (UE) destined to an anycast address of a server, wherein the first packet is associated with a sticky traffic flow; the egress router sending the first packet to the server; the egress router receiving, from the server, a second packet of the flow, wherein the second packet is destined to the UE; the egress router inserting a sticky destination subtype length value (Sticky-Dst-SubTLV) in an Internet Protocol extension header of the second packet, wherein the Sticky-Dst-SubTLV comprises an address of the egress router; and the egress router sending the second packet with the Sticky-Dst-SubTLV to the first ingress router.

[0026] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a UE’s communication, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to an IP address that points to a specific computer on the Internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), traffic that wishes to maintain a flow of communications between the UE and a particular application server is referred to herein as sticky traffic.

[0027] This embodiment includes a mechanism used when the network cannot rely on the UE to support sticky traffic. In this case, various routers in the network can be preconfigured with a anycast address and / or sticky traffic ID for sticky traffic, e.g., from communication with the EC sticky traffic management system. The UE sends a packet to an application server as part of a flow. The initial ingress router receives the packet and determines the least cost application server and determines the corresponding egress router. In this example, the initial ingress router maintains a sticky traffic table. The initial ingress router reads the anycast address and determines that the anycast address is associated with sticky traffic. The initial ingress router then stores the anycast address and / or sticky traffic ID, data indicating the flow (e.g., the UE's flow label and / or address), and the egress address of the egress router in the entry in the sticky traffic table. The initial ingress router then forwards the packet and any subsequent flow packets to the application server through the egress router according to the sticky traffic table entry. This forwarding can be done over an IP tunnel. In this example, the initial ingress router is responsible for forwarding the sticky traffic table entry to other ingress routers in order to maintain sticky traffic upon UE handover. In one example, when the UE experiences a handover to a final 5G site, the 5G EC management system notifies the initial ingress router. In this case, the initial ingress router determines a final ingress router associated with the final 5G site and sends the sticky traffic table entry to the final ingress router, e.g., in a Sticky-Dst-SubTLV. In another example, the ingress router does not receive a notification from the 5G network. In this case, the initial ingress router periodically advertises the sticky traffic table to a set of neighboring ingress routers. In either case, the final ingress router receives the sticky traffic table entry from the initial ingress router. Thus, when the UE moves between 5G sites, the final ingress router uses the egress router address in the sticky traffic table entry corresponding to the anycast address and flow label / UE address to forward subsequent packets to the correct egress router. For example, the final ingress router can use the egress router address to establish an IP tunnel with the egress router.

[0028] Optionally, in any of the above aspects, another implementation of the aspect provides that the IP extension header of the second packet is an Internet Protocol version six (IPv6) Destination Options header, and the Sticky-Dst-SubTLV is inserted in the IPv6 Destination Options header.

[0029] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the Sticky-Dst-SubTLV comprises a sticky type.

[0030] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the first ingress router is coupled to a first Protocol Data Unit (PDU) Session Anchor (PSA) in a first mobile network site, the first packet is received from the first ingress router when traffic from the UE is anchored by the first PSA in the first mobile network site.

[0031] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the method further comprises: receiving, by the egress router, a third packet of the flow from a second ingress router, wherein the third packet is destined to the anycast address of the server and comprises the Sticky-Dst-SubTLV; and sending, by the egress router, the third packet to the server.

[0032] Optionally, in any of the preceding aspects, in a further implementation form of the aspect, the second ingress router is coupled to a second PSA in a second mobile network site, the third packet is received from the second ingress router when traffic from the UE is anchored by the second PSA in the second mobile network site.

[0033] In one embodiment, the present application comprises a method implemented by an ingress router, the method comprising: receiving, by the ingress router, a first packet destined to an anycast address of a server from a user equipment (UE), wherein the first packet comprises data indicating a sticky traffic flow associated with the first packet; determining, by the ingress router, that the anycast address is associated with a sticky traffic identifier (ID); determining, by the ingress router, an egress address of an egress router for forwarding the first packet; storing, by the ingress router, the data indicating the flow, the sticky traffic ID and the egress address in an entry in a sticky traffic table; sending, by the ingress router, the first packet to the egress router; receiving, by the ingress router, a second packet comprising the anycast address and the data indicating the flow; and sending, by the ingress router, the second packet to the egress router according to a correspondence between the sticky traffic ID, the flow label and the egress address in the sticky traffic table.

[0034] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a UE’s communication, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to an IP address that points to a specific computer on the Internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), traffic that wishes to maintain a flow of communications between the UE and a particular application server is referred to herein as sticky traffic.

[0035] This embodiment includes a mechanism used when the network cannot rely on the UE to support sticky traffic. In this case, for example, various routers in the network can be preconfigured with a anycast address and / or sticky traffic ID for sticky traffic, e.g., based on communication with an EC sticky traffic management system. The UE sends a packet to an application server as part of a flow. The initial ingress router receives the packet and determines the least cost application server and determines a corresponding egress router. In this example, the initial ingress router maintains a sticky traffic table. The initial ingress router reads the anycast address and determines that the anycast address is associated with sticky traffic. The initial ingress router then stores the anycast address and / or sticky traffic ID, data indicating the flow (e.g., a flow label and / or address of the UE), and the egress address of the egress router in the entry in the sticky traffic table. The initial ingress router then forwards the packet and any subsequent flow packets to the application server through the egress router according to the sticky traffic table entry. This forwarding can be done over an IP tunnel. In this example, the initial ingress router is responsible for forwarding the sticky traffic table entry to other ingress routers in order to maintain sticky traffic as the UE moves between sites. In one example, when the UE experiences a handoff to a final 5G site, the 5G EC management system notifies the initial ingress router. In this case, the initial ingress router determines a final ingress router associated with the final 5G site and sends the sticky traffic table entry to the final ingress router, e.g., in a Sticky-Dst-SubTLV. In another example, the ingress router does not receive a notification from the 5G network. In this case, the initial ingress router periodically advertises the sticky traffic table to a set of neighboring ingress routers. In either case, the final ingress router receives the sticky traffic table entry from the initial ingress router. Thus, as the UE moves between 5G sites, the final ingress router uses the egress router address in the sticky traffic table entry corresponding to the anycast address and flow label / UE address to forward subsequent packets to the correct egress router. For example, the final ingress router can use the egress router address to establish an IP tunnel with the egress router.

[0036] Optionally, in any of the above aspects, another implementation of the aspect provides that the method further includes the ingress router advertising the sticky traffic table to neighboring ingress routers in a set of neighboring ingress routers to support routing of subsequent packets to the server as the UE moves between fifth-generation (5G) mobile network sites.

[0037] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the data indicative of the flow is a flow label.

[0038] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the ingress router further comprises receiving a notification from a fifth-generation (5G) mobile network Edge Computing (EC) management system, wherein the notification indicates that the UE has moved from an initial Protocol Data Unit (PDU) session anchor (PSA) of an initial 5G mobile network site to a subsequent PSA of a subsequent 5G site; and sending, by the ingress router, the entry in the sticky traffic table to a subsequent ingress router to support routing of subsequent packets to the server.

[0039] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the entry in the sticky traffic table comprises a timer, and the method further comprises deleting, by the ingress router, the entry in the sticky traffic table when the timer expires.

[0040] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the sticky traffic identifier ID is the anycast address of the server.

[0041] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the method further comprises receiving, by the receiver, a list of sticky traffic IDs for sticky traffic from a sticky traffic management system.

[0042] In one embodiment, the present application comprises a method implemented by an Edge Computing (EC) sticky traffic management system, the method comprising: receiving, by the EC sticky traffic management system, a request to register an anycast address of an application server as associated with sticky traffic; storing, by the EC sticky traffic management system, the anycast address of the application server in a sticky traffic list; and sending, by the EC sticky traffic management system, a configuration message to add the anycast address of the application server stored in the sticky traffic list to an access control list (ACL) for filtering traffic on an ingress router for sticky traffic.

[0043] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a UE’s communication, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to an IP address that points to a specific computer on the Internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), traffic that wishes to maintain a flow of communications between the UE and a particular application server is referred to herein as sticky traffic.

[0044] This embodiment includes mechanisms to support sticky traffic that connects to edge computing application servers sharing the same anycast address for different instances in different data centers. The disclosed mechanisms operate on ingress routers and egress routers. In one example, sticky traffic can be managed by relying on functionality at the UE. The UE sends a packet to an application server as part of a flow. The packet is forwarded through an initial ingress router and the egress router to the application server. The application server sends a response packet to the UE through the egress router. The egress router is preconfigured to identify the anycast address as being associated with sticky traffic. For example, an Edge Computing (EC) sticky traffic management system can configure various routers in the network with an anycast address and / or a sticky traffic identifier (ID) for sticky traffic. The egress router inserts a sticky destination sub type length value (Sticky-Dst-SubTLV) in a header of the response packet. The packet includes an additional destination address field that includes a destination address for forwarding the packet. The header can be a destination options header (or destination extension header), such as an IPv6 destination options header defined by the IPv6 protocol. The Sticky-Dst-SubTLV includes the IP address of the egress router. The egress router then forwards the packet to the UE through the initial ingress router. The UE copies the Sticky-Dst-SubTLV into subsequent packets belonging to the flow. In other words, the UE extracts the Sticky-Dst-SubTLV and inserts the extracted Sticky-Dst-SubTLV into subsequent packets belonging to the flow. The UE can extract the Sticky-Dst-SubTLV from each packet of the flow that it receives so that the UE can insert it into the next packet of the same flow. The UE can store the extracted Sticky-Dst-SubTLV for sending subsequent packets belonging to the same flow. The act of storing the extracted Sticky-Dst-SubTLV can not be required for every packet received from the server, can be performed when the UE receives a packet that responds to the first packet sent by the UE, or when the UE receives an updated egress router address specified in the Sticky-Dst-SubTLV. When the UE moves between 5G sites, the subsequent ingress router uses the egress router address in the Sticky-Dst-SubTLV to forward subsequent packets to the correct egress router.For example, the subsequent ingress router can establish an IP tunnel with the egress router using the egress router address. All packets sent by the UE to the server can include the UE address as the source address specified in the fixed header and the server address (e.g., an anycast address) as the destination address specified in the fixed header. Correspondingly, all packets sent by the server to the UE can include the UE address as the destination address specified in the fixed header and the server address (e.g., an anycast address) as the source address specified in the fixed header.

[0045] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the anycast address of the application server is a sticky traffic identifier (ID) of a flow destined to the anycast address.

[0046] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the method further includes sending, by the EC sticky traffic management system, the configuration message to add the anycast address of the application server to an ACL for filtering traffic on an egress router for sticky traffic.

[0047] Optionally, in any of the preceding aspects, in another implementation form of the aspect, the ingress router is coupled to a fifth generation (5G) mobile network site and the egress router is coupled to the application server.

[0048] In one embodiment, the present disclosure includes a network element comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the preceding aspects.

[0049] In one embodiment, the present disclosure includes a non-transitory computer readable medium comprising a computer program product for use by a network element, wherein the computer program product comprises computer executable instructions stored in the non-transitory computer readable medium such that when executed by a processor cause the network element to perform the method of any of the preceding aspects.

[0050] In one embodiment, the present disclosure includes an egress router comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the preceding aspects.

[0051] In one embodiment, the present disclosure includes a user equipment (UE) comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the above aspects.

[0052] In one embodiment, the present disclosure includes an ingress router comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the above aspects.

[0053] In one embodiment, the present disclosure includes an ingress router comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the above aspects.

[0054] In one embodiment, the present disclosure includes an Edge Computing (EC) sticky traffic management system comprising: a non-transitory memory storage comprising instructions; and one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to perform the method of any of the above aspects.

[0055] For clarity of description, any of the above embodiments can be combined with any other one or more of the above embodiments to create new embodiments within the scope of the present disclosure.

[0056] These and other features will be more readily understood from the following detailed description, taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF DRAWINGS

[0057] For a more thorough understanding of the present disclosure, reference is made to the following description taken in conjunction with the accompanying drawings and specific embodiments described below, in which like reference numerals indicate like parts.

[0058] Figure 1 is a schematic diagram of an exemplary 5G Edge Computing network.

[0059] Figure 2 is a protocol diagram of an exemplary method of managing sticky traffic using a UE and an egress router.

[0060] Figure 3 is a protocol diagram of an exemplary method of managing sticky traffic using an ingress router based on information from a 5G network.

[0061] Figure 4 is a protocol diagram of an exemplary method of managing sticky traffic using an ingress router without input from a 5G network.

[0062] Figure 5 An exemplary IP version six (IPv6) destination options header using sticky service is shown.

[0063] Figure 6 An exemplary sticky destination sub type length value (Sticky-Dst-SubTLV) structure is shown.

[0064] Figure 7 An exemplary sticky service identifier (ID) used as an application aware ID is shown.

[0065] Figure 8 An exemplary sticky service table is shown.

[0066] Figure 9 A schematic diagram of an exemplary network element for managing sticky service.

[0067] Figure 10 A flowchart of an exemplary method for managing sticky service on a user equipment (UE) side.

[0068] Figure 11 A flowchart of an exemplary method for managing sticky service on an egress router side.

[0069] Figure 12 A flowchart of an exemplary method for managing sticky service on an ingress router side.

[0070] Figure 13 A flowchart of an exemplary method for managing sticky service on an edge computing sticky service management system side.

[0071] Figure 14 A schematic diagram of an exemplary 5G edge computing system for managing sticky service through UE interaction.

[0072] Figure 15 A schematic diagram of an exemplary 5G edge computing system for managing sticky service without UE interaction.

[0073] Figure 16 An exemplary IPv6 packet format is shown.

[0074] Figure 17 Another exemplary Sticky-Dst-SubTLV structure is shown.

[0075] Figure 18 An exemplary route extension header used by sticky service is shown. DETAILED DESCRIPTION

[0076] It should be understood at the outset that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including exemplary design and implementation set forth herein, but can be modified in various ways.

[0077] Mobile devices, referred to herein as user equipment (UE), can utilize edge computing services. Specifically, a 5G network is communicatively connected to an IP network, which is communicatively connected to various data centers. Edge computing involves connecting application servers in the data centers directly to the IP network. The goal of edge computing is to route communications from a UE connected to 5G to the least expensive application server over the IP network. Least expensive can include physical distance, current network congestion, measurements of current load on the application server, etc. By placing application servers physically close to the 5G network, latency between the UE and the application server can be significantly reduced.

[0078] Edge computing application servers can employ instantiation. For example, different data centers can each use a different copy (instance) of the same application server. In this case, no matter which data center receives a communication from a UE, the UE receives the same service. One mechanism to implement this instantiation is to configure all application server instances with the same anycast address, which can be a unicast IP address. The UE can use the anycast address as a destination address in a communication, and the network can use the anycast address to route the communication to the nearest application server. This is in contrast to pointing to an IP address of a specific computer on the internet. One problem with this approach is that some services can experience latency when exchanged between instances. For example, services that support autonomous driving can need to resend data when exchanged between instances, which can cause undesirable and / or dangerous latency. Even when a UE moves between mobile network sites or wireless communication network sites (e.g., 5G network sites), it is desirable to maintain traffic for a communication flow between the UE and a particular application server, referred to herein as sticky traffic. In this disclosure, mobile network sites are not limited to 5G network sites and can extend beyond 5G network sites.

[0079] Disclosed herein are mechanisms to support sticky traffic that connects to edge computing application servers sharing the same anycast address for different instances in different data centers. The disclosed mechanisms operate on ingress routers and egress routers. Ingress routers as used herein are routers connecting a 5G network and an IP network, and egress routers are routers connecting an IP network and a data center that includes edge computing application servers. It is noted that the terms initial and subsequent are used herein to distinguish between 5G sites / ingress routers serving a UE before and after a handover, respectively. In one example, sticky traffic can be managed by relying on functionality at the UE. The UE sends a packet to an application server as part of a flow. The packet is forwarded by an initial ingress router and an egress router to the application server. The application server sends a response packet to the UE through the egress router. The egress router is preconfigured to identify the anycast address as being associated with sticky traffic. For example, an Edge Computing (EC) sticky traffic management system can configure various routers in the network with an anycast address and / or a sticky traffic identifier (ID) for sticky traffic. The egress router inserts a sticky destination subtype length value (Sticky-Dst-SubTLV) in a header of the response packet. The packet includes an additional destination address field that includes a destination address for forwarding the packet. The header can be a destination options header (or destination extension header), such as an IPv6 destination options header defined by the IPv6 protocol. The Sticky-Dst-SubTLV includes the IP address of the egress router. The egress router then forwards the packet to the UE through the initial ingress router. The UE copies the Sticky-Dst-SubTLV into subsequent packets belonging to the flow. In other words, the UE extracts the Sticky-Dst-SubTLV and inserts the extracted Sticky-Dst-SubTLV into subsequent packets belonging to the flow. The UE can extract the Sticky-Dst-SubTLV from each packet of the received flow so that the UE can insert it into the next packet of the same flow. The UE can store the extracted Sticky-Dst-SubTLV for sending subsequent packets belonging to the same flow.The action of storing the extracted Sticky-Dst-SubTLV can not be needed every time a packet is received from the server, can be performed when the UE receives a packet in response to the first packet sent by the UE, or when the UE receives an updated egress router address specified in a Sticky-Dst-SubTLV. The subsequent ingress routers use the egress router address in the Sticky-Dst-SubTLV to forward subsequent packets to the correct egress router when the UE moves between 5G sites. For example, the subsequent ingress routers can use the egress router address to establish an IP tunnel with the egress router. All packets sent by the UE to the server can include a UE address as the source address specified in the fixed header and a server address (e.g., an anycast address) as the destination address specified in the fixed header. Correspondingly, all packets sent by the server to the UE can include a UE address as the destination address specified in the fixed header 1600 and a server address (e.g., an anycast address) as the source address specified in the fixed header 1600.

[0080] In another example, the network cannot rely on the UE to support sticky traffic. In this case, various routers in the network can be preconfigured with a anycast address and / or sticky traffic ID for sticky traffic, e.g., according to communication with an EC sticky traffic management system. The UE sends a packet to an application server as part of a flow. The initial ingress router receives the packet and determines the application server with the lowest cost and determines a corresponding egress router. In this example, the initial ingress router maintains a sticky traffic table. The initial ingress router reads the anycast address and determines that the anycast address is associated with sticky traffic. The initial ingress router then stores the anycast address and / or sticky traffic ID, data indicating the flow (e.g., a flow label and / or address of the UE), and the egress address of the egress router in the entry in the sticky traffic table. The initial ingress router then forwards the packet and any subsequent flow packets to the application server through the egress router according to the sticky traffic table entry. This forwarding can be done over an IP tunnel. In this example, the initial ingress router is responsible for forwarding the sticky traffic table entry to other ingress routers in order to maintain sticky traffic as the UE is handed over. In one example, the 5G EC management system notifies the initial ingress router when the UE experiences a handover to a final 5G site. In this case, the initial ingress router determines a final ingress router associated with the final 5G site and sends the sticky traffic table entry to the final ingress router, e.g., in a Sticky-Dst-SubTLV. In another example, the ingress router does not receive a notification from the 5G network. In this case, the initial ingress router periodically advertises the sticky traffic table to a set of neighboring ingress routers. In either case, the final ingress router receives the sticky traffic table entry from the initial ingress router. Thus, as the UE moves between 5G sites, the final ingress router uses the egress router address in the sticky traffic table entry corresponding to the anycast address and flow label / UE address to forward subsequent packets to the correct egress router. For example, the final ingress router can use the egress router address to establish an IP tunnel with the egress router.

[0081] Figure 1An exemplary 5G edge computing network 100 is shown. The network 100 includes a 5G network 110 and an IP network 120. A UE 101 can connect to the 5G network, which connects to the IP network 120. The IP network 120 can then connect to a local data network (LDN) 132 and / or LDN 136, which include an application server 133 and / or an application server 137, respectively. In this way, the UE 101 can communicate with the application servers 133 and / or 137 through the 5G network 110 and the IP network 120.

[0082] The UE 101 is any user equipment capable of communicating with the 5G network 110 over a wireless interface. A wide variety of UEs 101 include 5G communication capabilities, such as cell phones, tablets, computers, appliances, and the like. The present invention focuses on UEs 101 that use sticky traffic. Sticky traffic is any communication traffic designed to maintain a communication flow between the UE 101 and a particular application server (e.g., the application server 133) even if the UE 101 moves between sites of the 5G network 110. For example, handover between application servers can require the UE 101 to resend certain data. This can be problematic for applications that include strict latency requirements. As a specific example, the UE 101 can be an autonomous vehicle that uses a wireless interface to communicate with an application running on the application server 133 for driving purposes. As a specific example, handover between the application server 133 and the application server 137 can impact the ability of the autonomous vehicle to timely perform driving related actions.

[0083] The UE 101 connects to the 5G network 110. The 5G network 110 includes various 5G sites, including an initial 5G site 111 and a subsequent 5G site 115. The initial 5G site 111 and the subsequent 5G site 115 are substantially similar, but are located in different geographic locations. To discuss clearly, the terms initial and subsequent are used to indicate that the UE 101 initially connects to the initial 5G site 111 before moving to a different location and connecting to the subsequent 5G site 115. The initial 5G site 111 and the subsequent 5G site 115 each include a 3GPP compliant wireless communication device known as a gNodeB base station (gNB). The gNB (not shown) wirelessly communicates with the UE 101.

[0084] The initial 5G site 111 and the subsequent 5G site 115 also include an initial Protocol Data Unit (PDU) Session Anchor (PSA) 112 and a subsequent PSA 116, respectively. The initial PSA 112 and the subsequent PSA 116 are 5G components that function as session anchors for mobiles in the initial 5G site 111 and the subsequent 5G site 115, respectively. As an example, the UE 101 can initially anchor to the initial PSA 112 in the initial 5G site 111. The UE 101 can transmit packets to the initial PSA 112 through a gNB, and the initial PSA 112 can forward these packets to the IP network 120. Also, devices in communication with the UE 101 can send packets to the initial PSA 112, and the initial PSA 112 can forward these packets to the UE 101. Subsequently, the UE 101 can move to the subsequent 5G site 115, in which case the session anchor responsibility is handed over to the subsequent PSA 116. The subsequent PSA 116 can then forward packets back and forth between the UE 101 and the IP network 120. Note that the 5G network 110 includes many other components that are not directly relevant to the current example. These components are omitted for clarity of discussion.

[0085] The IP network 120 is a set of interconnected network nodes that are addressable by IP addresses. The IP network 120 can include an IP version four (IPv4) network that uses IPv4 address space and / or an IP version six (IPv6) network that uses a larger IPv6 address space. The IP network 120 includes many network nodes, including an initial ingress router 113, a subsequent ingress router 117, an egress router 131, and an egress router 135. The initial ingress router 113 and the subsequent ingress router 117 connect the initial 5G site 111 and the subsequent 5G site to the IP network 120, respectively. Likewise, the egress router 131 and the egress router 135 connect the LDN 132 and the LDN 136 to the IP network 120. The initial ingress router 113, the subsequent ingress router 117, the egress router 131, and the egress router 135 each function to apply packet filters to flows and route packets according to IP addresses included in packet headers. The initial ingress router 113, the subsequent ingress router 117, the egress router 131, and the egress router 135 also function to encapsulate packets with additional headers to create IP tunnels across the IP network 120, such as IP tunnel 121 and IP tunnel 122. IP tunnels 121 and 122 are paths through a network between two points. Headers can be appended to the front of each packet in a stream of packets, which causes each packet to be routed along a path according to the header, resulting in IP tunnels 121 and / or 122.

[0086] The IP network 120 deploys IPv6 protocol to send and receive packets (i.e., IPv6 packets). An IPv6 packet has an IPv6 header, which includes a fixed header and one or more extension headers (if applicable). The extension headers, also referred to as optional headers or option headers, carry optional Internet layer information and are placed between the fixed header and the upper layer protocol header. The upper layer protocol header is located in the upper layer protocol unit. The extension headers form a chain using the "next header" field. The "next header" field in the fixed header indicates the type of the first extension header, and the "next header" field of the last extension header indicates the type of the upper layer protocol header in the packet payload. The size of all extension headers is a multiple of 8 octets; some extension headers require internal padding to meet this requirement.

[0087] Reference Figure 16is an exemplary IPv6 packet format that can be used by IPv6 protocols in the IP network 120. The IPv6 packet includes an IPv6 fixed header 1600, which includes a version field 1601, a traffic class field 1603, a flow label field 1605, a length field 1607, a next header field 1609, a hop limit field 1611, a source address field 1613, and a destination address field 1615. The version field 1601 is set to 6, indicating an IPv6 version. The traffic class field 1603 can be 8 bits in length and can extend from bit position 4 to bit position 11. The traffic class field 1603 can be used for network traffic management and can be set to indicate a traffic class associated with a flow to which the packet belongs. The flow label field 1605 can be 20 bits in length and can extend from bit position 12 to bit position 31. The flow label field 1605 can be set by a source to label a sequence of packets to be treated as a single flow in the network. The payload length field 1607 can be 16 bits in length and can extend from bit position 0 to bit position 15. The length field 1607 indicates the size of the payload in octets, including any extension headers. When the "hop-by-hop" extension header carries the jumbo payload option, the length is set to 0. The next header field 1609 can be 8 bits in length and can extend from bit position 16 to bit position 23. The next header field 1609 specifies the type of the next header, typically specifying a transport layer protocol used by the payload of the packet. The hop limit field 1611 can be 8 bits in length and can extend from bit position 23 to bit position 31. The hop limit field 1611 can be set to indicate a value that helps limit the number of hops a packet can travel. The value of the hop limit field 1611 can be decremented by 1 by each node that forwards the packet. Any node other than the destination node can discard the packet when the value in the hop limit field 1611 is decremented to 0. However, the destination node should process the packet normally even if the hop limit received is 0. The source address field 1613 and the destination address field 1615, each can be 128 bits in length and can extend from bit position 0 to bit position 31 on a contiguous set of octets. The source address field 1613 can be set to the address of the originator of the packet and the destination address field 1615 can be set to the address of the intended recipient of the packet.

[0088] In Figure 16 the IPv6 packet includes an extension field 1617, which is an optional field that can be used to carry one or more extension headers, such as a destination options header, a routing extension header, etc. The IPv6 packet includes an upper layer protocol data unit 1620 for carrying data, which includes additional upper layer protocol headers.

[0089] Returning to Figure 1LDNs 132 and 136 are networks for connecting computing components (e.g., servers) to IP network 120. For example, LDNs 132 and 136 can each be housed in a data center. Application server 133 and application server 137 are computing components located in LDN 132 and LDN 136, respectively. For example, application server 133 and application server 137 can host applications that are accessible by other components (e.g., UE 101). In an edge computing system, application server 133 and 137 can be directly connected to corresponding egress routers 131 and 135 to support as low latency as possible. In one example, application server 133 and application server 137 each deploy different instances of the same application. Each instance can respond to input data in substantially the same way, but each instance can receive different input data. Further, application server 133 and application server 137 can both be assigned the same anycast address. An anycast address is a single destination IP address that is shared by multiple devices. Since application server 133 and application server 137 are located in different LDNs 132 and 136, application server 133 and 137 are both located in different locations. Since application server 133 and 137 both have the same anycast address, communications from UE 101 can be routed to the application server 133 and / or 137 that is physically closest to UE 101. Thus, UE 101 can use the anycast address to communicate with the application server 133 and / or 137 that is located closest to the 5G site currently connected to UE 101. For example, anycast routing can use routing costs that take into account hop count and / or network congestion to balance communications.

[0090] Using an anycast address in this manner has the advantage of reducing latency by ensuring that the UE 101 is always communicating with the application server 133 and / or 137 with the lowest cost. However, in some cases, the UE 101 can use sticky traffic, and thus, the UE 101 can want to continue to communicate with the same application server even when the UE 101 moves to a different 5G site. For example, the UE 101 can initially connect to the initial PSA 112 in the initial 5G site 111. The UE 101 can send a message requesting service from an application instance by setting the destination address to the application's anycast address. The initial PSA 112 forwards the message to the initial ingress router 113 that is directly connected to the initial 5G site 111. The initial ingress router 113 looks at the anycast address and determines that the lowest cost instance associated with the anycast address is connected to the egress router 131. Thus, the initial ingress router 113 forwards the message to the egress router 131 through the IP tunnel 121. The egress router 131 can then forward the message to the application server 133 in the LDN 132. The application server 133 can then communicate with the UE 101 at the initial 5G site 111 through the egress router 131, the IP tunnel 121, the initial ingress router 113, and the initial PSA 112.

[0091] At a later time, the UE 101 can move to the subsequent PSA 116 at the subsequent 5G site 115. The UE 101 can continue to send messages to the anycast address. In this case, the subsequent PSA 116 can forward the message to the subsequent ingress router 117. The default behavior of the subsequent ingress router 117 can be to determine the lowest cost instance associated with the anycast address, which can cause the subsequent ingress router 117 to forward the message to the application server 137 through the egress router 135. Since the application server 137 is a different instance than the application server 133, the application server 137 can incorrectly process the message because the application server 137 can not be aware of the session and / or flow associated with the message. The present invention is directed to mechanisms to implement sticky traffic to cause the flow to continue to be routed to the same application server after the UE 101 moves. In the present example, the sticky traffic should cause the subsequent ingress router 117 to continue to route anycast messages from the UE 101 to the application server 133 that is connected or connected to the egress router 131 even though the egress router 135 and the application server 137 can be associated with a lower routing cost.

[0092] This embodiment can include an edge computing (EC) sticky traffic management system 125 in the IP network 120, which is a computing component for managing sticky traffic. For example, the EC sticky traffic management system 125 can receive a registration request from an application or its administrator that uses sticky traffic. The EC sticky traffic management system 125 can maintain a list of sticky traffic and corresponding anycast addresses. For example, the EC sticky traffic management system 125 can maintain a list of anycast addresses as sticky traffic identifiers (IDs) for corresponding applications. The sticky traffic ID can be an anycast address of the sticky traffic or other values that represent the sticky traffic. The EC sticky traffic management system 125 can then configure access control lists (ACLs) on the initial ingress router 113, the subsequent ingress router 117, the egress router 131, and / or the egress router 135 using the anycast addresses and / or the sticky traffic IDs. Thus, the routers 113, 117, 131, and 135 can use the ACLs to filter packets by anycast addresses to locate packets that should be considered as part of the sticky traffic. The sticky traffic IDs can be included in the ACLs for filtering packets. Details of the ACLs can be referenced in the description included in this disclosure.

[0093] Once the routers 113, 117, 131, and 135 are used for sticky traffic, various mechanisms can be employed to implement the sticky traffic functionality. In one example, the network 100 can rely on the UE 101 to assist with sticky traffic routing. In this embodiment, the UE 101 forwards a first packet upstream to the initial PSA 112. The first packet can be part of a flow. The packet is then forwarded to the initial ingress router 113. The initial ingress router 113 forwards the first packet to the least cost egress router 131, which forwards the first packet to the application server 133. The application server 133 then responds with a second packet sent downstream through the egress router 131. The egress router 131 recognizes that the source address of the second packet is equal to the sticky traffic anycast address of the application server 133. The egress router 131 then appends the IP address of the egress router to the second packet. For example, the IP address of the egress router can be included in a sticky destination sub type length value (Sticky-Dst-SubTLV). The Sticky-Dst-SubTLV can then be included in the packet header of the second packet, such as an IPv6 Destination Options header or an IPv6 Destination Extension header. In IPv6, optional Internet layer information is encoded in separate headers that can be placed between the IPv6 fixed header and upper layer headers of a packet. Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or removed by any node or router in the path of a packet until the packet reaches the node (or each group of nodes in the case of multicast) identified in the Destination Address field of the IPv6 header. The second packet can then be forwarded to the UE 101. The UE 101 can be configured to copy the packet header from each downstream packet into a subsequent upstream packet that belongs to the same flow. Thus, the initial ingress router 113 receives further upstream packets at the initial 5G site 111, extracts the header with the Sticky-Dst-SubTLV, and determines whether the packet matches an ACL. If the flow exists in the Sticky-Dst-SubTLV, the ingress router 113 can extract the flow label and egress router address (or identifier) from the Sticky-Dst-SubTLV. The initial ingress router 113 can determine whether the extracted flow label matches the flow label in the IPv6 fixed header in order to further forward the packet. The initial ingress router 113 can then forward the upstream packet to the egress router 131 according to the IP address of the egress router 131 in the header, rather than determining the least cost destination of the anycast address. Furthermore, the UE 101 can move to a subsequent 5G site 115. The header from the downstream packet continues to include the Sticky-Dst-SubTLV with the IP address of the egress router 131.Accordingly, the UE 101 can copy the header with the IP address of the egress router 131 into the uplink messages sent to the subsequent PSA 116. These messages are forwarded to the subsequent ingress router 117, which identifies the messages as sticky traffic messages according to the ACL. The subsequent ingress router 117 can then forward the uplink messages to the egress router 131 via the IP tunnel 122, etc., according to the IP address of the egress router 131 in the header, rather than determining the lowest cost destination of the anycast address. In this way, the anycast messages from the UE 101 continue to stick to the application server 133 even if the UE 101 physically leaves the initial 5G site 111.

[0094] In another example, the network 100 can not rely on the UE 101 to assist with sticky traffic routing. In this case, the initial ingress router 113 can be used to manage sticky traffic. The initial ingress router 113 can identify packets from the UE 101 as sticky traffic according to the anycast address. The initial ingress router 113 can maintain a sticky traffic table. When a sticky traffic flow is not already included in the sticky traffic table, the initial ingress router 113 can determine the least cost egress router 131. The initial ingress router 113 can then add an entry in the sticky traffic table to identify the flow and the egress router 131. For example, the flow can be identified by the anycast address, a sticky traffic ID, an IP address of the UE 101, and / or a flow label that identifies the flow. The initial ingress router 113 can then route the flow according to the entry in the sticky traffic table that includes the IP address of the egress router 131. As long as the sticky traffic table and / or its entries can be shared with the subsequent ingress router 117, the subsequent ingress router 117 can also forward the UE 101 packets to the egress router 131 after the UE 101 moves according to the sticky traffic table. It is noted that the sticky traffic table entries can also include a timer to allow for the deletion of stale entries from the sticky traffic table. In one example, when the UE 101 moves from the initial 5G site 111 to the subsequent 5G site 115, the 5G network 110 notifies the IP network 120. For example, the 5G network 110 can also include a 5G EC management system 119. The 5G EC management system 119 can be part of the 5G core (5GC). The 5G EC management system 119 is a component used to manage edge computing functionality on behalf of the 5G network 110. The 5G EC management system 119 can receive a notification whenever a UE (e.g., the UE 101) that uses edge computing services moves between 5G sites. Thus, when the UE 101 moves to the subsequent 5G site 115, the 5G EC management system 119 notifies the initial ingress router 113. For example, the 5G EC management system 119 can indicate to the initial ingress router 113 that the UE 101 is handing over to the subsequent 5G site 115 that is connected to the subsequent ingress router 117. The notification sent by the 5G EC management system 119 to the initial ingress router 113 can include the following information: the address of the new PSA to which the UE is to be anchored and the new IP address of the UE. The initial ingress router 113 can then send the sticky traffic table entry (or entries) associated with the UE 101 to the subsequent ingress router 117. In another embodiment, the initial ingress router 113 can send the “sticky traffic ID” (e.g., the anycast address) + Sticky-Dst-SubTLV to the subsequent ingress router 117.The subsequent ingress routers 117 can use the information included in the notification from the initial ingress router 113 to establish an ACL to filter packets associated with the same flow of sticky traffic and continue to forward the UE 101 packets belonging to the same flow to the egress router 131 after the UE 101 moves according to the sticky traffic entry instead of according to the default anycast forwarding.

[0095] In another embodiment, the old UPF attached to the initial ingress router 113 can record the Sticky-Dst-SubTLV extracted from the sticky traffic flow packets and then send the Sticky-Dst-SubTLV to the SMF of the 5GC through N4 signaling defined by the 5G standard. During the handover operation, the SMF populates the "sticky traffic ID" (e.g., anycast address) + Sticky-Dst-SubTLV into the new UPF. The new UPF can add the Destination Options header or Routing Extension Header in the IPv6 packets of the UE that recently attached to the new UPF. With respect to the subscription Network Exposure Function (NEF), this results in per-flow state transfer between two domains (e.g., 5G domain and application domain). This procedure can work normally but can cause some scalability inefficiency. This approach can also require SA2 changes and coordination with third-party domains.

[0096] In another example, the 5G network 110 does not notify the IP network 120 when the UE 101 moves. In this example, the initial ingress router 113 periodically advertises the sticky traffic table to a group of routers including the subsequent ingress routers 117, which is denoted as the adjacent ingress group. Each router in the adjacent ingress group can then add the advertised sticky traffic table entries to each router's local sticky traffic table. As in the previous example, when there are no entries in the sticky traffic table, the ingress routers forward the packets to the egress router with the lowest cost. However, when the entries in the sticky traffic table indicate the flow and IP address of the egress router 131, both the initial ingress router 113 and the subsequent ingress routers 117 forward the packets to the egress router 131. Thus, the subsequent ingress routers 117 can continue to forward the UE 101 packets to the egress router 131 using the advertised sticky traffic table after the UE 101 moves according to the sticky traffic table instead of according to the default anycast forwarding.

[0097] Figure 2is a protocol diagram of an exemplary method 200 for managing sticky traffic using a UE and an egress router. Specifically, the method 200 runs on a UE, an initial ingress router, a subsequent ingress router, an egress router, and an application server, such as UE 101, initial ingress router 113, subsequent ingress router 117, egress router 131, and application server 133, respectively. It is noted that messages discussed below are described by numbers (e.g., first message, second message, etc.). Such numbering is for clarity of discussion, and other unnumbered messages can be transmitted in a similar manner to the numbered messages. For example, many messages can be sent between the third message and the fourth message. Thus, the numbering should be considered interpretative, rather than limiting.

[0098] The method 200 begins when a UE initiates a sticky traffic based flow to an application running on an application server. The method 200 assumes that the routers have been configured by the EC sticky traffic management system 125 to support sticky traffic. In step 201, the UE connects to an initial 5G site. Thus, the UE sends a first message to the 5G site, for example, to the initial PSA. The message is then forwarded to the initial ingress router. According to an example, the first message can or can not be the first message of the flow. The UE sets the destination address of the first message to an anycast address associated with the application server.

[0099] In step 203, the initial ingress router filters the first message through an ACL on the initial ingress router and determines that the anycast address in the first message is associated with sticky traffic. The initial ingress router can also look at the message header for a Sticky-Dst-SubTLV. Since the flow has not been previously routed to the egress router, the first message does not include a Sticky-Dst-SubTLV. Thus, the initial ingress router routes the first message according to the anycast address. Specifically, the initial ingress router determines that the cost of using the anycast address and sending the first message to the application server connected to the egress router that terminates the IP tunnel defined by the label stack is the lowest, for example, by encapsulating the first message with a label stack that defines the IP tunnel terminating at the egress router. Then, in step 205, the first message is forwarded along the tunnel to the egress router. For example, each node along the path between the initial ingress router and the egress router can remove the label and forward the message according to the next label in the stack, with the subsequent label directing the message to the egress router. The egress router can then decapsulate the first message.

[0100] In step 207, the egress router forwards the first packet to the application server according to the anycast address destination of the first packet. In step 209, the application server responds with a second packet that redirects the flow back to the UE. Specifically, the application server sets the destination address of the second packet to the IP address of the UE. In step 210, the egress router filters the second packet by the ACL at the egress router and determines that the source address is any of the anycast addresses associated with the sticky traffic. From this determination, the egress router inserts a Sticky-Dst-SubTLV in the header of the packet. The Sticky-Dst-SubTLV includes the IP address of the egress router. In one example, the Sticky-Dst-SubTLV is inserted in the IPv6 Destination Options header of the second packet. Then, in step 211, the egress router forwards the second packet to the initial ingress router that is communicatively connected to the initial 5G site associated with the UE. Then, in step 213, the initial ingress router forwards the second packet to the UE. The initial 5G site then forwards the send packet to the UE through the initial PSA and gNB.

[0101] In step 215, the UE sends a third packet to the application server as part of the flow. The UE generates the third packet and copies the IPv6 Destination Options header in the second packet into the third header. Accordingly, the third packet includes a header that includes a Sticky-Dst-SubTLV with the egress router IP address. In step 217, the UE sets the destination address of the third packet to the anycast address of the application server and forwards the third packet on the initial 5G site. The third packet is routed to the initial ingress router connected to the initial 5G site.

[0102] In step 219, the initial ingress router filters the first packet by the ACL and determines that the anycast address in the third packet is associated with the sticky traffic. The initial ingress router can also look at the packet header for the Sticky-Dst-SubTLV. Unlike step 203, this time the initial ingress router finds the Sticky-Dst-SubTLV. Accordingly, the initial ingress router routes the third packet according to the Sticky-Dst-SubTLV instead of according to the anycast address. In step 221, the initial ingress router finds the IP address of the egress router in the Sticky-Dst-SubTLV and forwards the third packet to the egress router through the IP tunnel. Then, in step 223, the egress router forwards the third packet to the application server in a similar manner as step 207.

[0103] The process can continue for some time until the UE moves to a different 5G site, denoted here as a subsequent 5G site for clarity of discussion. In step 225, the UE determines to send a fourth packet to the application server in a similar manner as step 215. The UE copies the header IPv6 Destination Options header from the last packet received from the application server into the fourth packet. Accordingly, the fourth packet includes a header that includes a Sticky-Dst-SubTLV with the egress router IP address. In step 227, the UE sets the destination address of the fourth packet to the anycast address of the application server and forwards the fourth packet on the subsequent 5G site. The fourth packet is routed to a subsequent ingress router connected to the subsequent 5G site.

[0104] In step 228, the subsequent ingress router processes the fourth packet in a similar manner as the third packet was processed in the initial ingress router in step 219. That is, the subsequent ingress router filters the fourth packet through the ACL of the subsequent ingress router and determines that the anycast address in the fourth packet is associated with sticky traffic. The subsequent ingress router also looks at the packet header and finds the Sticky-Dst-SubTLV with the egress router IP address. Accordingly, the subsequent ingress router routes the fourth packet according to the Sticky-Dst-SubTLV instead of according to the anycast address. In step 229, the subsequent ingress router finds the IP address of the egress router in the Sticky-Dst-SubTLV and forwards the fourth packet to the egress router over the IP tunnel. Then, in step 231, the egress router forwards the packet to the application server.

[0105] By inserting the Sticky-Dst-SubTLV in the downlink packet at the egress router and copying the header of the downlink packet into the uplink packet, the uplink packet will be routed back to the egress router instead of being routed according to the anycast address. Accordingly, the Sticky-Dst-SubTLV causes the flow to stick to the first egress router for the flow even if the UE moves to a different 5G site that can be closer to a different instance of the application server. If the UE wishes to not stick the flow (e.g., when the latency becomes too large), the UE can stop copying the downlink header onto the next uplink packet. This will cause the flow to be routed according to the anycast address to the closest application server. The UE can then start copying the header again to cause the flow to stick to a different egress router as desired.

[0106] Figure 3is a protocol diagram of an exemplary method 300 of managing sticky traffic using ingress routers according to information from a 5G network. Specifically, the method 300 operates in: a 5G EC management system, an EC sticky traffic management system, a UE, an initial ingress router, a subsequent ingress router, an egress router, and an application server, e.g., 5G EC management system 119, EC sticky traffic management system 125, UE 101, initial ingress router 113, subsequent ingress router 117, egress router 131, and application server 133, respectively. As with method 200, the messages of method 300 discussed below are described by numbers (e.g., first message, second message, etc.). Such numbering is for clarity of discussion, other unnumbered messages can also be conveyed in a similar manner to the numbered messages. Thus, the numbering should be considered explanatory, rather than limiting.

[0107] Method 300 begins when the EC sticky traffic management system configures the routers using the sticky traffic ID. For example, the EC sticky traffic management system can receive a request from a user to register an anycast address of an application running on an application server as a sticky traffic ID. In step 301, the EC sticky traffic management system sends a configuration message to the initial ingress router. The configuration message configures an ACL on the initial ingress router to filter messages so as to identify messages with the application server anycast address as source and / or destination address as sticky traffic related messages. In step 303, the EC sticky traffic management system sends a configuration message to the subsequent ingress router. In step 301, the configuration message configures an ACL on the subsequent ingress router in a similar manner to the initial ingress router. In step 305, the EC sticky traffic management system sends a configuration message to the egress router. In step 301, the configuration message configures an ACL on the egress router in a similar manner to the initial ingress router. Thus, the configuration messages of steps 301, 303, and 305 configure the routers in the IP network to identify the anycast address of the application server as associated with sticky traffic. It is noted that steps 301, 303, and 305 can also be used for method 200 described in some of the examples above.

[0108] In step 311, the UE connects to the initial 5G site. Thus, the UE sends a first message to the 5G site, e.g., to the initial PSA. The message is then forwarded to the initial ingress router. According to an example, the first message can or can not be the first message of a flow. The UE sets the destination address of the first message to the anycast address associated with the application server. It is noted that method 300 assumes that the UE is not used to assist in sticky traffic management. Thus, the UE forwards the first message according to the anycast address without considering sticky traffic related mechanisms, leaving such management to the IP network components.

[0109] In step 313, the initial ingress router filters the first packet through an ACL on the initial ingress router and determines that the anycast address in the first packet is associated with sticky traffic. The initial ingress router checks a sticky traffic table stored on the initial ingress router to determine whether the first packet is associated with a flow that has been stuck on an egress router. In the present example, the first packet is not included in the sticky traffic table. Accordingly, the initial ingress router prepares to route the first packet according to a default anycast address routing behavior. Specifically, the initial ingress router determines the application server with the lowest cost using the anycast address. The initial ingress router then adds an entry to the sticky traffic table for the flow that includes the first packet. The entry can include the anycast address as a sticky traffic ID and data identifying the flow. For example, the data identifying the flow can include a flow label and / or an IP address of the UE. The entry can also include a timer that can be refreshed when the initial ingress router receives other packets associated with the flow. The entry can then be deleted upon expiration of the timer to remove the stale flow from the sticky traffic table.

[0110] In step 315, the initial ingress router sends the first packet to the application server with the lowest cost to the egress router connected to the application server, such as by encapsulating the first packet with a label stack defining an IP tunnel terminated at the egress router. The first packet is then forwarded along the tunnel to the egress router. For example, each node along the path between the initial ingress router and the egress router can remove the label and forward the packet according to the next label in the stack, with the final label directing the packet to the egress router. The egress router can then decapsulate the first packet. In step 317, the egress router forwards the first packet to the application server according to the anycast address destination of the first packet. The application server responds as needed with packets directed to the UE IP address. However, unlike method 200, method 300 can not use the downlink packets from the application server to propagate sticky traffic information.

[0111] In step 319, the UE sends a second packet to the initial ingress router in a manner substantially similar to step 311. In step 320, the initial ingress router filters the second packet through the ACL on the initial ingress router and determines that the anycast address in the second packet is associated with sticky traffic. The initial ingress router then checks the sticky traffic table stored on the initial ingress router and determines that the flow already exists in the table based on the anycast address and flow identification data. The initial ingress router can then refresh the timer of the table entry and route the second packet according to the sticky traffic table entry in step 321. Specifically, the initial ingress router can route the packet to the egress router through the IP tunnel according to the IP address of the egress router stored in the sticky traffic table entry, rather than according to the anycast address. In step 323, the egress router forwards the second packet to the application server according to the anycast address destination of the second packet.

[0112] In step 325, the UE moves to a subsequent 5G site and switches from the initial PSA of the initial 5G site to a subsequent PSA of the subsequent 5G site. The method 300 assumes that the 5G network is used to help support sticky traffic management. Specifically, in step 325, the 5G EC management system is made aware of the UE switch, for example, by one or more of the PSAs. In step 327, the 5G EC management system notifies the initial ingress router that the UE has moved and is now connected to a 5G site that is connected to a subsequent ingress router. For example, the 5G EC management system can notify the initial ingress router of the UE’s connection to the subsequent 5G site, the UE’s connection to the subsequent ingress router, the UE’s different IP address associated with the subsequent PSA of the subsequent 5G site, etc.

[0113] In step 329, the initial ingress router sends the sticky traffic table entry for the UE to the subsequent ingress router. The subsequent ingress router is notified that the UE is associated with the active sticky traffic flow that is connected to the egress router. The subsequent ingress router is also notified of the IP address of the egress router to allow the flow to continue to be forwarded to the egress router.

[0114] In step 331, the UE sends a third packet to the subsequent ingress router through the 5G gNB and the subsequent PSA. In step 333, the subsequent ingress router filters the third packet through the ACL on the subsequent ingress router and determines that the anycast address in the third packet is associated with sticky traffic. The subsequent ingress router then checks the sticky traffic table stored on the subsequent ingress router. The subsequent ingress router finds the sticky traffic table entry for the flow received from the initial ingress router in step 329. Accordingly, the subsequent ingress router determines that the entry for the flow already exists according to the anycast address and the flow identification data. Then, in step 335, the subsequent ingress router can refresh the timer of the entry and route the third packet according to the sticky traffic entry. Specifically, the subsequent ingress router can route the packet to the egress router through the IP tunnel according to the IP address of the egress router stored in the sticky traffic entry, instead of according to the anycast address. In step 337, the egress router forwards the third packet to the application server according to the anycast address destination of the third packet.

[0115] By saving the IP address of the egress server in the entry in the sticky traffic table, the flow packets from the initial ingress router are forwarded to the egress server. Further, sharing the sticky traffic entry with the subsequent ingress router causes the subsequent ingress router to continue to forward the flow packets to the egress router even when the UE moves to a subsequent 5G site. Thus, the sticky traffic table causes the flow to stick to the first egress router for the flow even when the UE moves to a different 5G site that can be closer to a different instance of the application server. The flow can be un-stuck by the IP network. For example, the flow can be removed from the sticky traffic table when the timer expires. Further, the ingress nodes can be limited to sharing the sticky traffic entry within a certain number of hops (ingress routers, egress routers, etc.). This helps when the UE moves far away from the egress router, the flow is un-stuck such that it is more disruptive to route to the initial egress router than to stick the flow to a new egress router.

[0116] Figure 4 is a protocol diagram of an example method 400 of managing sticky traffic using ingress routers without input from a 5G network. Specifically, the method 400 operates in an EC sticky traffic management system, a UE, an initial ingress router, a subsequent ingress router, an egress router, and an application server, e.g., the EC sticky traffic management system 125, the UE 101, the initial ingress router 113, the subsequent ingress router 117, the egress router 131, and the application server 133, respectively. As with the method 200 and the method 300, the packets of the method 400 discussed below are described by numbers (e.g., first packet, second packet, etc.). This numbering is for clarity of discussion, and other unnumbered packets can also be communicated in a similar manner to the numbered packets. Thus, the numbering should be considered explanatory, rather than limiting.

[0117] Method 400 is similar to method 300, but assumes that the 5G network does not notify the IP network when the UE moves between 5G sites. Steps 401, 403, 405, 411, 413, 415, and 417 are substantially similar to steps 301, 303, 305, 311, 313, 315, and 317, respectively. However, in method 400, the initial ingress router does not know whether the UE has moved to another 5G network. In addition, the initial ingress router does not know which 5G site the UE can move to, and thus does not know which ingress router should receive the UE's sticky traffic table entry.

[0118] To address these issues, the initial ingress router periodically shares the initial ingress router's sticky traffic table with a group of neighboring ingress routers in the neighboring ingress group to support routing of subsequent packets to the egress server when the UE moves between 5G sites. Thus, in step 418, the initial ingress router broadcasts the initial ingress router's sticky traffic table to all neighboring ingress routers, including the subsequent ingress router. The subsequent ingress router then adds non-duplicate entries in the initial ingress router's sticky traffic table to the subsequent ingress router's sticky traffic table. As a result, all ingress routers in the group of neighboring ingress routers have substantially the same information in the corresponding sticky traffic tables.

[0119] The UE can route packets through the initial ingress router and to the egress router according to the initial ingress router's sticky traffic table. Thus, steps 419, 420, 421, and 423 are substantially similar to steps 319, 320, 321, and 323, respectively, in method 300.

[0120] Since the initial ingress router does not know when the UE moves to a different 5G site, the initial ingress router continues to broadcast the initial ingress router's sticky traffic table. Thus, in step 424, the initial ingress router broadcasts the initial ingress router's sticky traffic table to all neighboring ingress routers, including the subsequent ingress router, in a manner substantially similar to step 418.

[0121] In step 425, the UE moves to a subsequent 5G site in a manner similar to step 325. Then, in step 431, the UE sends a third packet to a subsequent ingress router in a manner similar to step 331. In step 433, the subsequent ingress router filters the third packet by the ACL on the subsequent ingress router and determines that the anycast address in the third packet is associated with sticky traffic. The subsequent ingress router then checks the sticky traffic table stored on the subsequent ingress router. Since the subsequent ingress router received the table entry from the sticky traffic table of the initial ingress router in steps 418 and / or 424, the subsequent ingress router finds the sticky traffic table entry for the flow. Accordingly, the subsequent ingress router determines that the table entry for the flow already exists according to the anycast address and flow identification data. The subsequent ingress router can refresh the timer of the table entry and route the third packet. Thus, steps 435 and 437 are substantially similar to steps 335 and 337, respectively.

[0122] By saving the IP address of the egress server in the table entry in the sticky traffic table, the flow packet from the initial ingress router is forwarded to the egress server. Moreover, by broadcasting the sticky traffic table of each ingress router to other neighboring ingress routers, the subsequent ingress router receives the corresponding sticky traffic table entry for the UE even if the IP network components are not notified of the movement of the UE.

[0123] Figure 5 An exemplary IPv6 Destination Options header 500 using sticky traffic is shown. For example, the IPv6 Destination Options header 500 can be communicated between the UE 101 and the egress router 135 as part of the method 200. For example, the egress router can insert the IPv6 Destination Options header 500 in a downlink packet, and the UE can copy the IPv6 Destination Options header 500 into an uplink packet. This facilitates the IPv6 Destination Options header 500 to communicate the IP address of the egress router to the ingress router, and thus the ingress router to stick the corresponding flow to the egress router.

[0124] The IPv6 Destination Options header 500 is specified by the Internet Engineering Task Force (IETF) document Request For Comment (RFC) 8200 and includes a Next Header field 501 that can be 8 bits in length and can extend from bit position 0 to bit position 7. The Next Header field 501 identifies the type of header immediately following the IPv6 Destination Options header 500. The Next Header field 501 can be set to a value of sixty (60). The IPv6 Destination Options header 500 also includes a Header Extension Length field 503 that can be 8 bits in length and can extend from bit position 8 to bit position 15. The Header Extension Length field 503 can include the length of the IPv6 Destination Options header 500 in units of eight octets, not including the first eight octets. The IPv6 Destination Options header 500 also includes a Sticky-Dst-SubTLV field 505. The Sticky-Dst-SubTLV field 505 has a variable length and follows the Header Extension Length field 503, thus extending from bit position 16. The Sticky-Dst-SubTLV field 505 includes the IP address of the egress router that supports sticky traffic.

[0125] Figure 6An example Sticky-Dst-SubTLV structure 600 is shown. For example, the Sticky-Dst-SubTLV structure 600 can be included in the IPv6 Destination Option header 500 in the Sticky-Dst-SubTLV field 505. The Sticky-Dst-SubTLV structure 600 includes a sticky type field 601, which can be 8 bits in length and can extend from bit position 0 to bit position 7. The sticky type field 601 can be set to a value representing the type of IP address in the Sticky-Dst-SubTLV structure 600. For example, the sticky type field 601 can be set to 1, indicating that a sticky egress unicast address is encoded in the Sticky-Dst-SubTLV structure 600. The Sticky-Dst-SubTLV structure 600 includes a length field 603, which can be 8 bits in length and can extend from bit position 8 to bit position 15. The length field 603 can be set to a value representing the length of the Sticky-Dst-SubTLV structure 600 (e.g., in octets). The Sticky-Dst-SubTLV structure 600 also includes an address family identifier (AFI) field 603, which can be 8 bits in length and can extend from bit position 16 to bit position 23. The AFI field 603 can be set to a value indicating whether the Sticky-Dst-SubTLV structure 600 includes an IPv4 address or an IPv6 address. The Sticky-Dst-SubTLV structure 600 also includes a reserved field 607, which can be 8 bits in length and can extend from bit position 23 to bit position 31. The reserved field 607 can be reserved for other functions. The Sticky-Dst-SubTLV structure 600 also includes a sticky egress address field 609, which can be set to an IP address of an egress router used to reach an application server having a corresponding anycast address. It is noted that the Sticky-Dst-SubTLV structure 600 can also be included in the service parameters subTLV field.

[0126] Figure 7An exemplary sticky service ID 700 is shown that can be used as an application aware ID. For example, the sticky service ID 700 can be used in a packet header, such as when transmitting sticky service data to a UE according to method 200. The sticky service ID 700 includes a stickiness level field 701 that can be 8 bits in length and can extend from bit position 0 to bit position 7. The stickiness level field 701 includes a value that indicates a level of stickiness. For example, the stickiness level can be used to indicate a level of importance for which an application should stick to a corresponding anycast server. Some applications can be more preferred, but not require the flow to stick to the original anycast server. Other applications can require stickiness. The stickiness level field 701 can be used to transmit this information. The sticky service ID 700 also includes a sticky service ID field 703 that can be 8 bits in length and can extend from bit position 8 to bit position 15. The sticky service ID field 703 can include an anycast address of an application server. The sticky service ID 700 also includes a reserved field 705 that can be 8 bits in length and can extend from bit position 16 to bit position 23. The reserved field 705 can be reserved for including an identifier of a flow in a 5G access domain. The sticky service ID 700 also includes a flow ID field 707 that can be 8 bits in length and can extend from bit position 24 to bit position 31. The flow ID field 707 can include an identifier of a flow that should stick to a particular anycast server.

[0127] Figure 8 An exemplary sticky service table 800 is shown that can be used by an initial ingress router 113 and / or a subsequent ingress router 117, such as in methods 300 and / or 400. The sticky service table 800 includes various table entries 810. Each table entry identifies a sticky flow. The table entry includes at least a sticky service ID 801, a flow indicator 803, and an egress router address 805. The table entry can also include a timer to support timeout and / or time out functionality. The sticky service ID 801 can include an anycast address of an application that uses the sticky flow. The flow indicator 803 includes any data that uniquely identifies the flow, such as a UE IP address and / or a flow label. The egress router address 805 can include an IP address of an egress router to which the flow, identified by the corresponding sticky service ID 801 and flow indicator 803, should stick.

[0128] In one example, the above embodiments can be implemented as follows. This document introduces an IPv6 technical solution that can stick application flows from a mobile device to the same Anycast server location when the mobile device moves from one 5G cell site to another. This technical solution extends the Application Aware ID and Service Parameter Option by including Anycast sticky traffic location information in the IPv6 Hop-by-Hop or Destination Options header. Note that the terms Destination Options header, Destination Option header, Destination Option header, and similar terms are used interchangeably to carry optional information that should only be examined by the destination node or router of the packet.

[0129] One application in the 5G edge computing environment can host multiple application servers in different edge computing data centers that are close by. These edge computing data centers can be very close to, or co-located with, 5G base stations to minimize latency and optimize performance. When a mobile device sends a packet using a destination address from a domain name service (DNS) reply or its own cache, the packet is carried by a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) tunnel from the 5G gNB to the 5G user plan function (UPF)-PSA. The UPF-PSA decapsulates the 5G GTP outer header and forwards the packet from the mobile device to the ingress router of the EC LDN. The IP network is responsible for forwarding the packet to the intended destination.

[0130] When the UE starts an application, the UE sends a query to the DNS to resolve the application name (app.net). The DNS replies with an A / AAAA record. For the rest of the flow sequence, IPv4 (G-4) is used. The UE initiates an application request (e.g., HTTPS) with a destination address of G-4. The PDU is forwarded to the UPF-PSA attached to the UE. The UPF-PSA terminates the GTP and forwards the IP packet with a destination address of G-4 to the IP network. The router in the IP network selects an application server from {E1, E2, E3}. For the rest of the sequence, assume that the LDN (LDN1) is selected. Since this is a stateful application, the application server issues a redirect request with a new URL. In this case, the URL is set to the URL of the local data center - ldnl.opl.app.net. IP address translation directs the packet to E1, unless there is a site failure.

[0131] The UE sends a query to the DNS resolving the redirect URL - ldnl.opl.app.net, the DNS replies with the anycast address Ll. The UE continues the application request with the anycast address: Ll as destination address. The PDU is forwarded to the UPF-PSA. The UPF-PSA terminates the GTP and forwards the IP packet with the anycast address Ll to the IP network. The configured routing rules ensure that the anycast address Ll is always forwarded to the LDNl unless the LDNl site fails. When the UE has a PDU session from a new location, a handover procedure is taken. In case of Session and Service Continuity Mode 3 (SSC Mode 3), the UE continues to receive packets on the old gNB (gNB1) for a short time. When the IP address changes, the UE initiates an application layer message. This is to ensure that pending downlink packets are directed to the UE attached to the new UPF-PSA.

[0132] When a mobile device moves out of the coverage of the current gNB, a handover procedure is initiated and the 5G Session Management Function (SMF) selects a new UPF-PSA. When the handover procedure is completed, the mobile device is anchored to the new UPF-PSA. The 5G SMF can keep the path from the old UPF to the new UPF for SSC Mode 3 for a short time to make the handover procedure more seamless. The 5G SMF is part of the 5GC or 5G EC management system.

[0133] The 5G EC network properties are now discussed. In this document, a 5G edge computing network refers to a number of LDNs in a region used to connect EC mini data centers. From the 3GPP 5G perspective, these IP LDN networks are N6 interfaces. The ingress router of a 5G edge computing network is directly connected to a 5G UPF. The egress router of a 5G edge computing network is the router that has a direct link to the edge computing servers. The servers and egress routers are co-located. Some of these mini edge computing data centers can have a virtual switch or a top-of-rack switch between the egress router and the servers. But the transport delay between the egress router and the edge computing servers is very small and can be neglected in this document.

[0134] When a micro data center has multiple edge computing servers connected to an application layer load balancer, the 5G edge computing network only sees the application layer load balancer. The edge computing service is a special managed service that leverages the network topology and balances between multiple mini edge computing data centers with the same anycast address. The mobile device can access services that do not belong to the registered 5G edge computing services.

[0135] One issue with Anycast in the 5G EC environment is that Anycast is widely used by various application providers because Anycast supports dynamic load balancing between multiple locations of the same address based on network conditions. When multiple servers in different locations have the same Anycast IP address, the router sees multiple paths to that IP address. Using Anycast address selection for application server locations takes advantage of the proximity information that exists in the network routing layer and eliminates single points of failure and bottlenecks on DNS resolvers and application layer load balancers. Another benefit of using Anycast addresses is the elimination of the dependency on mobile devices using their cached IP addresses instead of querying DNS when moving to a new location. In the 5G edge computing environment, having multiple locations for the same Anycast address can be problematic because all of these edge computing data centers can be close to each other. The routing cost to the application servers in different edge DCs can not have any difference. The same routing cost to multiple locations can cause packets from one flow to be forwarded to different locations, resulting in service failure.

[0136] Another issue with Anycast is related to sticking to the original application server. When a mobile device moves to a new location but continues the same application flow, the router located in the new location can select the application server. The server is closer to the new location. When the UE in the first 5G site moves to the second 5G site, the router directly connected to the second 5G PSA can forward the packets destined for the first application server to the server located in the second LDN because the second LDN has the lowest cost according to the routing. This is not the desired behavior for some services, which are referred to as sticky services in this document. Even for advanced applications with some built-in mechanisms to resynchronize the application layer communication after moving to a new location, service failure is often encountered. It is important to note that not all services need to be sticky. Assume that only a subset of services is sticky and the network is informed of the services that should be sticky, usually by the request of the application developer or controller. This document introduces an IPv6-based network layer solution to stick the packets belonging to the same flow of a mobile device to its original application server location after the mobile device anchors to a new UPF-PSA.

[0137] Another issue is related to application server relocation. When an application server is added to, moved, or removed from a 5G edge computing data center, the routing protocol must propagate the change to the 5G PSA or PSA adjacent routers. After the change, the cost associated with the site can also change. For ease of description, edge computing servers, application servers (Application Server and / or App Server) are used interchangeably in this document.

[0138] APN6 is an application aware network using IPv6. The word application is very broad in meaning. In this document, the term application refers to any application using an anycast server in a 5G edge computing environment. A-ER is an egress router to an application server. A-ER is used to describe the last router that an application server connects to. For a 5G EC environment, the A-ER can be a gateway router to a mini edge computing data center. An application server is a physical or virtual server that hosts an application software system. An application server location represents a cluster of servers in one location that serve the same application. An application can have a layer 7 load balancer in front of a group of application servers whose addresses are accessible from the outside IP network. From the IP network perspective, this whole server group is considered as the application server of a location. Edge application server is used interchangeably with application server here. An edge hosting environment is an environment that provides support for the execution of edge application servers. An edge data center (DC) provides an edge computing hosting environment, possibly co-located with or very close to a 5G base station. A mobile device (MD) is the same as a UE. The term mobile device or UE used in this document should emphasize the stickiness of the service from a mobile to the same server.

[0139] From the perspective of the local data network, implementing sticky traffic for a flow from a mobile device to a specific anycast server is the same as delivering the flow's packets to the same egress router that the anycast server connects to. The egress router should deliver packets destined to an anycast address to the direct server, even if the same address is accessible from other routers, unless the direct server is no longer accessible due to server or link failure. The egress router that an edge computing server connects to directly is called the sticky egress node for the location edge computing server. The sticky egress node has a unicast address. When edge computing servers with the same anycast address in multiple edge computing data centers are located in different edge computing data centers, each location is identified by its sticky egress node unicast address. For an ingress router of the LDN, implementing sticky traffic is sending packets belonging to the same flow to the same sticky egress node unicast address.

[0140] From the perspective of the local data network, the sticky egress node unicast address is the next hop to reach the edge computing server anycast address. The flow affinity function can ensure that packets belonging to one flow are forwarded along the same path to the same egress router, which then delivers the packets to the connected edge computing server. For IPv6 traffic, the LDN router can support flow affinity to forward packets with the same flow label in the IPv6 header of the packet along the same path to the same egress router. For IPv4 traffic, the five-tuple in the IPv4 header can be used to implement flow affinity.

[0141] This document describes a technical solution that sticks the mobile device's flow to the same egress router of the application server after the mobile device moves to a new 5G site. Now the technical solution in a limited domain is described. In a limited domain, the mobile device, edge server, and network function are under one administrative domain. Therefore, it is feasible for the mobile device to perform certain actions. Now the use case of 5G edge computing in a limited domain is discussed. Some 5G interconnected devices, such as drones for coping with natural disasters or robots in industrial environments, require ultra-low latency responses from the analysis server. In order to achieve ultra-low latency, these analysis functions can be hosted on servers very close to the radio tower. All functions (including network and analysis) and devices can be managed by one operator. These functions can be provided by different vendors, so an interoperable technical solution is needed.

[0142] The router directly connected to the 5G PSA can learn the address of the egress router that the edge server instance is connected to through the BGP update message advertised from these egress routers. For convenience of description, the router directly connected to the PSA in each 5G site is called the 5G site-specific local data network ingress router. The 5G site-specific ingress router learns the egress router of the edge computing server instance through the BGP update message or IGP advertisement initiated from these routers.

[0143] The end node-based sticky traffic technical solution is introduced as follows. If the next packet belongs to the same flow, the end node-based sticky traffic technical solution requires the IPv6 mobile device to insert the destination option header extracted from the packet received from the network side into the IPv6 header of the next packet. This operation significantly simplifies the processing of the LDN ingress router. The following are some assumptions of the end node-based sticky traffic technical solution. The mobile device is under the same administrative control as the edge computing server. If the edge computing service requires stickiness in the 5G edge computing environment, the corresponding service ID is registered to the 5G edge computing controller. The sticky traffic ID can be one or a group of anycast addresses or regular addresses.

[0144] The following is an overview of the end node based sticky traffic solution. Each anycast edge compute server learns or is told the unicast sticky egress address. The goal is to deliver packets belonging to a flow to the same sticky egress address of the anycast address. When the edge compute server sends the packet back to the client (or mobile device), it inserts the Sticky-Dst-SubTLV in the Destination Option header of the packet. If the next packet belongs to the same flow as the previous packet, the client (or mobile device) copies the Destination Option header in the received packet to the Destination Option header of the next packet. If the following conditions are true, the ingress router encapsulates the packet from the client in a tunnel with the outer destination address of the tunnel set to the sticky egress address extracted from the Sticky-Dst-SubTLV in the packet. The destination of the packet from the client matches one of the sticky traffic ACLs configured on the LDN ingress router, and there is a Destination Option with Sticky-Dst-SubTLV in the packet header. Otherwise (one of the above conditions is not true), the ingress node uses an algorithm, such as the least cost algorithm, to select the best sticky egress address to forward the packet.

[0145] Sticky egress address discovery is now discussed. For an App server with an anycast address, the sticky egress address is the same as its default gateway address. The proxy sticky egress address can be encoded in the Destination Option header to prevent a malicious entity from sending a distributed denial of service (DDOS) attack to the routers within the 5G EC LDN by using the sticky egress address encoded in the Destination Option header in the packet sent back to the client. The proxy sticky egress address can only be recognized by the 5G EC LDN ingress node, but is not routable in other networks. The LDN ingress router can convert the proxy sticky egress to a routable address of the sticky egress node after authenticating the source address of the packet.

[0146] The processing of the ingress router is now described. The ingress router is configured with an ACL to filter out the applications that need sticky traffic. Not all applications need sticky traffic. Using an ACL can significantly reduce the processing on the router. When the ingress router receives a packet from the 5G side that matches the ACL, when there is a Sticky-Dst-SubTLV in the packet header, the ingress router extracts this field from the packet header. The ingress can use the sticky egress address extracted in the destination field of the outer header to encapsulate the packet as the tunnel type supported by the original sticky egress node and forward the packet. If the proxy sticky egress address is encoded in the Sticky-Dst-SubTLV, the ingress router should convert the proxy sticky egress address to a routable address. If the above conditions are not met, the ingress router uses an algorithm to select the best sticky egress node to forward the packet.

[0147] Now discuss the channel-based sticky traffic technical solution. For the environment where the mobile device cannot change its handling behavior, the channel-based sticky traffic technical solution can be used. This technical solution does not depend on the behavior of the mobile device, so more processing is used for the LDN ingress router. Now discuss the handling behavior of the ingress and egress routers. This technical solution assumes that both the ingress router and the egress router support at least one channel type and are configured with ACLs that filter out packets whose destination address or source address matches a sticky traffic identifier (sticky traffic ID). The technical solution also assumes that the number of supported sticky traffics is limited. The ingress router builds a sticky traffic table, which can include one or more of the following attributes: sticky traffic ID, flow label, sticky egress address, and timer. The sticky traffic table is initialized to be empty.

[0148] When a mobile device moves from one 5G site to another 5G site, the same mobile device can be assigned a new IP address. When the mobile device anchors to a new PSA, the flow label and the sticky traffic ID can remain the same. Therefore, this technical solution uses the flow label and the sticky traffic ID to identify the sticky flow. Since the probability of different mobile devices sending packets to the same anycast address using the same flow label is very low, the flow label and the sticky traffic ID are very likely to uniquely identify the flow. When multiple mobile devices send packets to the same anycast address using the same flow label, the technical solution described in this section will stick the flow to the same anycast server connected to the sticky egress router. This behavior will not cause any harm.

[0149] Each entry in the sticky traffic table has a timer because if there are no packets for the same flow sent to the traffic ID for a period of time, the sticky traffic is no longer sticky. The timer should be greater than the typical Transmission Control Protocol (TCP) session timeout value. When the entry timer expires, the entry will be automatically removed from the sticky traffic table. Since there are only a small number of sticky traffics, the sticky traffic table is not very large. When the ingress router receives a packet from a mobile device that matches one of the sticky traffic ACLs and there is no entry in the sticky traffic table that matches the flow label and the sticky traffic ID, the ingress router treats the packet as the first packet of the flow. There is no need to stick the packet anywhere. The ingress router uses its own algorithm to select the best egress node as the sticky egress address for the anycast address, and encapsulates the packet with the channel supported by the egress node. The destination address of the channel is set to the egress node address.

[0150] When an egress router receives a packet whose source address matches one of the sticky service IDs from a connected host, the egress router encapsulates the packet using the tunnel supported by the ingress router and sets the destination address of the tunnel to the ingress router address. The egress router learns the ingress router address of the mobile device IP address through a border gateway protocol (BGP) update message. When the ingress router receives a packet in the tunnel from any egress router and the source address of the packet matches a sticky service ID, the egress router address will be set to the sticky egress address of the sticky service ID. The ingress router adds the table entry to the sticky service table when the sticky service ID, flow label, associated sticky egress address, and timer table entry do not already exist in the sticky service table. If the table entry exists, the ingress router refreshes the timer of the table entry in the sticky service table. When the ingress router receives a subsequent packet of the flow matching the sticky service ID and flow label in the sticky service table from the 5G side, the ingress router encapsulates the packet using the sticky egress address found in the sticky service table and refreshes the timer of the table entry. When the sticky service ID does not exist in the table, the ingress router treats the packet as the first packet of the flow.

[0151] The following section describes how an ingress node propagates its sticky service table to its neighboring ingress nodes. This propagation is used to inform the neighboring ingress nodes of the sticky egress addresses to sticky services when a mobile device moves to a new neighboring 5G site resulting in anchoring to a new ingress node. A solution is now discussed that does not communicate with the 5G system. When a mobile device moves to a very far 5G site, e.g., a different geographical area, the benefit of sticking to the original anycast server is weighted by the network latency. Then, it does not make sense to send packets to a sticky egress node when the ingress router is very far. Therefore, each ingress router can need to have a set of neighboring ingress routers that are not far from the potential sticky egress nodes selected by the ingress router. This set of ingress routers is called the neighboring ingress group. Each ingress router can discover its neighboring ingress group automatically through a routing protocol or be configured by a controller. Each ingress node should periodically advertise its sticky service table to the routers within its neighboring ingress group. When each ingress router receives the sticky service table from the routers in its neighboring ingress group, each ingress router merges the table entries of the received sticky service table into its own table entries.

[0152] A solution that relies on communication with the 5G system is now discussed. In this case, the communication with the 5G system is made and the network is notified when the mobile device is anchored to a new PSA. When the mobile device re-anchors from one PSA to another, the 5G EC management system sends a notification to the router that is directly connected to the first PSA. The notification includes the address of the new PSA to which the mobile device will be anchored and the new IP address of the mobile device. In this scenario, sticky traffic can be uniquely identified by the sticky traffic ID and the mobile device address. The sticky traffic table should include the following attributes: sticky traffic ID, mobile device address, sticky egress address, and timer.

[0153] Upon receiving the notification from the 5G EC management system, the ingress router (the router that is directly connected to the old PSA) sends the specific entry of the sticky traffic table, e.g., “sticky traffic ID” + mobile device address + sticky egress + timer, to the router that is directly connected to the new PSA. Upon receiving the entry, the ingress router merges the entry into its own sticky traffic table. The ingress and egress routers handle the same as described above, except that the flow is now uniquely identified by “sticky traffic ID” + “mobile device address” instead of “sticky traffic ID” + “flow label”.

[0154] Figure 9 is a schematic diagram of an example network element 900 for managing sticky traffic, such as the EC sticky traffic management system 125, the UE 101, the initial ingress router 113, the subsequent router 117, the egress router 131, the application server 133, or other components within the network 100. For example, the network element 900 can be used to implement the methods 200, 300, 400, 1000, 1100, 1200, and / or 1300 by employing the IPv6 Destination Options header 500, the Sticky-Dst-SubTLV structure 600, the sticky traffic ID 700, and / or the sticky traffic table 800. Thus, the network element 900 is suitable for implementing the disclosed examples / embodiments described herein. The network element 900 includes a downstream port 920, an upstream port 950, and / or one or more transceiver units (Tx / Rx) 910, which include transmitters and / or receivers for upstream and / or downstream data communication over a network. The network element 900 also includes a processor 930, which includes a logic unit and / or a central processing unit (CPU) that processes data, and a memory 932 for storing data. The network element 900 can also include electrical components, optical-to-electrical (OE) components, electrical-to-optical (EO) components, wireless communication components coupled with the upstream port 950 and / or the downstream port 920 for data communication over electrical, optical, or wireless communication networks.

[0155] The processor 930 is implemented by hardware and software. The processor 930 can be implemented as one or more CPU chips, one or more cores (e.g., as a multi-core processor), one or more field-programmable gate arrays (FPGAs), one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or any combination of the above. The processor 930 is in communication with the downstream port 920, the Tx / Rx 910, the upstream port 950, and the memory 932. The processor 930 includes a sticky module 914. The sticky module 914 can implement one or more embodiments disclosed above.

[0156] In one example, the sticky module 914 can identify that the anycast address is associated with sticky traffic and include a Sticky-Dst-SubTLV in a packet header (e.g., an IPv6 Destination Options header) so that more packets of the flow can be routed to the same egress router even if the UE moves between 5G networks. In another example, the sticky module 914 copies a packet header from an incoming packet into a subsequent outgoing packet in order to copy the Sticky-Dst-SubTLV so that the ingress router forwards the subsequent packets to the same egress router even if the UE moves between 5G networks. In another example, the sticky module 914 identifies that the anycast address is associated with sticky traffic, stores the egress address in a sticky traffic table, and shares the sticky traffic table entry with other ingress routers so that the ingress router forwards the subsequent packets to the same egress router even if the UE moves between 5G networks. In another example, the sticky module 914 registers the anycast address and configures various network routers to support sticky traffic management. Thus, the sticky module 914 can be used to perform mechanisms that solve one or more of the problems described above. As such, the sticky module 914 improves the functionality of the network element 900 and solves problems in the telecommunication field. Further, the sticky module 914 transforms the network element 900 to a different state. Alternatively, the sticky module 914 can be implemented as instructions stored in the memory 932 and executed by the processor 930 (e.g., a computer program product stored on a non-transitory medium).

[0157] Memory 932 includes one or more memory types such as disk, tape drives, solid state drives, read only memory (ROM), random access memory (RAM), flash, ternary content-addressable memory (TCAM), static random-access memory (SRAM), and other optical and / or electrical storage systems suitable for the task. Memory 932 can serve as an overflow data storage device to store programs when selected for execution, and to store instructions and data read during program execution.

[0158] Figure 10 Flowchart of an example method 1000 for managing sticky traffic at a UE, such as UE 101, in network 100. Method 1000 can be used in conjunction with methods 200, 1100, and / or 1300, for example, by using IPv6 Destination Options header 500, Sticky-Dst-SubTLV structure 600, and / or sticky traffic ID 700. Method 1000 can begin when a UE determines to communicate a data flow with an application server using sticky traffic.

[0159] In step 1001, the UE includes an anycast address of an application server as a destination address of a first packet. The UE then sends the first packet to an initial ingress router in an IP network through a 5G network for forwarding to the application server with the anycast address. The UE can be communicatively connected to an initial 5G site. Thus, the first packet can be sent to the initial ingress router when the UE is connected to an initial PSA of the initial 5G site.

[0160] In step 1003, the UE receives a second packet from the application server. The second packet includes a header that includes a Sticky-Dst-SubTLV, the header having an address of an egress router connected or connected to the application server. For example, the header of the second packet can be an IPv6 Destination Options header, and the Sticky-Dst-SubTLV can be included in the IPv6 Destination Options header.

[0161] In step 1005, the UE sends another packet of the flow. The UE copies the Sticky-Dst-SubTLV in the second packet to a header of the third packet. This copies the Sticky-Dst-SubTLV into the header of the third packet.

[0162] In step 1007, the UE sends a third packet with the Sticky-Dst-SubTLV to the initial ingress router. The initial ingress router then sends the third packet sent in the Sticky-Dst-SubTLV to the application server through the egress router. In this example, the third packet can be sent to the initial ingress router when the UE is connected to the initial PSA of the initial 5G site.

[0163] After step 1007, the UE moves to another 5G site. The UE then undergoes a 5G handover from the initial PSA of the initial 5G site to a subsequent PSA of a subsequent 5G site. After the handover, in step 1009, the UE copies the header including the Sticky-Dst-SubTLV into the header of a fourth packet.

[0164] In step 1011, the UE sends the fourth packet to the subsequent ingress router in the IP network through the subsequent 5G site. The subsequent ingress router receives the fourth packet with the Sticky-Dst-SubTLV. Accordingly, the subsequent ingress router sends the fourth packet sent in the Sticky-Dst-SubTLV to the application server through the egress router. Since the fourth packet is sent after the handover, the fourth packet is sent to the subsequent ingress router when the UE is connected to the subsequent PSA of the subsequent 5G site. The first packet, the second packet, the third packet, and the fourth packet are associated with the same flow between the UE and the application server. Moreover, since the UE copies the Sticky-Dst-SubTLV in the received packet into the sent packet, the packets in the flow are forwarded to the same egress router regardless of the handover between the 5G networks.

[0165] In one example, the first packet, the second packet, and the third packet are encapsulated during communication through the tunnel, wherein the egress router is coupled to the ingress router through an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in a variable length option field in a Generic Network Virtualization Encapsulation (GENEVE) header. In another example, the first packet, the second packet, and the third packet are encapsulated during communication through the tunnel, the egress router is coupled to the ingress router through an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in an IPv6 Destination Options header field of an IPv6 header.

[0166] Figure 11 Flowchart of an example method 1100 for managing sticky traffic in an egress router, such as egress router 131 in network 100. Method 1100 can be used in conjunction with methods 200, 1000, and / or 1300, for example, by using IPv6 Destination Options header 500, Sticky-Dst-SubTLV structure 600, and / or sticky traffic ID 700. Method 1100 can begin when the egress router identifies a packet that includes an anycast address associated with sticky traffic. For example, method 1100 can be performed in response to method 1000 and / or method 1300.

[0167] In step 1101, the egress router receives a first packet from an initial ingress router (e.g., over an IP tunnel) destined for an anycast address of an application server. For example, the first packet can be generated by a UE of an initial 5G site and forwarded to an initial ingress router coupled to the initial 5G site. The initial ingress router then forwards the first packet to the egress router over the IP tunnel. Thus, the first packet can be received from the initial ingress router when the UE is connected to an initial PSA of the initial 5G site. The egress router then sends the first packet to the application server in step 1103.

[0168] In step 1105, the egress router receives a second packet from the application server. The second packet is destined for the UE and can reach the UE through the initial ingress router. The egress router can have an ACL for filtering packet flows to find packets that include an anycast address associated with sticky traffic.

[0169] Thus, the egress router identifies that the source address of the second packet is the anycast address of the sticky traffic. Accordingly, in step 1107, the egress router inserts a Sticky-Dst-SubTLV in a header of the second packet. The header of the second packet can be an IPv6 Destination Options header, and the Sticky-Dst-SubTLV can be inserted in the IPv6 Destination Options header. The Sticky-Dst-SubTLV includes an address of the egress router. The egress router then sends the second packet with the Sticky-Dst-SubTLV to the UE through an ingress router, such as through an IP tunnel, in step 1109.

[0170] After step 1109, the UE moves to another 5G site. Then, the UE experiences a 5G handover from the initial PSA of the initial 5G site to a subsequent PSA of the subsequent 5G site. In step 1111, the egress router receives a third packet from a subsequent ingress router coupled to the subsequent 5G site, e.g., over an IP tunnel to the egress router. The third packet can be destined to the anycast address of the application server. But the third packet includes the Sticky-Dst-SubTLV, which will cause the subsequent ingress router to route the third packet to the same egress router as the first and second packets, instead of sending the third packet to the egress router closest to the subsequent ingress router. Since the third packet is received after the UE experiences the 5G handover, the third packet is received from the subsequent ingress router when the UE is connected to the subsequent PSA of the subsequent 5G site. In step 1113, the egress router sends the third packet to the application server. The first, second, third, and fourth packets are associated with the same flow between the UE and the application server. Moreover, since the UE copies the Sticky-Dst-SubTLV in the received packets to the sent packets, the packets in the flow are forwarded to the same egress router regardless of the handover between the 5G networks.

[0171] In one example, the first, second, third, and fourth packets are encapsulated during communication over the tunnel, where the egress router is communicatively coupled to the ingress router over an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in a variable length option field in a Generic Network Virtualization Encapsulation (GENEVE) header. In another example, the first, second, third, and fourth packets are encapsulated during communication over the tunnel, where the egress router is communicatively coupled to the ingress router over an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in an IPv6 Destination Options header field of an IPv6 header.

[0172] Figure 12 A flowchart of an example method 1200 for managing sticky traffic in an ingress router, such as the initial ingress router 113 in the network 100. The method 1200 can be used in conjunction with the methods 300, 400, and / or 1300, e.g., by using the sticky traffic table 800.

[0173] The method 1200 can begin when the ingress router is configured to inspect packets for sticky traffic for processing. In step 1201, the ingress router receives a list of sticky traffic IDs for sticky traffic from a sticky traffic management system, e.g., as a result of the method 1300. In one example, the sticky traffic identifier ID can be an anycast address of an application server. In another example, the sticky traffic management system, e.g., the EC sticky traffic management system 125, can configure an ACL on the ingress router with sticky traffic IDs and / or anycast addresses of various sticky traffic. The ingress router then filters packets according to the ACL to identify which packets should receive sticky traffic processing.

[0174] In step 1203, the ingress router receives a first packet from a UE destined for an anycast address of an application server. The first packet can also include data indicating a flow associated with the first packet. For example, the data indicating the flow can be a flow label, a mobile device address of the UE, and / or other flow identification information.

[0175] In step 1205, the ingress router determines that the anycast address is associated with a sticky traffic ID, e.g., by comparing the destination anycast address with sticky traffic addresses in an ACL configured by the sticky traffic management system. Assuming that the first packet is associated with a new flow, the ingress node then determines an egress address of an egress router associated with the anycast address that has the lowest routing cost.

[0176] In step 1207, the ingress router stores the sticky traffic ID, the data indicating the flow, and the egress address in an entry in a sticky traffic table to indicate that future packets in the flow should be treated as part of the sticky traffic. In one example, the entry in the sticky traffic table includes a timer. The timer can be used to delete stale flows from the sticky traffic table. Thus, the ingress router can be configured to delete entries in the sticky traffic table when the timer expires.

[0177] In step 1209, the ingress router sends the first packet to the egress router associated with the anycast address that has the lowest routing cost.

[0178] In step 1211, the ingress router receives a second packet including the anycast address and the data indicating the flow. The ingress router determines that the second packet is associated with the sticky traffic according to the ACL and that the second packet is part of an existing flow according to the sticky traffic table. Thus, in step 1213, the ingress router sends the second packet to the egress router according to the correspondence between the sticky traffic ID, the flow label, and the egress address in the sticky traffic table. Subsequent packets of the flow can be forwarded in a similar manner.

[0179] In step 1215, the ingress router sends the sticky traffic table entries and / or the entire sticky traffic table to the designated subsequent ingress router and / or adjacent ingress group. For example, the ingress router can periodically advertise the sticky traffic table to adjacent ingress routers within the adjacent ingress group to support routing of subsequent packets to the egress server as the UE moves between 5G sites. In another example, the ingress router can receive a notification from the 5G EC management system. The notification can indicate that the UE has moved from an initial PSA of an initial 5G site to a subsequent PSA of a subsequent 5G site. In this example, the ingress router can send the entries in the sticky traffic table to a subsequent ingress router connected to the subsequent 5G site to support routing of subsequent packets to the egress server.

[0180] In one example, the first packet and the second packet are encapsulated during communication over the tunnel, wherein the egress router is communicatively connected to the ingress router over an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in a variable length options field in a Generic Network Virtualization Encapsulation (GENEVE) header. In another example, the first packet and the second packet are encapsulated during communication over the tunnel, the egress router is communicatively connected to the ingress router over an internet protocol version four (IPv4) network, and the Sticky-Dst-SubTLV is included in an IPv6 Destination Options header field of an IPv6 header.

[0181] Figure 13 A flowchart of an example method 1300 for managing sticky traffic at an edge computing sticky traffic management system, such as the EC sticky traffic management system in network 100. Method 1300 can be used in conjunction with methods 200, 300, 400, 1000, 1100, and / or 1200, such as by using IPv6 Destination Options header 500, Sticky-Dst-SubTLV structure 600, sticky traffic ID 700, and / or sticky traffic table 800.

[0182] Method 1300 can be initiated when an EC sticky traffic management system determines to manage sticky traffic for an edge computing network. In step 1301, the EC sticky traffic management system receives a request to register an anycast address of an application server as associated with sticky traffic. In some examples, the anycast address of the application server is a sticky traffic ID for a flow destined to the anycast address.

[0183] In step 1303, the EC sticky traffic management system stores the anycast address of the application server in a sticky traffic list. In step 1305, the EC sticky traffic management system sends a configuration message to add the anycast address of the application server to an ACL for filtering traffic on an ingress router for sticky traffic. The EC sticky traffic management system can also send a configuration message to add the anycast address of the application server to an ACL for filtering traffic on an egress router for sticky traffic. In some examples, the ingress router is coupled to a 5G site and the egress router is coupled to the application server.

[0184] Figure 14 A diagram of an example 5G edge computing system 1400 for managing sticky traffic through UE interaction. For example, the 5G edge computing system 1400 can be implemented by the corresponding components and / or network elements 900 in the 5G edge computing network 100. In one example, the 5G edge computing system 1400 can use the methods 200, 1000, 1100, and / or 1300 using the IPv6 Destination Options header 500, the Sticky-Dst-SubTLV structure 600, and / or the sticky traffic ID 700.

[0185] The 5G edge computing system 1400 includes a UE 1410. The UE 1410 includes a sending module 1401 to send a first packet to an initial ingress router destined for an anycast address of an application server. The 5G edge computing system 1400 also includes a receiving module 1403 to receive a second packet from the application server, the second packet including a header including a Sticky-Dst-SubTLV having an egress router address connected to the application server. The 5G edge computing system 1400 also includes a copying module 1405 to copy the Sticky-Dst-SubTLV into a header of a third packet. The sending module 1401 is also to send the third packet with the Sticky-Dst-SubTLV to the initial ingress router to send the third packet sent in the Sticky-Dst-SubTLV to the application server through the egress router. The components of the UE 1410 can also be used to perform any of the steps of the method 1000.

[0186] 5G edge computing system 1400 includes an egress router 1420. Egress router 1420 includes a receiving module 1421 to receive a first packet from a user equipment (UE) via an initial ingress router to an anycast address of an application server. Egress router 1420 also includes a sending module 1423 to send the first packet to the application server. Receiving module 1421 is also to receive a second packet from the application server, the second packet being to the UE. Egress router 1420 also includes an inserting module 1425 to insert a Sticky-Dst-SubTLV in a header of the second packet. Sending module 1423 is also to send the second packet with the Sticky-Dst-SubTLV to the ingress router. The components of egress router 1420 can also be used to perform any of the steps of method 1100.

[0187] Figure 15 A diagram of an example 5G edge computing system 1500 for managing sticky traffic without UE interaction. For example, 5G edge computing system 1500 can be implemented by the corresponding components and / or network elements 900 in 5G edge computing network 100. In one example, 5G edge computing system 1500 can use methods 300, 400, 1200, and / or 1300 using sticky traffic table 800.

[0188] 5G edge computing system 1500 includes an EC sticky traffic management system 1510. EC sticky traffic management system 1510 includes a receiving module 1501 to receive a request to register an anycast address of an application server as associated with sticky traffic. EC sticky traffic management system 1510 also includes a storing module 1503 to store the anycast address of the application server in a sticky traffic list. EC sticky traffic management system 1510 also includes a sending module 1505 to send a configuration message to add the anycast address of the application server to an ACL for filtering traffic on an egress router for the sticky traffic. The components of EC sticky traffic management system 1510 can also be used to perform any of the steps of method 1300.

[0189] The 5G edge computing system 1500 includes an ingress router 1520. The ingress router 1520 includes a receiving module 1521 configured to receive, from a user equipment (UE), a first packet destined for an anycast address of an application server, the first packet including data indicating a flow associated with the first packet. The ingress router 1520 also includes a determining module 1523 configured to determine that the anycast address is associated with a sticky service ID. The determining module 1523 is further configured to determine an egress address of an egress router associated with the anycast address having a lowest routing cost. The ingress router 1520 also includes a storing module 1525 configured to store the sticky service ID, the data indicating the flow, and the egress address in an entry in a sticky service table. The ingress router 1520 also includes a sending module 1527 configured to send the first packet to the egress router associated with the anycast address having the lowest routing cost. The receiving module 1521 is further configured to receive a second packet including the anycast address and the data indicating the flow. The sending module 1527 is further configured to send the second packet to the egress router according to a correspondence between the sticky service ID, the flow label, and the egress address in the sticky service table. The components of the ingress router 1520 can also be configured to perform any of the steps of the method 1200.

[0190] In one embodiment, a method is implemented in an ingress router, the method comprising: a receiver of the ingress router receiving a first packet from a user equipment (UE) destined for an anycast address of an application server, wherein the first packet includes a flow label; a processor of the ingress router searching a sticky destination sub type length value (Sticky-Dst-SubTLV) table to find an entry including the flow label; a transmitter of the ingress router transmitting the first packet to an egress router associated with the anycast address of the application server. In one example, the method further comprises: the processor obtaining an address of the egress router from the entry including the flow label in the Sticky-Dst-SubTLV table; the processor encapsulating the first packet by adding an address of the ingress router as a source address of the first packet and adding the address of the egress router as a destination address of the first packet. In another example, the method further comprises: when the entry including the flow label is not included in the Sticky-Dst-SubTLV table, the processor selecting the egress router according to a lowest route cost algorithm; obtaining the address of the egress router from a memory of the egress router; the processor encapsulating the first packet by adding the address of the ingress router as the source address of the first packet and adding the address of the egress router as the destination address of the first packet. In one example, the ingress router is communicatively connected to the egress router over an internet protocol version four (IPv4) network, and encapsulating the first packet includes inserting a Sticky-Dst-SubTLV including the address of the egress router into a variable length options field in a Generic Network Virtualization Encapsulation (GENEVE) header. In one example, the ingress router is communicatively connected to the egress router over an internet protocol version six (IPv6) network, and encapsulating the first packet includes inserting a Sticky-Dst-SubTLV including the address of the egress router into an IPv6 destination options header field of the IPv6 packet. In one example, the method further comprises: the receiver receiving a second packet from the egress router; the processor decapsulating the second packet to obtain a header including the Sticky-Dst-SubTLV; the memory storing the Sticky-Dst-SubTLV into an entry in the Sticky-Dst-SubTLV table; the transmitter transmitting the second packet to the UE. In some examples, the entry in the sticky traffic table includes a timer.The method can further include refreshing the timer in the table entry each time the Sticky-Dst-SubTLV is received in a packet, and deleting the table entry when the timer expires.

[0191] Figure 17 Another example Sticky-Dst-SubTLV structure 1700. The Sticky-Dst-SubTLV structure 1700 is similar to the Sticky-Dst-SubTLV structure 600, and can be used in a similar manner to the Sticky-Dst-SubTLV structure 600. For example, the Sticky-Dst-SubTLV structure 1700 can be included in the IPv6 Destination Options header 500 and / or 1600. The Sticky-Dst-SubTLV structure 1700 can include a sticky type field 1701 and a length field 1703, which can be substantially similar to the sticky type field 601 and the length field 603, respectively, of the Sticky-Dst-SubTLV structure 600. The Sticky-Dst-SubTLV structure 1700 further includes a reserved field 1705, which can be 16 bits in length and can extend from bit position 16 to bit position 31. The reserved field 1705 can be reserved for other functions. The Sticky-Dst-SubTLV structure 1700 further includes a flow label field 1707, which can be 20 bits in length and can extend from bit position 0 to bit position 19. The flow label field 1707 can be set to a value to indicate that the flow should be considered sticky. If the Sticky-Dst-SubTLV is generated first, the flow label field 1707 can be set to the same flow label extracted from the flow label field 1605 in the IPv6 fixed header of a received packet. The Sticky-Dst-SubTLV structure 1700 further includes a reserved field 1711, which can be 12 bits in length and can extend from bit position 20 to bit position 31. The reserved field 1711 can be reserved for other functions. The Sticky-Dst-SubTLV structure 1700 further includes an egress router or tunnel endpoint field 1711, which can be 32 bits in length and can extend from bit position 0 to bit position 31. The egress router or tunnel endpoint field 1711 can be set to 1 to indicate a 32-bit identifier for representing an egress router. The original egress router identifier can assume that in a 5G edge computing environment, all routers have a 32-bit identifier, even though they can use an IPv6 address. In one example, the sticky type field 1701 can be set to 2 to indicate a tunnel endpoint SubTLV for representing an egress router from an original site before the UE moves to a new site.

[0192] Figure 18An exemplary route extension header 1800 for use by sticky traffic. The route extension header 1800 is an extension header placed between the fixed header 1700 and upper layer protocol headers, which can be used to include a Sticky-Dst-SubTLV, such as the Sticky-Dst-SubTLV structure 600 and / or 1700. The route extension header 1800 includes a next header field 1801, which can be 8 bits in length and can extend from bit position 0 to bit position 7. The next header field 1801 can be set to identify the type of header immediately following the route extension header 1800. The route extension header 1800 also includes a header extension length field 1803, which can be 8 bits in length and can extend from bit position 8 to bit position 15. The header extension length field 1803 can be set to indicate the route extension header 1800 in units of eight octets, not including the first eight octets. The route extension header 1800 also includes a route type field 1805, which can be 8 bits in length and can extend from bit position 16 to bit position 23. The route type field 1805 can be set to a value indicating a particular route extension header 1800 variant. The route extension header 1800 also includes a remaining segment field 1811, which can be 8 bits in length and can extend from bit position 24 to bit position 31. The remaining segment field 1811 can be set to indicate the number of remaining route segments, such as the number of explicitly listed intermediate nodes that will still be visited before reaching the final destination. The route extension header 1800 also includes a type specific data field 1813, which can be variable in length and have a format determined by the route type indicated in the route type field 1805. For example, the length of the type specific data field 1813 can be such that the complete route extension header 1800 is an integer multiple of 8 octets in length. In the present example, a Sticky-Dst-SubTLV, such as the Sticky-Dst-SubTLV structure 600 and / or 1700, is inserted into the type specific data field 1813 of the route extension header 1800 included in an IPv6 header. The route extension header 1800 can be used by an IPv6 source to list one or more intermediate nodes to be visited on the way to the destination of a packet. The route extension header 1800 can be identified by a next header value of 43 in the immediately preceding header.

[0193] This section describes a technical solution that can prioritize the ingress router receiving packets. For example, an edge computing server can have instances connected to four different egress routers (denoted as R1, R2, R3, and R4, respectively). For packets of flow A, the priority is to send to the instance connected to R1 (e.g., egress router 131). When R1 fails, which can be caused by various factors such as connection loss or other failures, packets of flow A can be forwarded to the instance connected to R2, R3, or R4 (e.g., one of egress routers 135) according to network cost. The following is an example process to implement such location-priority forwarding for anycast locations.

[0194] Each server instance can be configured with multiple anycast addresses. Location-priority anycast addresses can be used to make a particular location a priority. When the priority location fails, packets are forwarded to other locations. For example, for flow A, three different anycast addresses are assigned and denoted as L1, L2, L3, and L4. For example, when connected to R1, the cost of anycast address L1 is the lowest. When connected to R2, R3, and R4, the cost of L1 is higher, e.g., 30. Anycast L2 has the lowest cost for the instance connected to R2, and a higher cost for the instances connected to R1 and R3, respectively. Anycast L3 has the lowest cost for the instance connected to R3, and a higher cost for the instances connected to R1, R2, and R4, respectively. Anycast L4 has the lowest cost for the instance connected to R4, and a higher cost for the instances connected to R1, R2, and R3, respectively.

[0195] For sticky traffic that should be sent to the instance on R1, the ingress router directly connected to the 5G PSA can replace the destination address with L1, directing the packet to R1. If R1 fails, packets of flow A are sent to R2 or R3 according to network cost. For the above process, egress router R1 can insert L1 into the egress router ID of the Sticky-Dst-SubTLV. This will cause the ingress router of the new 5G site to send packets to L1, which will be sent to R1 if R1 has not failed. Otherwise, the packet will be forwarded to other egress routers of the instance. Alternatively, the local DNS resolver can reply with L1, L2, or L3 according to the source of the DNS request to direct the packet to the preferred site of the edge computing server instance.

[0196] The techniques described herein are not only applicable to 5G edge networks, but also to other network environments such as data center networks, enterprise networks, and operator backbones.

[0197] A first component is directly coupled to a second component when there are no intervening components between the first and second components other than a wire, trace, or other medium. A first component is indirectly coupled to a second component when there are intervening components between the first and second components other than a wire, trace, or other medium. The term "coupled" and variations thereof are used herein to include both direct and indirect coupling. The use of the term "about" means ±10% of the number described unless otherwise indicated.

[0198] It should also be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps can be included or existing steps can be removed, or one or more steps can be added to or integrated with other steps as desired.

[0199] While the present application provides a number of specific embodiments, it should be understood that the disclosed systems and methods can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present examples are therefore to be considered in all respects as illustrative and not restrictive, and the scope of the application should be governed by the appended claims. For example, various elements or components can be combined, eliminated, or added to other systems or methods without departing from the scope of the present application.

[0200] Furthermore, the described features, systems, subsystems and methods can be combined in various ways without departing from the spirit or scope of the present application. Other variations and modifications of the examples disclosed herein can be made based on the description set forth herein, without departing from the scope and spirit of the disclosure.

Claims

1. A service flow transmission method, characterized in that, The service flow transmission method is applied to a user equipment (UE), and the method includes: The UE sends a first message to the anycast address of the server, and the first message is associated with the sticky service flow; The UE receives a second message of the flow from the server. The second message of the flow includes an Internet Protocol (IP) extended header with a sticky destination subtype length value (Sticky-Dst-SubTLV), wherein the Sticky-Dst-SubTLV includes the address of the egress router connected to the server. The UE copies the Sticky-Dst-SubTLV to the IP extension header of the third packet of the flow; The UE sends the third message with the Sticky-Dst-SubTLV.

2. The method according to claim 1, characterized in that, The IP extension header of the second message is an Internet Protocol version six (IPv6) destination options header, and the Sticky-Dst-SubTLV is included in the IPv6 destination options header.

3. The method according to claim 1 or 2, characterized in that, The first message, the second message, and the third message are sent by the UE to the first Protocol Data Unit (PDU) session anchor (PSA) in the first mobile network site. The method further includes: The UE copies the Sticky-Dst-SubTLV to the IP extension header of the fourth packet of the flow; The UE sends the fourth message with the Sticky-Dst-SubTLV to the second PSA in the second mobile network site, for transmitting the fourth message to the server through the egress router specified in the Sticky-Dst-SubTLV.

4. The method according to any one of claims 1 to 3, characterized in that, The Sticky-Dst-SubTLV includes the viscous type.

5. The method according to claim 4, characterized in that, The Sticky-Dst-SubTLV includes a stream label.

6. A service flow transmission method, characterized in that, The method is applied to an ingress router, and the method includes: The ingress router receives a first message from user equipment (UE) destined for an anycast address of the server. The first message is associated with a sticky service flow and includes an Internet Protocol (IP) extension header with a sticky destination subtype length value (Sticky-Dst-SubTLV), which includes the address of the egress router. The ingress router determines that the destination of the first packet matches the access control list (ACL) of the sticky service; The ingress router sends the first message based on the Sticky-Dst-SubTLV extracted from the first message.

7. The method according to claim 6, characterized in that, The Sticky-Dst-SubTLV includes the viscous type.

8. The method according to claim 6 or 7, characterized in that, The IP extension header of the second message is an Internet Protocol version six (IPv6) destination options header, and the Sticky-Dst-SubTLV is inserted into the IPv6 destination options header.

9. The method according to any one of claims 6 to 8, characterized in that, Before sending the first message, the method further includes: The ingress router encapsulates the first packet in a channel whose outer destination address is set to the egress address extracted from the Sticky-Dst-SubTLV.

10. The method according to any one of claims 6 to 9, characterized in that, Also includes: The ingress router sends sticky service entries to neighboring ingress routers in the adjacent ingress group to support the routing of subsequent packets to the server when the UE moves between mobile network sites, wherein the sticky service entries include the address of the egress router.

11. A service flow transmission method, characterized in that, The method is applied to a server, and the method includes: The server receives a first message from the user equipment (UE) via a data network, wherein the first message includes the server's anycast address and is associated with a sticky service flow; The server inserts a sticky destination subtype lengthvalue (Sticky-Dst-SubTLV) into the Internet Protocol (IP) extension header of the second message of the flow, wherein the Sticky-Dst-SubTLV includes the address of the egress router connected to the server; The server sends the second message with the Sticky-Dst-SubTLV to the UE through the data network.

12. The method according to claim 11, characterized in that, The Sticky-Dst-SubTLV includes the viscous type.

13. The method according to claim 11 or 12, characterized in that, The IP extension header of the second message is an Internet Protocol version six (IPv6) destination options header, and the Sticky-Dst-SubTLV is inserted into the IPv6 destination options header.

14. The method according to any one of claims 11 to 13, characterized in that, Before sending the first message, the method further includes: The ingress router encapsulates the first packet in a channel with an outer destination address set to the egress address extracted from the Sticky-Dst-SubTLV.

15. A service flow transmission method, characterized in that, The method is applied to an export server, and the method includes: The egress router receives a first message destined for the server from the user equipment (UE) via the first ingress router, wherein the first message is associated with a sticky service flow; The egress router sends the first message to the server; The egress router receives a second message of the flow from the server, wherein the second message is sent to the UE; The egress router inserts a sticky destination subtype lengthvalue (Sticky-Dst-SubTLV) into the Internet Protocol (IP) extension header of the second message, wherein the Sticky-Dst-SubTLV includes the address of the egress router; The egress router sends the second message with the Sticky-Dst-SubTLV to the first ingress router.

16. The method according to claim 15, characterized in that, The IP extension header of the second message is an Internet Protocol version six (IPv6) destination options header, and the Sticky-Dst-SubTLV is inserted into the IPv6 destination options header.

17. The method according to claim 16, characterized in that, The Sticky-Dst-SubTLV includes the viscous type.

18. The method according to any one of claims 15 to 17, characterized in that, The first ingress router is coupled to a first Protocol Data Unit (PDU) session anchor (PSA) in the first mobile network site. When traffic from the UE is anchored to the first PSA at the first mobile network site, the first packet is received from the first ingress router.

19. The method according to any one of claims 15 to 18, characterized in that, Also includes: The egress router receives a third message of the flow from the second ingress router, wherein the third message is sent to the anycast address of the server and includes the Sticky-Dst-SubTLV; The egress router sends the third message to the server.

20. The method according to claim 19, characterized in that, The second ingress router is coupled to the second PSA in the second mobile network site, and receives the third message from the second ingress router when traffic from the UE is anchored to the second PSA in the second mobile network site.

21. A network element, characterized in that, include: Non-transitory memory, including instructions; One or more processors communicate with the non-transient memory, wherein the one or more processors execute the instructions to perform the method according to any one of claims 1 to 20.

22. A non-transitory computer-readable medium, characterized in that, The invention includes a computer program product for use by a network element, wherein the computer program product includes computer-executable instructions stored in the non-transitory computer-readable medium, such that when a processor executes the computer-executable instructions, the network element performs the method according to any one of claims 1 to 20.

23. An export router, characterized in that, include: Non-transitory memory, including instructions; One or more processors communicate with the non-transient memory, wherein the one or more processors execute the instructions to perform the method according to any one of claims 15 to 20.

24. A user equipment (UE), characterized in that, include: Non-transitory memory, including instructions; One or more processors communicate with the non-transient memory, wherein the one or more processors execute the instructions to perform the method according to any one of claims 1 to 5.

25. An ingress router, characterized in that, include: Non-transitory memory, including instructions; One or more processors communicate with the non-transient memory, wherein the one or more processors execute the instructions to perform the method according to any one of claims 6 to 10.

Images