Patent Description:
There is a need to provide for increased efficiency and optimization in the routing of user plane traffic in a mobile network to accommodate for mobility.

<CIT> describes a method and apparatus for supporting distributed and dynamic mobility management, with multiple flows anchored at different gateways.

"<NPL>, describes SDN-based distributed mobility management in <NUM> networks, and the scalability and performance of such methods.

<NPL>, describes the applicability of SRv6 to the user-plane of mobile networks.

Numerous details are described in order to provide a thorough understanding of the example implementations shown in the drawings. However, the drawings merely show some example aspects of the present disclosure and are therefore not to be considered limiting. Moreover, well-known systems, methods, components, devices and circuits have not been described in exhaustive detail so as not to obscure more pertinent aspects of the example implementations described herein.

Methods and apparatus for use in adaptively rerouting user plane traffic for mobility using a segment routing (SR) for IPv6 (SRv6) protocol are described herein. Advantageously, a mobility-aware, floating anchor (MFA) may be provided in a mobile network.

In some implementations, a technique of the present disclosure may be performed at one or more controllers of a control plane (CP) entity for a mobile network. In an illustrative example, a message indicating an attachment of a mobile node (MN) to the mobile network is received, where a first user plane (UP) anchor node (e.g. a GW-U) is selected for the MN. A first set of home network prefixes (HNPs) and a first set of local network prefixes (LNPs) are allocated to the MN. An IP traffic flow to and/or from a first HNP prefix of the MN is established between the MN and a correspondent node (CN) along a first network path. The first network path may be selected with use of a destination-based routing protocol, and defined by a first plurality of nodes which include the first UP anchor node of the MN and an anchor node of the CN.

In response to a handover of the MN in the mobile network, a message indicating a subsequent attachment of the MN to the mobile network is received, where a second UP anchor node is selected for the MN. The second UP anchor node is instructed to host the first HNP prefix previously allocated by the first UP anchor node. Further, at least one of the first UP anchor node, the second UP anchor node, and the anchor node of the CN may be subsequently provisioned with one or more rules, for instruction to perform SRv6 routing or rerouting of an IP traffic flow to and/or from the first HNP prefix of the relocated MN, to optimize such IP traffic flow. At least some of such provisioning may be performed in response to anchor node reports of IP traffic flow to and/or from the first HNP prefix.

As one example, the anchor node of the CN may be provisioned with one or more rules, for instructing the anchor node to perform SRv6 routing of a downlink IP traffic flow from the CN to the (relocated) MN along a second network path defined by a second plurality of nodes. The second plurality of nodes include the second UP anchor node and exclude the first UP anchor node, for optimizing the IP traffic flow.

Note that, at some time with the new, second UP anchor node, a second set of HNPs may be allocated to the MN, where new network paths for newly-established IP traffic flows to and/or from a second HNP prefix of the MN may be selected based on the destination-based routing protocol.

<FIG> are illustrative block diagrams of communication networks operative to route IP traffic flows with use of a segment routing (SR) for IPv6 (SRv6) protocol. In general, SRv6 is a source-based routing protocol which is different from a destination-based routing protocol. The following description in relation to <FIG> illustrates a few basic concepts of SRv6.

With reference to <FIG>, a communication network 100a which includes a plurality of nodes <NUM> (e.g. routers, servers, gateways, etc.) is shown. In this example, the plurality of nodes <NUM> includes nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> which are designated as nodes A, B, C, D, E, F, G, H, and Z, respectively. Here, node <NUM> (i.e. node A) is considered to be a source node and node <NUM> (i.e. node Z) is considered to be a destination node. Nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> which correspond to nodes B, C, D, E, F, and G are part of an SR domain (i.e. nodes that are SRv6-capable nodes / SRv6-configured nodes). The source node (node <NUM> or A) and the destination node (node <NUM> or Z) are not part of or outside of the SR domain (e.g. they may or may not be SRv6-configured nodes, such as "regular" IPv6 nodes).

A basic data format of an SR-IPv6 packet <NUM> for use in SRv6 routing is also shown in <FIG>. As illustrated, the data format of SR-IPv6 packet <NUM> includes an IPv6 header <NUM> and a payload <NUM>. For SRv6 routing of IPv6 packet <NUM>, the data format of IPv6 packet <NUM> further includes an SR header <NUM> or "SRH" (i.e. an extension header for SR as defined by RFC <NUM>). SR header <NUM> may include an ordered list of segments <NUM> which defines a network path <NUM> along which the SR-IPv6 packet <NUM> will be communicated in communication network 100a. In the example of <FIG>, the ordered list of segments <NUM> includes node <NUM> ("node C"), node <NUM> ("node F"), and node <NUM> ("node H") in network path <NUM>. A segment is or includes an instruction (e.g. forwarding, servicing, application-specific, etc.) to be applied to the SR-IPv6 packet <NUM>.

Thus, an SR-IPv6 packet (e.g. SR-IPv6 packet <NUM>) may be communicated in communication network 100a from a source node (e.g. node <NUM> or A) to a destination node (e.g. a node <NUM> or Z) along a desired or predetermined network path <NUM>. The source node (e.g. node <NUM> or A) may operate to choose this network path <NUM> and encode it in the SR header <NUM> as the ordered list of segments <NUM>. The rest of communication network 100a may operate to execute the encoded instructions without any further per-flow state.

<FIG> is an illustrative representation of a communication network 100b which is similar to communication network 100a of <FIG>. In <FIG>, nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> which correspond to nodes B, C, D, E, F, and G are shown to be part of an SR domain <NUM>. The source node (node <NUM> or A) and the destination node (node <NUM> or Z) are not part of or outside of the SR domain <NUM> (e.g. they may or may not be SRv6-configured nodes). In the example of <FIG>, node <NUM> or B may be considered as an ingress node of the SR domain <NUM> and node <NUM> or G may be considered as an egress node of the SR domain <NUM>.

Note that an SR header may be inserted in an IPv6 packet at a source node or at an ingress node, or even encapsulated at the ingress node, as a few examples. In the example shown in <FIG>, an SR header of an IPv6 packet is inserted at the source node (node <NUM> or A) to produce an SR-IPv6 packet 190b. In this case, the source node (node <NUM> or A) which is SRv6-capable may originate the SR-IPv6 packet 190b. Here, the SR header of SR-IPv6 packet 190b includes an ordered list of segments (SL) designating nodes B, D, G, and Z to define network path <NUM>. Initially, a source address (SA) of SR-IPv6 packet 190b is designated as node A and a destination address (DA) of SR-IPv6 packet 190b is designated as node B (i.e. the first node in the SL). When SR-IPv6 packet 190b is communicated to the ingress node (i.e. node <NUM> or B), the DA is modified by the ingress node to include the next or second node in the SL (i.e. node D), as indicated in SR-IPv6 packet 192b. When SR-IPv6 packet 192b is communicated to the node D (via node C), the DA is modified by node D to include the next or third node in the SL (i.e. node G), as indicated in SR-IPv6 packet 194b. When SR-IPv6 packet 194b is further communicated to the node G (via node F), the DA is modified by node G to include the next or fourth node in the SL (i.e. node Z which is the destination node), as indicated in SR-IPv6 packet 196b.

In the example of <FIG>, an SR header of an IPv6 packet 190c is inserted at the ingress node (node <NUM> or B) to produce an SR-IPv6 packet 192c. Here, the SR header of SR-IPv6 packet 192c includes an ordered list of segments (SL) designating nodes D, G, and Z to define network path <NUM>. In this case, the source node, which may or may not be SRv6-configured, may originate the IPv6 packet 190c without any SR header. When SR-IPv6 packet 192c is communicated to node D (via node C), the DA is modified by node D to include the next or second node in the SL (i.e. node G), as indicated in SR-IPv6 packet 194c. When SR-IPv6 packet 194c is further communicated to the node G (via node F), the DA is modified by node G to include the next or third node in the SL (i.e. node Z, which is the destination node) and the SR header is removed, as indicated in IPv6 packet 196c. Here, similar to the source node, the destination node may or may not be SRv6-configured.

In the example of <FIG>, the source node, which may or may not be SRv6-configured, originates an IPv6 packet 190d without any SR header. The ingress node (node <NUM> or B) operates to encapsulate IPv6 packet 190d with a new, outer IPv6 header followed by an SR header, to produce an SR-IPv6 packet 192d. The SL of the SR header includes nodes D and G, but does not include the destination node (node <NUM> or Z). When SR-IPv6 packet 192d is communicated to node D (via node C), the DA is modified by node D to include the next or second node in the SL (i.e. node G), as indicated in SR-IPv6 packet 194d. When SR-IPv6 packet 194d is further communicated to the node G (via node F), the SR-IPv6 packet 194d is decapsulated by node G, which is represented by SR-IPv6 packet 196d. Here, similar to the source node, the destination node may or may not be SRv6-configured.

As one ordinarily skilled in the art would readily appreciate, the current state of the art for SRv6 is further described in various standards-related documents, including Internet Engineering Task Force (IETF) documents, such as "Segment Routing Architecture" identified by "draft-ietf-spring-segment-routing-<NUM>"; "IPv6 Segment Routing Header (SRH)" identified by "draft-ietf-6man-segment-routing-header-<NUM>"; and "SRv6 Network Programming" identified by "draft-filsfils-spring-srv6-network-programming-<NUM>".

Advantageously, methods and apparatus of the present disclosure leverage the current state of the art of SRv6, for use in the adaptive rerouting of user plane traffic for mobile nodes (MN) in a mobile network. The methods and apparatus of the present disclosure may be implemented in any suitable type of mobile network. The mobile network may be, for example, <NUM> Long Term Evolution (LTE)-based mobile network or a <NUM> mobile network.

Reference is now made to <FIG>, which shows a network architecture <NUM> of a <NUM>, LTE-based mobile network in which techniques and components of the present disclosure may be implemented. The mobile network of <FIG> may be configured with a control plane (CP) and user plane (UP) separation architecture which is described later in relation to <FIG>.

Network architecture <NUM> of the <NUM>, LTE-based network of <FIG> includes a mobility management entity (MME) <NUM>, a serving GPRS support node (SGSN) <NUM>, a home subscriber server (HSS) <NUM>, a service capability exposure function (SCEF) <NUM>, a policy and charging rules function (PCRF) <NUM>, a serving gateway (GW) <NUM> or S-GW, and a packet data network (PDN) gateway <NUM> or P-GW. A business support system (BSS) <NUM> may also be connected to the network. A plurality of interfaces shown in network architecture <NUM> of <FIG> (e.g. LTE-Uu, S1-U, S <NUM>-MME, S3, S4, S5, S6a, S10, S11, S12, Gx, Rx, SGi, S6t, and an NB REpresentational State Transfer (REST) Application Programming Interface (API)) may define the communications and/or protocols between each of the entities, as described in the relevant standards documents for LTE. An operator may provide an IP service network <NUM> with connection to the network via PCRF <NUM> and PDN gateway <NUM>. The IP service network <NUM> may provide various IP services, such as IP multimedia subsystem (IMS), packet switched stream (PSS), etc. An application server (AS) <NUM> may connect to the mobile network via SCEF <NUM>.

A user equipment (UE) <NUM> (one type of a mobile node or MN) may obtain access to the mobile network via a Universal Terrestrial Radio Access Network (eUTRAN) which may include one or more base stations (eNodeBs or eNBs) and one or more radio network controllers (RNCs). In the present disclosure, a UE <NUM> operating in the LTE-based mobile network may be any suitable type of device, such as a cellular telephone, a smart phone, a tablet device, a laptop computer, an Internet of Things (IoT) device, and a machine-to-machine (M2M) communication device, to name but a few. For additional network access for UEs, one or more additional UTRANs <NUM> and one or more GSM edge radio access networks (GERAN) <NUM> may be connected in the network.

In some implementations of the present disclosure, the techniques are embodied in one or more components of the mobile network configured with control plane (CP) and user plane (UP) separation. An architecture <NUM> for separation of a control plane (CP) <NUM> and a user plane (UP) <NUM> is conceptually illustrated in <FIG>. The left side of <FIG> illustrates equipment and/or entities of the architecture without the CP and UP separation, showing MME <NUM> and S/PGW equipment <NUM>/<NUM> including a S/PGW-C <NUM> (i.e. as part of the CP), a GW-U <NUM> (i.e. as part of the UP), and service point functionality <NUM> for charging and accounting (and perhaps other services, such as lawful intercept). The right side of <FIG> illustrates equipment and/or entities of the architecture <NUM> with the separation and modularization of the CP <NUM> and the UP <NUM> (a C/U "split"), showing MME <NUM>' and S/PGW <NUM>' (the CP <NUM>) being separated from GW-U <NUM>' and its service point functionality <NUM>' (the UP <NUM>).

Note that some techniques of the present disclosure may be implemented in one or more controllers of the CP entity of a mobile network. Accordingly, in a <NUM> LTE-based mobile network, the techniques may be implemented in a mobility management entity (MME) and/or a gateway control plane (GW-C) of the mobile network, where the UP entities may be (or be part of) gateway user planes (GW-U) which serve as service points for accounting and charging. In a <NUM> mobile network, the techniques may be implemented in an access and mobility management function (AMF) and/or a session management function (SMF), where the UP entities may be user plane functions (UPFs) which serve as the service points for accounting and charging.

Referring ahead now to <FIG>, what is shown is a more general illustrative representation 400a of a mobile network, according to some implementations of the present disclosure. A mobile node (MN), such as an MN-<NUM><NUM>, may access a core network (CN) of the mobile network via a radio access network (RAN). The RAN includes a plurality of base stations <NUM> (e.g. eNodeBs, eNodeGs, access points or APs etc.). Each one of a plurality of access gateways (AGs) <NUM> may be associated with one or more of the base stations <NUM>. AGs <NUM> may be anchor nodes for MNs and provide UP functions for UP traffic of the MNs. The CN of the mobile network includes a plurality of routers <NUM>, sometimes referred to as transit routers, which may be used to route such UP traffic. In <FIG>, routers <NUM> are shown to include routers <NUM>, <NUM>, <NUM>, and <NUM>, designated as routers R1, R2, R3, and R4, respectively.

The mobile network 400a also includes a mobility controller (MC) <NUM> and a transport controller (TC) <NUM>. MC <NUM> / TC <NUM> are configured to perform conventional CP functions, as well as to perform the adaptive rerouting techniques of the present disclosure. For this purpose, MC <NUM> and/or TC <NUM> maintain access to a policy database (DB) <NUM>, a network topology DB <NUM>, and a mobile node location table <NUM>. Policy DB <NUM> is for storing policy or routing rules information associated with routing or SRv6. Network topology DB <NUM> is for storing network topology information which characterizes a network topology of the mobile network. Mobile node location table <NUM> is for storing associations between MNs and their assigned/allocated IP addresses, and between MNs and their assigned anchor nodes. Such information, as well as the use thereof, will become more clear in relation to the flowcharts and call flows provided in the remaining figures.

Each one of routers <NUM> or AGs <NUM> may be equipped with plurality of software functions or modules, including one or more destination-based routing protocols, an SRv6 routing protocol with network programming features, and one or more interfaces with for programmability with the MC / TC (see e.g. the description in relation to <FIG> provided later below). The one or more destination-based routing protocols may include one or more of Internet Group Management Protocol (IGMP), Intermediate System to Intermediate System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), or the like. If the device is a gateway or the like (access gateway or GW-U), it may further include user plane (UP) functionality for user plane traffic.

Today's mobile routing practice typically involves fixed anchoring techniques and/or extensive tunneling from the user plane to accommodate mobility. Accordingly, there is a need to provide for increased efficiency and optimization in the routing of user plane traffic in a mobile network to accommodate for mobility.

Referring now to <FIG>, what are provided are flowcharts for describing methods of adaptively rerouting user plane traffic for MNs with use of SRv6, according to some implementations of the present disclosure. More detailed techniques are described later in relation to the call flows in <FIG>, <FIG>, and <FIG>. The methods of <FIG> may be performed by one or more controllers (e.g. an MC <NUM> and/or TC <NUM>) of a CP entity in a mobile network. The methods may also be embodied as a computer program product including a non-transitory computer readable medium and instructions stored in the non-transitory computer readable medium, where the instructions are executable on one or more processors or performing the steps of the method.

The flowcharts of <FIG> will now be described with reference to their associated mobile network illustrations in <FIG>. Description of the flowcharts of <FIG> will now begin with the flowchart 300a of <FIG>.

Beginning at a start block <NUM> of <FIG>, a message indicating an attachment of a MN to a mobile network is received, where a first user plane (UP) anchor node is selected for the MN (step <NUM> of <FIG>). The first UP anchor node may be selected for the MN based on its local proximity to the MN (e.g. the closest UP anchor node). Next, a set of home network prefixes (HNPs) is allocated to the MN, selected from a HNP prefix block of the first UP anchor node (step <NUM> of <FIG>). Note that this allocated set of HNPs is topologically anchored at the first UP anchor node; however, the assigned HNP will remain as a stable prefix for the MN to accommodate mobility. A first set of local network prefixes (LNPs) is also allocated to the MN, selected from a first LNP prefix block of the first UP anchor node (step <NUM> of <FIG>). Note that, in contrast to the allocated set of HNPs, the allocated first set of LNPs, topologically anchored at the first UP anchor node, will not provide mobility support.

Thus, the MN is attached to the mobile network and assigned with HNPs and LNPs. With reference to an illustrative representation 400b of the mobile network in <FIG>, MN-<NUM><NUM> may attach to the mobile network via a base station <NUM> (or access point or AP). The (local or closest) UP anchor node that is selected for MN-<NUM><NUM> is access gateway <NUM> (AG-<NUM>) <NUM>. The HNP assigned to MN-<NUM><NUM> is P1::/<NUM>.

Continuing with <FIG>, an IP traffic flow is established between the MN and a correspondent node (CN) along a first network path defined by a first plurality of nodes (step <NUM> of <FIG>). The IP traffic flow may be to and/or from a first HNP prefix allocated to the MN. The first network path for routing the IP traffic may be selected with use of a destination-based routing protocol. The destination-based routing protocol may be, for example, an Internet Group Management Protocol (IGMP), an Intermediate System to Intermediate System (IS-IS), an Open Shortest Path First (OSPF), or a Routing Information Protocol (RIP), to name but a few. The first plurality of nodes of the first network route include the first UP anchor node and an anchor node for the CN. The first UP anchor node of the MN-<NUM> will be the service point for charging and accounting (and perhaps other services, such as lawful intercept) for the MN.

Thus, an IP traffic flow between the MN and the CN is established over a first network path through the mobile network, with use of the first HNP prefix of the MN. With reference to an illustrative representation 400c of the mobile network in <FIG>, a network path <NUM> for an IP traffic flow between MN-<NUM><NUM> and a CN-<NUM><NUM> (connected in the mobile network via a base station <NUM>) is shown. The network path <NUM> includes a plurality of nodes AG-<NUM><NUM>, R2 <NUM>, and AG-<NUM><NUM>. AG-<NUM> is the access gateway (anchor node) for CN-<NUM><NUM>. <FIG> further illustrates an additional IP traffic flow between MN-<NUM><NUM> and a CN-<NUM><NUM> (connected to the Internet <NUM>) over another network path <NUM>. R3 <NUM> is the anchor node for CN-<NUM><NUM>. This other network path <NUM> includes a plurality of nodes AG-<NUM><NUM> and R3 <NUM>. R3 <NUM> is the anchor node for CN-<NUM><NUM> General information regarding the network paths is provided in a table <NUM> of <FIG>. In this configuration/routing, there is no special tunneling or special forwarding rules in place to steer IP traffic flows for the MN (i.e. there is no SRv6 steering rules in place for these IP traffic flows).

Continuing with a flowchart 300b in <FIG> via a connector A, in response to a handover of the MN, a message indicating a subsequent attachment of the MN to the mobile network is received, where a second UP anchor node is selected for the MN (step <NUM> of <FIG>). The second UP anchor node may be selected for the MN based on its local proximity to the MN (e.g. the closest UP anchor node). The second UP anchor node is instructed to host the set of HNPs previously assigned to the MN by the first anchor node (step <NUM> of <FIG>). Thus, the MN may continue to use the set of HNPs obtained from its initial attachment. In addition, a second set of LNPs are allocated to the MN from a second LNP prefix block of the second UP anchor node (step <NUM> of <FIG>). Note that the allocated set of LNPs are topologically anchored at the second UP anchor node. The first set of LNPs are deallocated from the MN (step <NUM> of <FIG>). The second UP anchor node of the MN-<NUM> will be the service point for charging and accounting (and perhaps other services, such as lawful intercept) for the MN.

Thus, the MN is reattached to the mobile network and assigned with a new, second UP anchor node, maintaining its previous HNPs and having newly-assigned LNPs. With reference to an illustrative representation 400d of the mobile network in <FIG>, for the handover, MN-<NUM><NUM> has reattached to the mobile network via a new base station <NUM> (or access point or AP). Here, the new (local) UP anchor node that is selected for MN-<NUM><NUM> is an access gateway <NUM> (AG-<NUM>) <NUM>, which will be the new service point for charging and accounting (and perhaps other services, such as lawful interept) for the MN. The HNPs of MN-<NUM><NUM> are maintained as P1::/<NUM> and the newly-assigned LNPs are P2::/<NUM>.

Continuing with <FIG>, sometime after the handover of the MN, at least one of the anchor nodes is provisioned to perform segment routing (SR) for IPv6 (SRv6), for rerouting and/or optimizing the network paths (step <NUM> of <FIG>). The rerouting and/or optimized network paths may be determined or selected based on IP traffic flow information (e.g. indicating unoptimized IP traffic flow) and network topology information which characterizes a network topology of the mobile network. The provisioned SRv6 routing may generally employ the SRv6 routing techniques described earlier in relation to <FIG> and elsewhere herein, using SRv6 network programing, for "steering" the IP traffic flows optimally as needed or desired.

The provisioning of such policy rules in step <NUM> of <FIG> may be performed with use of any suitable protocol. For example, a suitable protocol for provisioning such rules may be a Forwarding Policy Configuration (FPC) protocol (see e.g. "Protocol for Forwarding Policy Configuration" as described in draft-ietf-dmm-fpc-cpdp-<NUM>. txt); a 3GPP GPRS Tunneling Protocol (GTP) Control Plane Protocol (GTP-C); an OpenFlow protocol (e.g. OpenFlow version <NUM>. <NUM>); and Network Configuration Protocol (NETCONF) (e.g. described in RFC <NUM>) and YANG (e.g. RFC <NUM>).

Continuing with specific examples of step <NUM> provisioning in a flowchart 300c of <FIG> at a start block <NUM>, sometime after the handover, the anchor node of the CN may be provisioned with one or more rules, for instructing the anchor node to perform SRv6 routing of downlink IP traffic flow from the CN to the MN along a second network path defined by a second plurality of nodes (step 352a of <FIG>). Here, the second plurality of nodes may include the second UP anchor node and exclude the first UP anchor node, in a more efficient path (step 352b of <FIG>).

As another example provided in <FIG>, sometime after the handover, the first UP anchor node may be provisioned with one or more rules, for instructing the first UP anchor node to perform SRv6 routing of downlink IP traffic flow from the CN to the MN along a third network path defined by a third plurality of nodes (step 354a of <FIG>). Here, the third plurality of nodes may include the second UP anchor node, in a more efficient path (step 354b of <FIG>).

As an alternative example provided in <FIG>, sometime after the handover, the second UP anchor node may be instructed or provisioned to perform a destination-based routing of uplink IP traffic flow from the MN, along a fourth network path defined by a fourth plurality of nodes (step 356a of <FIG>). Here, the fourth network path may be a more optimal routing path (step 356b of <FIG>), as provided by at least some destination-based routing protocols. In some implementations, the instructing of performing the destination-based routing may be an implicit instruction (e.g. an implicit instruction to perform destination-based routing when no other overriding SRv6 rule is provisioned or provided).

Thus, the provisioning of SRv6 routing rules at the anchor nodes may be used to "steer" IP traffic flows as needed or desired. At least some SRv6 functions which may be used or activated for these purposes are provided in a table <NUM> of <FIG>. As shown, an SRv6 function which may be used or activated may depend on the anchor node and the direction of the IP traffic flow. As shown, an SRv6 function may be or include a "T. Insert" function or an "End. X" function. Note that the type of functions may change and depend on the type of access architecture. With use of such functions, network paths for IP traffic flows between a newly-located MN and the CN may be reconfigured for more optimal routing.

With reference to an illustrative representation 400e of the mobile network in <FIG>, a new network path <NUM> for IP traffic flows between MN-<NUM><NUM> and CN-<NUM><NUM> is illustrated. New network path <NUM> includes AG-<NUM><NUM> and AG-<NUM><NUM> and excludes AG-<NUM><NUM>. In addition, a new network path <NUM> for IP traffic flows between MN-<NUM><NUM> and CN-<NUM><NUM> is illustrated. New network path <NUM> includes AG-<NUM><NUM> and R3 <NUM> and excludes AG-<NUM><NUM>. General information regarding the updated network paths is provided in a table <NUM> of <FIG>.

Note that, sometime at the new second UP anchor node, a second set of HNPs may be allocated to the MN, where new network paths for newly-established IP traffic flows to and/or from a second HNP prefix of the MN may be selected based on the destination-based routing protocol, where the first HNP prefixes may (sometime later) be deallocated.

More details regarding the provisioning and reconfiguration in relation to the example of <FIG> will be described later in relation to the call flows of <FIG>, <FIG>, and <FIG>.

The provisioning of anchor nodes for rerouting may be performed at any suitable time or based on any suitable triggering mechanism. At least some of such provisioning may be performed in response to anchor node reports of IP traffic flow to and/or from the assigned first HNP prefix. <FIG> is a flowchart 300d for describing a method for use in triggering the provisioning of rules. Beginning at a start block <NUM> of <FIG>, in response to receiving the message indicating a subsequent attachment of the MN (e.g. as described earlier in step <NUM> of <FIG>) or an MN handover, an anchor node may be provisioned or instructed to report IP traffic flow information associated with subsequent receipt of (e.g. unoptimized) IP traffic flow associated with the MN (step <NUM> of <FIG>). Subsequently, one or more messages comprising a report of IP traffic flow information associated with a receipt of an (e.g. unoptimized) IP traffic flow may be received from the anchor node (step <NUM> of <FIG>). The reported IP traffic flow information may indicate a source address and a destination address of the IP traffic flow. An appropriate anchor node for provisioning/instructing may then be identified, from a mobile node location table, based on the reported IP traffic flow information (e.g. a source or destination address) (step <NUM> of <FIG>). The mobile node location table may provide stored associations between MNs and their assigned anchor nodes. After step <NUM>, provisioning at the appropriately-identified node for SRv6 routing may then be performed as described, for example, in relation to the flowchart 300c of <FIG>.

More details related to the example of <FIG> are now described in relation to the call flows of <FIG>, <FIG>, and <FIG>.

Referring now to <FIG>, a call flow 600a is provided to describe the initial configuration of nodes in the mobile network. The network topology DB and the mobile node location table is configured in the MC <NUM> / TC <NUM> (step <NUM> of <FIG>). CN-<NUM><NUM> is configured with an IP address of CAFÉ::<NUM> (step <NUM> of <FIG>). AG-<NUM><NUM> is configured with HNPs P2::/<NUM> and LNPs L2::/<NUM> prefix blocks for allocation to MNs (step <NUM> of <FIG>). AG-<NUM><NUM> is configured with HNPs P6::/<NUM> and LNPs L6::/<NUM> for allocation to MNs (step <NUM> of <FIG>). CN-<NUM> is configured with an IP address of BABA::<NUM> (step <NUM> of <FIG>). AG-<NUM><NUM> is selected as the gateway (anchor) for CN-<NUM><NUM> (step <NUM> of <FIG>). R3 <NUM> is selected as the exit gateway (anchor) for IP traffic flows for CN-<NUM><NUM> and CN-<NUM><NUM> (step <NUM> of <FIG>).

Continuing the description in <FIG> in a continued call flow 600b, an initial attachment of the MN-<NUM><NUM> to the mobile network and the initial establishment of IP traffic flows associated with MN-<NUM><NUM> are described. MN-<NUM><NUM> attaches to the mobile network, where AG-<NUM><NUM> is selected as the anchor (step <NUM> of <FIG>). MC <NUM> / TC <NUM> receives a message indicating that MN-<NUM><NUM> is attached to AG-<NUM><NUM> (step <NUM> of <FIG>). MC <NUM> / TC <NUM> performs access and authentication procedures with MN-<NUM><NUM> (step <NUM> of <FIG>).

After successful authentication, an IP address configuration procedure is performed (e.g. DHCPv6 / SLAAC) with AG-<NUM><NUM> and MN-<NUM><NUM> (step <NUM> of <FIG>). AG-<NUM><NUM> reports this IP configuration of MN-<NUM><NUM> to MC <NUM> / TC <NUM> (step <NUM> of <FIG>). MN-<NUM><NUM> obtains its allocated IP addresses, P2::<NUM>/<NUM> and L2::<NUM>/<NUM> (step <NUM> of <FIG>). MC <NUM> / TC <NUM> updates the location and IP configuration of MN-<NUM><NUM> in the mobile node location table (step <NUM> of <FIG>). More specifically (step <NUM> of <FIG>), the mobile node location table is updated to indicate MN-<NUM><NUM> is at AG-<NUM><NUM> with P1::<NUM>/<NUM> and L1::<NUM>/<NUM>; CN-<NUM><NUM> is at AG-<NUM><NUM> with P1::<NUM>/<NUM> and L1::<NUM>/<NUM>; and one or more nodes connected to the Internet are at R3 <NUM>.

Further as shown in <FIG>, IP traffic flows to and/or from MN-<NUM><NUM> are established between nodes using destination-based routing protocols. More specifically, an IP traffic flow is established between MN-<NUM><NUM> and CN-<NUM><NUM> as indicated (step <NUM> of <FIG>). An IP traffic flow is established between MN-<NUM><NUM> and CN-<NUM><NUM> as indicated (step <NUM> of <FIG>). An IP traffic flow is also established between MN-<NUM><NUM> and CN-<NUM><NUM> as indicated (step <NUM> of <FIG>).

Referring now to <FIG>, a call flow 700a is provided to describe actions that are performed in response to a handover of MN-<NUM><NUM> in the mobile network (e.g. provision or provide instructions to one or more anchor nodes to report IP traffic flows, provision or provide anchor nodes with SRv6 for more optimal routing, etc.). In <FIG>, a handover of MN-<NUM><NUM> occurs in the mobile network, where MN-<NUM><NUM> detaches and subsequently reattaches (step <NUM> of <FIG>). After the handover, the new anchor or access gateway that is selected for MN-<NUM><NUM> is AG-<NUM><NUM>. The MC <NUM> / TC <NUM> receives an event notification indicating that MN-<NUM><NUM> is now attached to AG-<NUM><NUM> (step <NUM> of <FIG>).

In response, MC <NUM> / TC <NUM> provisions AG-<NUM><NUM> (i.e. the previous anchor for MN-<NUM><NUM>) with a rule to reroute IP traffic flows for prefix P2::/<NUM> to AG-<NUM><NUM> directly using SRv6 (step <NUM> of <FIG>). In addition, MC <NUM> / TC <NUM> provisions AG-<NUM><NUM> (i.e. the previous anchor for MN-<NUM><NUM>) with a rule to report new IP traffic flows. Further, MC <NUM> / TC <NUM> instructs AG-<NUM><NUM> (i.e. the new anchor node for MN-<NUM><NUM>) to host prefix P2::/<NUM> on the link attached to MN-<NUM><NUM> (step <NUM> of <FIG>). In addition, MC <NUM> / TC <NUM> provisions AG-<NUM><NUM> (i.e. the new anchor for MN-<NUM><NUM>) with a rule to report unoptimized IP traffic flows associated with MN-<NUM><NUM>. State information for MN-<NUM>'s P2::/<NUM> is updated at AG-<NUM><NUM> (step <NUM> of <FIG>) and at AG-<NUM><NUM> (step <NUM> of <FIG>).

An IP address configuration procedure is performed (e.g. DHCPv6 / SLAAC) with AG-<NUM><NUM> and MN-<NUM><NUM> (step <NUM> of <FIG>). AG-<NUM><NUM> reports this IP configuration of MN-<NUM><NUM> to MC <NUM> / TC <NUM> (step <NUM> of <FIG>). MN-<NUM><NUM> obtains its IP addresses, P2::<NUM>/<NUM> and L6::<NUM>/<NUM> (step <NUM> of <FIG>). MC <NUM> / TC <NUM> updates the location and IP configuration of MN-<NUM><NUM> in the mobile node location table (step <NUM> of <FIG>). Note that MN-<NUM><NUM> does not detect the link change; prefix P2::<NUM> remains valid on the link (step <NUM> of <FIG>). In addition, new L2::/<NUM> is obtained, but previous L2::<NUM> is lost. At R3 <NUM>, P2::<NUM>/<NUM> is still reachable via AG-<NUM><NUM> (step <NUM> of <FIG>). At a previous local CN-<NUM><NUM>, IP traffic flow for MN-<NUM><NUM> is dead; previous local L2::<NUM> is unreachable (step <NUM> of <FIG>).

Continuing the description in <FIG> in a continued call flow 700b, an (unoptimized) IP traffic flow from CN-<NUM><NUM> to MN-<NUM><NUM> occurs as indicated in steps <NUM>(a), <NUM>(b), <NUM>(c) and <NUM>(d). In these steps, the network route of the IP traffic flow is CN-<NUM><NUM> → AG-<NUM><NUM> → AG-<NUM><NUM> → AG-<NUM><NUM> → MN-<NUM><NUM>. In response to receipt of the IP traffic flow, AG-<NUM><NUM> reports IP traffic flow information of the IP traffic flow to MC <NUM> / TC <NUM> (step <NUM> of <FIG>). The report includes the IP traffic flow between P4::<NUM> - P2::<NUM>. In response to receipt of the report, MC <NUM> / TC <NUM> looks up the anchor node for CN-<NUM><NUM> in the mobile node location table based on P4::<NUM> and identifies the anchor node as AG-<NUM><NUM> (step <NUM> of <FIG>). In response, MC <NUM> / TC <NUM> provisions AG-<NUM><NUM> with a rule to steer IP traffic flows for prefix P2::<NUM>/<NUM> to AG-<NUM><NUM> directly using SRv6 (step <NUM> of <FIG>). In addition, MC <NUM> / TC <NUM> provisions AG-<NUM><NUM> with a rule to report IP traffic flows for P2::<NUM>/<NUM> (step <NUM> of <FIG>).

Subsequently, an additional IP traffic flow occurs from CN-<NUM><NUM> to MN-<NUM><NUM> as indicated in steps <NUM>(a), <NUM>(b), and <NUM>(c). As provisioning for SRv6 optimization was provided in steps <NUM> and <NUM>, however, this IP traffic flow is now optimized (e.g. the IP traffic flow no longer traverses AG-<NUM><NUM>). The network route of the IP traffic flow is CN-<NUM><NUM> → AG-<NUM><NUM> → AG-<NUM><NUM> → MN-<NUM><NUM>. AG-<NUM><NUM> is the new service or control point for MN-<NUM><NUM> (step <NUM> of <FIG>); AG-<NUM><NUM> is no longer in the path for IP traffic flows of CN-<NUM><NUM> (step <NUM> of <FIG>). Similar operation may be performed according to steps <NUM> through <NUM> for IP traffic flows associated with CN-<NUM><NUM> (step <NUM> of <FIG>), where R3 <NUM> is the initial anchor node for CN-<NUM><NUM> but IP traffic flow for P2::/<NUM> is steered from R3 <NUM> to AG-<NUM><NUM> directly. IP traffic flows between MN-<NUM><NUM> and CN-<NUM><NUM> are now more optimized as indicated (step <NUM> of <FIG>). IP traffic flows between MN-<NUM><NUM> and CN-<NUM><NUM> are also more optimized (step <NUM> of <FIG>). New IP traffic flows using L6::<NUM> will have optimized network path, normal routing (e.g. destination-based routing) without SRv6 steering rules (step <NUM> of <FIG>).

Referring now to <FIG>, a call flow 800a is provided to describe the termination of IP traffic flows associated with MN-<NUM><NUM>. At some point in time, IP traffic flow between MN-<NUM><NUM> and CN-<NUM><NUM> ceases, and this inactivity is detected (step <NUM> of <FIG>). In response, AG-<NUM><NUM> "cleans up" or clears its state information for P2::<NUM>/<NUM> which is removed (step <NUM>(a) of <FIG>). As an alternative to step <NUM>(a), MC <NUM> / TC <NUM> may trigger the initiation of the removal of the state information (step <NUM>(b) of <FIG>). Similarly, AG-<NUM><NUM> "cleans up" or clears state information for CN-<NUM><NUM> which is removed (step <NUM>(a) of <FIG>). As an alternative to step <NUM>(a), MC <NUM> / TC <NUM> may trigger the initiation of the removal of the state information for CN_1 <NUM> (step <NUM>(b) of <FIG>).

Continuing the description in <FIG> with the continued call flow 800b, at some point in time, IP traffic flow between MN-<NUM><NUM> and CN-<NUM><NUM> ceases, and this inactivity is detected (step <NUM> of <FIG>). In response, the same or similar steps as steps <NUM>(a)/<NUM>(b) or <NUM>(a)/<NUM>(b) of <FIG> may be performed (step <NUM> of <FIG>). Now, no active IP traffic flows exist for MN-<NUM><NUM> using P2::<NUM>/<NUM> (step <NUM> of <FIG>). In response to such inactivity, a prefix deprecation (and reallocation) procedure may be performed (step <NUM>(a) of <FIG>). Here, MC <NUM> / TC <NUM> requests P2 deprecation for withdrawing prefix P2::<NUM>/<NUM>, and also requests a new HNP allocation, P6::<NUM>/<NUM>. MN-<NUM> will be allocated with new HNP and LNP from AG-<NUM><NUM> (AG-<NUM><NUM> is no longer relevant). As an alternative, MC <NUM> / TC <NUM> may choose to allow MN-<NUM><NUM> to retain P1::<NUM>/<NUM>, where SRv6 state is pushed as new IP traffic flows using P2::<NUM>/<NUM> surface.

Reference is now made to <FIG>, which shows a block diagram of pertinent components of a server, component, or network device or network equipment <NUM> according to some implementations of the present disclosure (e.g. for one or more controllers of a control plane or CP entity, such as a mobility controller and/or transport controller). Network equipment <NUM> has components which may include one or more processors <NUM> which are coupled to memory <NUM> and to communication interface <NUM>. Interface <NUM> is configured to connect to one or more networks for communications. The one or more processors <NUM> of the network device are configured to operate according to program instructions <NUM> stored in memory <NUM>, in order to perform basic operations as well as to perform additional techniques of the present disclosure as described above in relation to the Figures.

Reference is now made to <FIG>, which shows an example block diagram of a router device <NUM> configured with the functions described herein. Router device <NUM> in <FIG> may alternatively be referred to as a router, or a switching device. It should be appreciated that router device <NUM> may have a similar or the same basic components and functionality as any of the routers (e.g. gateways or access gateways) described herein.

Router device <NUM> comprises, among other components, a plurality of port units <NUM>, a router application specific integrated circuit (ASIC) <NUM>, a processor <NUM> and a memory <NUM>. Ports <NUM> receive communications (e.g., frames) from network devices and are configured to send communications to network devices. For example, ports <NUM> send messages destined for physical devices and receive response messages from physical devices. Ports <NUM> are coupled to router ASIC <NUM>. Router ASIC <NUM> receives instructions from processor <NUM> and forwards frames and/or packets to an appropriate one of port units <NUM> for transmission to a destination network device. Router ASIC <NUM> is coupled to processor <NUM>. Processor <NUM> is, for example, a microprocessor or microcontroller that is configured to execute program logic instructions (i.e., software) for carrying out various operations and tasks of a switch device, as described above. For example, processor <NUM> is configured to execute software <NUM> according to the techniques described above. The functions of processor <NUM> may be implemented by logic encoded in one or more tangible computer readable storage media or devices (e.g., storage devices compact discs, digital video discs, flash memory drives, etc. and embedded logic such as an application specific integrated circuit, digital signal processor instructions, software that is executed by a processor, etc.).

Memory <NUM> may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible (non-transitory) memory storage devices. Memory <NUM> stores software instructions for basic operation as well as for executing the techniques of the present disclosure. Memory <NUM> may also store a route forwarding table <NUM>. Thus, in general, memory <NUM> may comprise one or more computer readable storage media (e.g., a memory storage device) encoded with software comprising computer executable instructions and when the software is executed (e.g. by processor <NUM>) it is operable to perform the operations described for software <NUM>.

Software <NUM> may take any of a variety of forms, so as to be encoded in one or more tangible computer readable memory media or storage device for execution, such as fixed logic or programmable logic (e.g., software/computer instructions executed by a processor), and processor <NUM> may be an ASIC that comprises fixed digital logic, or a combination thereof. For example, processor <NUM> may be embodied by digital logic gates in a fixed or programmable digital logic integrated circuit, which digital logic gates are configured to execute functions of software <NUM>. In general, the software <NUM> may be embodied in one or more computer readable storage media encoded with software comprising computer executable instructions and when the software is executed operable to perform the operations described hereinafter.

Software <NUM> may include a plurality of different software functions or modules, including one or more destination-based routing protocols <NUM>, an SRv6 routing protocol <NUM>, and one or more (e.g. control and/or programming, etc.) interfaces with the mobility controller (MC) / transport controller (TC) (see e.g. <FIG>). The one or more destination-based routing protocols <NUM> may include one or more of Internet Group Management Protocol (IGMP), Intermediate System to Intermediate System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), or the like. If router device <NUM> provides for providing user plane (UP) functionality for user plane traffic (e.g. an access gateway or GW-U), software <NUM> may include one or more UP functions <NUM>. Accordingly, software <NUM> is configured to support the techniques of the present disclosure described in relation to the figures above.

The techniques described above in connection with various implementations may be performed by one or more computer readable storage media that is encoded with software comprising computer executable instructions to perform the methods and steps described herein. For example, the operations performed by the routers and other physical devices may be performed by one or more computer or machine readable storage media (non-transitory) or device executed by a processor and comprising software, hardware or a combination of software and hardware to perform the techniques described herein.

Reference is now made to <FIG>, which shows an example schematic block diagram of a mobile node (MN) <NUM> according to some implementations. MN <NUM> may be, for example, a user equipment (UE), a cellular telephone, a smart phone, a tablet, a laptop computer, etc. As shown in <FIG>, MN <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>. It will be appreciated that the MN <NUM> may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

Processor <NUM> may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. Processor <NUM> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables MN <NUM> to operate in a wireless environment. Processor <NUM> may be coupled to transceiver <NUM>, which may be coupled to the transmit/receive element <NUM>.

Transmit/receive element <NUM> may be configured to transmit signals to, or receive signals from, a base station over an air interface <NUM>. For example, in one embodiment, transmit/receive element <NUM> may be an antenna configured to transmit and/or receive RF signals. In another embodiment, transmit/receive element <NUM> may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, transmit/receive element <NUM> may be configured to transmit and receive both RF and light signals. It will be appreciated that transmit/receive element <NUM> may be configured to transmit and/or receive any combination of wireless signals.

In addition, although transmit/receive element <NUM> is depicted in <FIG> as a single element, MN <NUM> may include any number of transmit/receive elements <NUM>. More specifically, MN <NUM> may employ MIMO technology. Thus, in one embodiment, MN <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals over air interface <NUM>.

Transceiver <NUM> may be configured to modulate the signals that are to be transmitted by transmit/receive element <NUM> and to demodulate the signals that are received by transmit/receive element <NUM>. As noted above, MN <NUM> may have multi-mode capabilities. Thus, transceiver <NUM> may include multiple transceivers for enabling MN <NUM> to communicate via multiple RATs, such as UTRA and IEEE <NUM>, for example.

Processor <NUM> of MN <NUM> may be coupled to, and may receive user input data from, speaker/microphone <NUM>, keypad <NUM>, and/or display/touchpad <NUM> (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). Processor <NUM> may also output user data to speaker/microphone <NUM>, keypad <NUM>, and/or display/touchpad <NUM>. In addition, processor <NUM> may access information from, and store data in, any type of suitable memory, such as non-removable memory <NUM> and/or removable memory <NUM>. Non-removable memory <NUM> may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. In other embodiments, processor <NUM> may access information from, and store data in, memory that is not physically located on MN <NUM>, such as on a server or a home computer (not shown).

Processor <NUM> may receive power from power source <NUM>, and may be configured to distribute and/or control the power to the other components in the MN <NUM>. Power source <NUM> may be any suitable device for powering MN <NUM>. For example, power source <NUM> may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

Processor <NUM> may also be coupled to GPS chipset <NUM>, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of MN <NUM>. In addition to, or in lieu of, the information from the GPS chipset <NUM>, MN <NUM> may receive location information over air interface <NUM> from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that MN <NUM> may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

Processor <NUM> may further be coupled to other peripherals <NUM>, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, peripherals <NUM> may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

Methods and apparatus for use in adaptively rerouting user plane traffic for mobility using a segment routing (SR) for IPv6 (SRv6) protocol have been described. Advantageously, a mobility-aware, floating anchor (MFA) may be provided in a mobile network. In some implementations, a technique of the present disclosure is performed at one or more controllers of a control plane (CP) entity for a mobile network. A message indicating an attachment of a mobile node (MN) to the mobile network is received, where a first user plane (UP) anchor node (e.g. a GW-U) is selected for the MN. A first set of home network prefixes (HNPs) and a first set of local network prefixes (LNPs) are allocated to the MN. An IP traffic flow using a first HNP prefix of the MN is established between the MN and a correspondent node (CN) along a first network path. The first network path may be selected with use of a destination-based routing protocol, and defined by a first plurality of nodes which include the first UP anchor node of the MN and an anchor node of the CN.

In response to a handover of the MN in the mobile network, a message indicating a subsequent attachment of the MN to the mobile network is received, where a second UP anchor node is selected for the MN. The second UP anchor node is instructed to host the first HNP prefix previously allocated by the first UP anchor node. Further, at least one of the first UP anchor node, the second UP anchor node, and the anchor node of the CN is provisioned with one or more rules, for instruction to perform SRv6 routing or rerouting of an IP traffic flow to and/or from the first HNP prefix of the relocated MN, to optimize such IP traffic flow. At least some of such provisioning is performed in response to anchor node reports of IP traffic flow to and/or from the first HNP prefix.

As one example, the anchor node of the CN may be provisioned with one or more rules, for instructing the anchor node of the CN to perform SRv6 routing of a downlink IP traffic flow from the CN to the (relocated) MN along a second network path defined by a second plurality of nodes. The second plurality of nodes include the second UP anchor node and exclude the first UP anchor node, for optimizing the IP traffic flow.

At the new, second UP anchor node, a second set of HNPs and a second set of LNPs may allocated to the MN, where new network paths for newly-established IP traffic flows (for a second HNP prefix and/or for second LNP prefix) may again be selected based on the destination-based routing protocol.

In response to receiving the message indicating the subsequent attachment of the MN to the mobile network, the first UP anchor node is provisioned or instructed to report IP traffic flow information associated with subsequent receipt of IP traffic flow associated with the MN. Subsequently, one or more messages are received from the first UP anchor node, where the one or more messages comprise a report of downlink IP traffic flow information associated with a receipt of downlink IP traffic flow destined to the MN, where the downlink IP traffic flow information indicates a source address corresponding to the CN. The anchor node of the CN is identified, from a mobile node location table, based on the downlink IP traffic flow information indicating the source address of the CN and network topology information which characterizes a network topology of the mobile network. The provisioning of the anchor node of the CN with the one or more rules is performed in response to receiving the one or more messages comprising the report of the downlink IP traffic flow information.

In further implementations, after the handover, the first UP anchor node may be provisioned with one or more rules, for instructing the first UP anchor node to perform SRv6 routing of downlink IP traffic flow from the CN to the MN along a third network path defined by a third plurality of nodes. The third plurality of nodes includes the second UP anchor node of the MN. The third plurality of nodes of the third network path may be selected based on the network topology information.

In yet further implementations, in response to receiving the message indicating the subsequent attachment of the MN to the mobile network, the second UP anchor node may be instructed to report uplink IP traffic flow information associated with a subsequent receipt of uplink IP traffic flow from the MN. Subsequently, one or more messages may be received from the second UP anchor node, where the one or more messages may comprise a report of uplink IP traffic flow information associated with a receipt of uplink IP traffic flow from the MN. The after receiving the message indicating the subsequent attachment of the MN to the second UP anchor node, the second UP anchor node may be instructed to perform destination-based routing of uplink IP traffic flow from the MN.

In some implementations, a set of home network prefixes (HNPs) are assigned to the MN from a HNP prefix block of the first UP anchor node and, in response to receiving the message indicating the subsequent attachment of the MN to the mobile network, the second UP anchor node is instructed to host the set of HNPs allocated to the MN. In addition, a first set of local network prefixes (LNPs) are allocated to the MN from a first LNP prefix block of the first UP anchor node and, in response to receiving the message indicating the subsequent attachment of the MN to the mobile network, a second set of LNPs may be allocated to the MN from a second LNP prefix block of the second UP anchor node, and the first set of LNPs are deallocated. At the new, second UP anchor node, the second set of HNPs and the second set of LNPs allocated to the MN may be used, where new network paths for newly-established IP traffic flows (for a second HNP prefix and/or for second LNP prefix) may again be selected based on the destination-based routing protocol.

Note that the components and techniques shown and described in relation to the separate figures may indeed be provided as separate components and techniques; alternatively, one or more (or all of) the components and techniques shown and described in relation to the separate figures are provided together and/or used in combination for operation in a cooperative manner.

Although the detailed embodiments above described the inventive techniques within the context of a <NUM>, LTE-based mobile network, where the one or more controllers of the CP entity were an MME and/or a GW-C and the first and the second UP anchor nodes were GW-Us which serve as service points for accounting and charging (and other services, such as lawful intercept), the inventive techniques may be applied in the same or similar manner to a <NUM> mobile network, where one or more controllers of the CP entity involve an access and mobility management function (AMF) and/or a session management function (SMF), and the first and the second UP anchor nodes may involve (instances of) user plane functions (UPFs) which serve as the service points for accounting and charging (and perhaps other services, such as lawful intercept).

It will also be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. For example, a first anchor node could be termed a second anchor node, and similarly, a second anchor node could be termed a first anchor node, without changing the meaning of the description, so long as all occurrences of the first anchor node are renamed consistently and all occurrences of the second anchor node are renamed consistently. The first anchor node and the second anchor node are both anchor nodes, but they are not the same anchor node.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the claims. As used in the description of the embodiments and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

Claim 1:
A method for controlling routing of user plane traffic using a segment routing, SR, for IPv6, SRv6, protocol, comprising:
at one or more controllers of a control plane, CP, entity,
receiving (<NUM>) a message indicating an attachment of a mobile node, MN, to a mobile network, wherein a first user plane, UP, anchor node and a first set of home network prefixes, HNPs, are selected for the MN, and wherein an IP traffic flow to and/or from a first HNP prefix is established between the MN and a correspondent node, CN, along a first network path defined by a first plurality of nodes, the first plurality of nodes including the first UP anchor node of the MN and an anchor node of the CN;
receiving (<NUM>) a message indicating a subsequent attachment of the MN to the mobile network in response to a handover of the MN, wherein a second UP anchor node is selected for the MN; and
after receiving the message indicating the subsequent attachment of the MN to the mobile network:
instructing (<NUM>) the second UP anchor node to host the first set of HNP prefixes previously allocated to the MN;
instructing the first UP anchor node to report IP traffic flow information associated with subsequent receipt of IP traffic flow associated with the MN;
receiving from the first UP anchor node one or more messages comprising a report of downlink IP traffic flow information associated with a receipt of downlink IP traffic from the CN destined to the first HNP prefix of the MN, and
provisioning (352a) the anchor node of the CN with one or more rules for steering, to the second UP anchor node of the MN using SRv6 routing, IP traffic flows from the CN destined to the first HNP prefix along a second network path defined by a second plurality of nodes, wherein the anchor node of the CN and the second UP anchor node of the MN are identified for the provisioning of the anchor node based on the report of the downlink IP traffic flow information.