Patent Description:
A user equipment (UE) may communicate in a <NUM> mobile network via a base station (e.g. gNB). One or more data packet flows of a PDU session of the UE may be routed (e.g. anchored) through a user plane function (UPF), where the session of the UE is managed and controlled by a session management function (SMF).

One or more conditions have been identified that may warrant a migration of the UE flows/session to a different UPF. For example, the communications of the UE may degrade in performance; the UE may be relocated to a different base station (e.g. a much longer route to reach the UPF); and/or the UE may add a new flow (e.g. a new flow that requires special UPF processing).

Accordingly, what are needed are mechanisms for triggering a session or flow migration for session or flows of a UE in a mobile network.

3GPP document TR <NUM> describes, according to its Scope section, how to collect data and how to feedback data analytics to the network functions.

<CIT> describes, according to its abstract, a network data analytics (NWDA) function and method of policy optimization in a communication network are provided. The NWDA performs data analytics on the communication network traffic, and includes communication interfaces to connect to other network elements in the communication network. The method comprises the NWDA function configured to receive a request for a policy input, send instructions to network elements to obtain network performance measurement data, receive the measurement data from the network elements, and transmit a policy input based on the received measurement data.

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. Those of ordinary skill in the art will appreciate that other effective aspects and/or variants do not include all of the specific details described herein. 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.

Segment routing (SR) for IPv6 (SRv6) user-plane-based triggering methods and apparatus for session or flow migration in mobile networks are provided in accordance to appended independent claims. Further aspects are defined in the dependent claims.

In one illustrative example of the present disclosure, a user plane (UP) entity for use in a mobile network may receive a data packet from a user equipment (UE) operative to communicate in one or more sessions via a serving base station (BS) of the mobile network. The data packet may be a segment routing (SR) for IPv6 (SRv6) data packet. The UP entity may detect, in a header (e.g. SRH) of the data packet, an identifier indicating a new serving BS or session of the UE. The identifier may be UE- or BS-added data (e.g. iOAM data) that is inserted in the header by the UE.

In response, the UP entity may cause a message to be sent to an analytics function (e.g. a NWDAF) to perform analytics for session or flow migration for the UE. The analytics function may receive the message, perform the analytics, and send a message to a control plane (CP) entity for session management in response. The message may indicate an instruction to perform session or flow migration and/or contain resulting data of the analytics (e.g. information associated with a more suitable or optimal UP entity). In response to receiving the message, the CP entity for session management may perform session or flow migration of one or more sessions or flows of the UE from the UP entity to a different UP entity.

In some preferred implementations, it is the UE that inserts the identifier in the header of the data packet. In other implementations, it is the BS that inserts the identifier in the header of the data packet.

In another illustrative example of the present disclosure, a UP entity may receive a data packet from a UE operative to communicate in one or more sessions via a BS of the mobile network. The data packet may be an SRv6 data packet. The UP entity may identify a timestamp in a header (e.g. SRH) of the data packet. The timestamp may be UE- or BS-added data (e.g. iOAM data) that is inserted in the header by the UE or the BS. The UP entity may cause a message which includes timing information to be sent to an analytics function to perform analytics for session or flow migration for the UE based on the timing information. The timing information may be indicative of at least a timing of communication of the data packet between the BS and the UP entity, and may include or be derived from the timestamp. For example, the timing information may include the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity, or may include a time differential between the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity.

The analytics function may receive, from the UP entity, the message which includes the timing information and perform the analytics for session or flow migration for the UE in response. The analytics may include identifying whether the timing information satisfies a requirement or preference associated with a service level agreement (SLA) of the UE. The analytics function may send to a control plane (CP) entity for session management one or more messages which include an instruction to perform session or flow migration and/or contain resulting data of the analytics (e.g. information associated with a more suitable or optimal UP entity), based on identifying that the timing information fails to satisfy the requirement or preference associated with the SLA of the UE.

In addition, the analytics function may perform the analytics further by receiving, from a different UP entity, a message which includes other timing information and identify whether the other timing information from the other UP entity satisfies the requirement or preference associated with the SLA of the UE. The other timing information may be indicative of at least another timing of communication of the data packet between the BS and the different UP entity. The analytics function may send to the CP entity for session management the one or more messages which include an identification of the different UP entity based on identifying that the other timing information from the different UP entity satisfies the requirement or preference associated with the SLA of the UE.

More detailed and alternative techniques and implementations are provided herein as described below.

When a PDU session for a user equipment (UE) is established in a <NUM> mobile network, it is anchored on a user plane function (UPF) node and routed to a data network (DN). Selection of the UPF node is typically performed by a session management function (SMF) node, taking into consideration the most optimal traffic path. Due to UE mobility or some other occurrence, the route to the DN through the initially-selected UPF node may become less than optimal. The suboptimal condition could exist for the entire PDU session or for just some of the flows of the session.

There is a need to provide efficient triggering mechanisms for session or flow migration for UEs in order to (regularly) reconfigure sub-optimal session paths in order to achieve communication efficiency.

To better illustrate, <FIG> is an illustrative representation of a network architecture 100A of a <NUM> mobile network configured to facilitate communications for a user equipment (UE) <NUM>. UE <NUM> may be an IoT or similar device. In general, network architecture 100a includes common control network functions (CCNF) <NUM> and a plurality of slice-specific core network functions <NUM>. UE <NUM> may obtain access to the mobile network via an access network (AN) <NUM>, which may be a radio access network (RAN). In the present disclosure, the UEs operating in the <NUM> mobile network may be any suitable type of devices, such as cellular telephones, smart phones, tablet devices, IoT devices, and machine-to-machine (M2M) communication devices, to name but a few. Techniques of the present disclosure may involve UEs that are IoT devices in an MIoT deployment.

CCNF <NUM> includes a plurality of network functions (NFs) which commonly support all sessions for UE <NUM>. UE <NUM> may be connected to and served by a single CCNF <NUM> at a time, although multiple sessions of UE <NUM> may be served by different slice-specific core network functions <NUM>. CCNF <NUM> may include, for example, an access and mobility management function (AMF) and a network slice selection function (NSSF). UE-level mobility management, authentication, and network slice instance selection are examples of common functionalities provided by CCNF <NUM>.

Slice-specific core network functions of network slices <NUM> are separated into control plane (CP) NFs <NUM> and user plane (UP) NFs <NUM>. In general, the user plane carries user traffic while the control plane carries network signaling. CP NFs <NUM> are shown in <FIG> as CP NF <NUM> through CP NF n, and UP NFs <NUM> are shown in <FIG> as UP NF <NUM> through UP NF n. CP NFs <NUM> may include, for example, a session management function (SMF), whereas UP NFs <NUM> may include, for example, a user plane function (UPF).

<FIG> is an illustrative representation of a more detailed network architecture 100B of the <NUM> mobile network of <FIG>. As provided in 3GPP standards for <NUM> (e.g. 3GPP <NUM> and <NUM>), network architecture 100b for the <NUM> mobile network which is operated by a mobile network operator (MNO) may include an authentication server function (AUSF) <NUM>, a unified data management (UDM) <NUM> (having a unified data repository or UDR), an AMF <NUM>, a policy control function (PCF) <NUM>, an SMF <NUM>, and a UPF <NUM>. A plurality of interfaces and/or reference points N1-N8, N10-N13, N15, and N22 shown in <FIG> (as well as others) may define the communications and/or protocols between each of the entities, as described in the relevant (evolving) standards documents. One or more application functions, such as an application function (AF) <NUM>, of a data network (DN) <NUM> may connect to the <NUM> mobile network via PCF <NUM> or UPF <NUM>.

UPF <NUM> is part of the user plane and all other NFs (i.e. AMF <NUM>, SMF <NUM>, PCF <NUM>, AUSF <NUM>, and UDM <NUM>) are part of the control plane. Separation of user and control planes guarantees that each plane resource can be scaled independently; it also allows UPFs to be deployed separately from CP functions in a distributed fashion. The NFs in the CP are modularized functions; for example, AMF and SMF are independent functions allowing for independent evolution and scaling. As specifically illustrated in <FIG>, NFs such as SMF <NUM> and UPF <NUM> of <FIG> may be provided as specific instances in a first network slice (e.g. network slice <NUM>) of a plurality of network slice instances made available in the mobile network.

Also, as shown in <FIG>, a network exposure function (NEF) <NUM> may be provided in the mobile network. In general, NEF <NUM> may be configured to receive information from other NFs (e.g. based on exposed capabilities of other NFs) and store the received information as structured data. The storage operations may be performed with use of a standardized interface to a data storage network function. The stored information may be re-exposed by NEF <NUM> to other NFs and used for other purposes (e.g. analytics). One example use of NEF <NUM> is to assist in the establishment of an AS-initiated communication with a UE / IoT device, from an application server (AS) <NUM> through an API (e.g. where no other existing data connection exists).

As shown in a network node arrangement <NUM> of <FIG>, an analytics function <NUM> may also be provided in the <NUM> mobile network. Analytics function <NUM> may be a network data analytics function (NWDAF), as described in the relevant (evolving) standards documents, such TS <NUM> and others. Analytics function <NUM> may be used for data collection and data analytics in a centralized manner. Analytics function <NUM> may receive activity data and local analytics from NFs <NUM> or an AF <NUM>, and/or access data from one or more data repositories <NUM>. Resulting analytics data may be generated and sent or otherwise provided by analytics function <NUM> to the NFs and/or AF <NUM>. Relevant interfaces associated with the NWDAF include the Na interface with the UPF, the Nb interface with the PCF, and the Nc interface with the SMF. Messaging and data may be communicated between analytics function <NUM> and OAM or OAM-processing nodes <NUM>.

In the present disclosure, network elements in the mobile network may make use of segment routing (SR) for communications, including session communications, in relation to the defined interfaces/reference points. The segment routing (SR) may be SR for IPv6 (SRv6). To illustrate a few SRv6 examples, <FIG> are block diagrams of network nodes which are configured to route packets using SRv6.

With reference first to <FIG>, a network 200a which includes a plurality of nodes <NUM> (e.g. routers, servers, base stations (BSs), gateways, CP or UP entities, 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 network 200a. 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 network 200a 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 network 200a may operate to execute the encoded instructions without any further per-flow state.

<FIG> is an illustrative representation of a network 200b which is similar to network 200a of <FIG>. Here, 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 290b. In this case, the source node (node <NUM> or A) which is SRv6-capable may originate the SR-IPv6 packet 290b. Here, the SR header of SR-IPv6 packet 290b 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 290b is designated as node A and a destination address (DA) of SR-IPv6 packet 290b is designated as node B (i.e. the first node in the SL). When SR-IPv6 packet 290b 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 292b. When SR-IPv6 packet 292b 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 294b. When SR-IPv6 packet 294b 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 296b.

In the example of <FIG>, an SR header of an IPv6 packet 290c is inserted at the ingress node (node <NUM> or B) to produce an SR-IPv6 packet 292c. Here, the SR header of SR-IPv6 packet 292c 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 290c without any SR header. When SR-IPv6 packet 292c 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 294c. When SR-IPv6 packet 294c 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 296c. 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 290d without any SR header. The ingress node (node <NUM> or B) operates to encapsulate IPv6 packet 290d with a new, outer IPv6 header followed by an SR header, to produce an SR-IPv6 packet 292d. 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 292d 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 294d. When SR-IPv6 packet 294d is further communicated to the node G (via node F), the SR-IPv6 packet 294d is decapsulated by node G, which is represented by SR-IPv6 packet 296d. Here, similar to the source node, the destination node may or may not be SRv6-configured.

Note that 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>".

<FIG> is an illustrative representation of a node arrangement <NUM> for describing (one particular need for) session migration for a UE based on a UE mobility event. Initially, UE <NUM> is being served by a gNB1 104a and has one or more sessions for communicating data packets that are routed via a UPF1 122a. Thus, an initial path <NUM> for the session includes a path between gNB1 104a and UPF1 122a. When the session of the UE <NUM> is handover from (source) gNB1 104a to a (target) gNB2 104b, a non- or sub-optimal path <NUM> for the session may result, which includes a (e.g. more lengthy) path between gNB2 104b and UPF1 122a. After session migration to a UPF2 122b, a (more) optimal path <NUM> for the session may be established which includes a path between gNB2 104b and UPF2 122b.

According to some implementations, session or flow migration for a UE may be performed according to implementation. In <NUM>, an SMF may insert a branching point (BP) for migrating an entire PDU session from one UPF to another UPF, or configure rules on an uplink classifier (ULCL) / BP to divert some of the flows of the PDU session from one UPF to another UPF.

To better illustrate, <FIG> is an illustrative representation of a node arrangement 400a of a mobile network for describing use of a UPF uplink classifier <NUM>, whereas <FIG> is an illustration representation of a node arrangement 400b of the mobile network for describing use of a UPF branching point <NUM>. With use of uplink classification rules at UP uplink classifier <NUM> in the configuration of <FIG>, (first) UPF 122a may be provided as a first anchor for a first PDU session of UE <NUM>, and (second) UPF 122b may be provided as a second anchor for a second PDU session of UE <NUM>. Here, local access to the same DN <NUM> may be provided. On the other hand, with use of UPF branching point <NUM> in the configuration of <FIG>, the (first) UPF 122a may be provided as a first anchor for a first PDU session of UE <NUM>, and the (second) UPF 122b may be provided as a second anchor for a second PDU session of UE <NUM>.

In the context of the <NUM> mobile network of <FIG>, <FIG>, and <FIG> (as well as <FIG>, <FIG>, and <FIG>), there is a need to provide efficient triggering mechanisms for session or flow migration for UEs in order to (regularly) reconfigure sub-optimal session paths in order to achieve communication efficiency.

According to some implementations of the present disclosure, a triggering mechanism for session or flow migration for a UE may be achieved with use of UE or BS "stamping" of metadata the header of a data packet. In some implementations, the present techniques may be achieved through use of stamping of iOAM data (e.g. iOAM TLVs) in SRHs of SRv6 data packets, for example, in the context of Internet-Draft document "Data Fields for In-situ OAM," "draft-brockners-inband-oam-data-<NUM>," Internet-Draft document "Data Fields for In-situ OAM, draft-ietf-ippm-ioam-data-<NUM>," and/or any related or succeeding documents or standards.

To better illustrate, <FIG> are illustrative representations of general message formats 500a, 500b, and 500c of data packets for use in SRv6 user-plane-based triggering for session or flow migration according to some implementations of the present disclosure.

In <FIG>, the message format 500a of the data packet includes a header 502a (e.g. an SRH) and a payload 504a which may include payload data. Header 502a may include UE- or BS-added data (i.e. data that are added to or inserted in the header 502a by the UE or BS) which may be referred to as iOAM data. More specifically in <FIG>, header 502a may include an identifier 520a which identifies a serving BS (e.g. eNB or gNB) of the UE. Identifier 520a may be a node ID or address of the serving BS. In some implementations, identifier 520a may be an identifier of a new target serving BS in a handover of one or more sessions of the UE. UP detection of identifier 520a that indicates a new target serving BS in a handover may be used as a trigger to perform analytics for session or flow migration for the UE.

In <FIG>, the message format 500b of the data packet includes a header 502b (e.g. an SRH) and a payload 504b which may include payload data. Header 502b may include UE- or BS-added data (i.e. data that are added to or inserted in the header 502b by the UE or BS) which may be referred to as iOAM data. More specifically in <FIG>, header 502b may include an identifier 520b of a session (e.g. a session ID) of the UE. In some implementations, UP detection of identifier 520b that indicates a new or changed session may be used as a trigger to perform analytics for session or flow migration for the UE.

In <FIG>, the message format 500c of the data packet includes a header 502c (e.g. an SRH) and a payload 504c which may include payload data. Header 502c may include UE- or BS-added data (i.e. data added to or inserted in the header 502c by the UE or BS) which may be referred to as iOAM data. More specifically in <FIG>, header 502b may include a timestamp (TS) 520c of a time of processing (sending and/or receiving) of the data packet by the UE or BS. In some implementations, the UP entity may identify timestamp 520c and include it in or use it to derive timing information. The timing information may be indicative of at least a timing of communication of the data packet between the BS and the UP entity. The timing information may be used to perform analytics for session or flow migration for the UE. For example, the timing information may include the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity, or may include a time differential between the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity.

<FIG> and <FIG> are flowcharts for describing the basic steps in the SRv6 user-plane-based triggering methods for session or flow migration in mobile networks according to some implementations of the present disclosure. With respect to the methods in these flowcharts, as well as the methods in the remaining flowcharts and call flow diagrams, the particular network function or node configured to perform the techniques may include one or more processors and one or more memories coupled to the one or more processors. The method may be embodied as a computer program product (e.g. memory) including a non-transitory computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the node for performing the steps of the method.

More particularly, <FIG> is a flowchart <NUM> for describing a method which may be performed at a UP entity (e.g. a UPF or GW-U), <FIG> is a flowchart <NUM> for describing a method which may be performed at an analytics function (e.g. a NWDAF), and <FIG> is a flowchart <NUM> for describing a method which may be performed at a CP for session management (e.g. an SMF or GW-C).

Beginning at a start block <NUM> of <FIG>, a UP entity for use in a mobile network may receive a data packet from a UE operative to communicate in one or more sessions via a serving BS (e.g. eNB or gNB) of the mobile network (step <NUM> of <FIG>). The data packet may be an SRv6 data packet. The UP entity may detect, in a header (e.g. the SRH or TLV) of the data packet, an identifier indicating a new serving BS or session of the UE (step <NUM> of <FIG>). The identifier may be UE- or BS-added data (e.g. iOAM data) that is inserted in the header by the UE. In response, the UP entity may cause a message to be sent to an analytics function (e.g. a NWDAF) to perform analytics for session or flow migration for the UE (step <NUM> of <FIG>).

Continuing, beginning at a start block <NUM> of <FIG>, the analytics function may receive the message from the UP entity (step <NUM> of <FIG>), perform the analytics (step <NUM> of <FIG>) and, in response, send a message to the CP entity for session management (step <NUM> of <FIG>). The message may indicate an instruction to perform session or flow migration and/or contain resulting data from the analytics (e.g. information associated with a more suitable or optimal UP entity).

Continuing, beginning at a start block <NUM> of <FIG>, the CP entity for session management may receive the message from the analytics function (step <NUM> of <FIG>). In response to receiving the message, the CP entity for session management may perform session or flow migration of one or more sessions or flows of the UE from the UP entity to a different UP entity (step <NUM> of <FIG>).

<FIG> is a flowchart <NUM> for describing a more descriptive, end-to-end SRv6 user-plane-based triggering method for session or flow migration in mobile networks according to some implementations of the present disclosure. The method of <FIG> pertains to an SRv6 user-plane-based triggering method for session or flow migration that is triggered based on a UE mobility event (e.g. handover or change in gNB). The method of <FIG> as described is applied specifically to a <NUM> mobile network and involves multiple entities of the <NUM> mobile network, including a gNB, a UPF, and a SMF.

Beginning at a start block <NUM> of <FIG>, a UE is being served by gNB1 and has one or more sessions for communicating data packets that are routed (e.g. anchored) via UPF1 (step <NUM> of <FIG>). Thus, the route for the data packets is gNB1-UPF1. When the session of the UE is handover from gNB1 to gNB2 (as identified at step <NUM> of <FIG>), this may be detected at the UE and/or gNB. The UE or gNB2 may add or insert an ID of new serving (target) gNB2 in a header of the (next) data packet (e.g. an iOAM TLV) (step <NUM> of <FIG>). The ID may be an ID or address of the gNB. The data packet may be an SRv6 data packet where the header is an SRH.

UPF1 may receive this data packet and detect or otherwise read the ID of new serving (target) gNB2 from the header (step <NUM> of <FIG>). UPF1 may communicate to the analytics function (e.g. NWDAF) a message which includes the ID of the new serving (target) gNB2 (step <NUM> of <FIG>). The change in gNB (i.e. the change in mobility) may serve as a trigger to signal the analytics function to perform analytics with respect to the new gNB2-UPF1 route.

The analytics function may receive, from UPF1, the message which includes the ID of the new serving (target) gNB2 (step <NUM> of <FIG>). The analytics function may perform analytics to determine or identify any new (more optimal) path associated with a new gNB-UPF pairing (i.e. whether session or flow of the UE should be migrated to a new UPF, such as UPF2) (step <NUM> of <FIG>). The analytics function may communicate to the SMF one or more messages which indicate an instruction to perform session or flow migration for the UE and/or contain resulting data from the analytics (e.g. information associated with a more suitable or optimal UPF2) (step <NUM> of <FIG>). The SMF may receive the one or more messages (step <NUM> of <FIG>) and, in response to the message, perform session or flow migration for the UE to a different UPF (e.g. UPF2) (step <NUM> of <FIG>).

In some alternative implementations of <FIG>, the UPF1 may communicate the one or more messages to an application function (AF) instead of the analytics function, so that the AF may (determine whether to) request and receive the resulting data from the analytics performed by the analytics function. Here, the AF may subsequently (determine whether to) send to the SMF the one or more message to indicate an instruction and/or contain the resulting data from the analytics. In other alterative implementations of <FIG>, the UPF1 may communicate the one or more messages to the SMF instead of the analytics function, so that the SMF may (determine whether to) request and receive from the analytics function the resulting data from the analytics.

<FIG> is a flowchart <NUM> for describing another more descriptive, end-to-end SRv6 user-plane-based triggering method for session or flow migration in mobile networks according to some implementations of the present disclosure. The method of <FIG> pertains to an SRv6 user-plane-based triggering method for session or flow migration that is triggered based on a new or changed session of the UE for communicating data packets. The method of <FIG> as described is applied specifically to a <NUM> mobile network and involves multiple entities of the <NUM> mobile network, including a gNB, a UPF, and a SMF.

Beginning at a start block <NUM> of <FIG>, a UE is being served by a gNB and has one or more sessions for communicating data packets that are routed (e.g. anchored) via UPF1 (step <NUM> of <FIG>). When there is a new or changed session for the UE (as identified at step <NUM> of <FIG>), this may be detected at the UE and/or gNB. Here, the UE or gNB may add or insert a session ID of the new session in a header of the (next) data packet (e.g. an iOAM TLV) (step <NUM> of <FIG>). The data packet may be an SRv6 data packet where the header is an SRH. Alternatively, in step <NUM>, when a session has changed (e.g. a session is ended or terminated), the UE or gNB may add or insert a session ID of the ended session (e.g. or identity only the remaining sessions) in the header of the (next) data packet.

UPF1 may receive this data packet and detect or otherwise read the session ID of the new session from the header (step <NUM> of <FIG>). UPF1 may communicate to the analytics function (e.g. NWDAF) a message which includes the session ID of the new session (step <NUM> of <FIG>). The change in session may serve as a trigger to signal the analytics function to perform analytics with respect to new or changed requirements associated with the session(s).

The analytics function may receive, from UPF1, the message which includes the session ID of the session (step <NUM> of <FIG>). The analytics function may perform analytics to determine or identify any new (more optimal) path associated with new or changed session (i.e. whether any flows or sessions of the UE should be migrated to a new UPF, such as UPF2) (step <NUM> of <FIG>). The analytics function may communicate to the SMF one or more messages which indicate an instruction to perform session or flow migration for the UE and/or contain resulting data from the analytics (e.g. information associated with a more suitable or optimal UPF2) (step <NUM> of <FIG>). The SMF may receive the one or more messages (step <NUM> of <FIG>) and, in response to the message, perform session or flow migration for the UE to a different UPF (e.g. UPF2) (step <NUM> of <FIG>).

In some alternative implementations of <FIG>, the UPF1 may communicate the one or more messages to an AF instead of the analytics function, so that the AF may (determine whether to) request and receive the resulting data from the analytics performed by the analytics function. Here, the AF may subsequently (determine whether to) send to the SMF the one or more messages to indicate an instruction and/or contain the resulting data from the analytics. In other alterative implementations of <FIG>, the UPF1 may communicate the one or more messages to the SMF instead of the analytics function, so that the SMF may (determine whether to) request and receive from the analytics function the resulting data from the analytics.

Some implementations associated with <FIG>, <FIG>, <FIG>, and <FIG> may be provided in the context of that shown and described in relation to <FIG>. Here, session or flow migration may be performed by the CP entity for session management (e.g. SMF or GW-C) by migrating the entire session to a different UP entity, by migrating some or all of the flows by configuring an uplink classifier or branching point, or by inserting a branching point and migrating the entire session to a different UP entity.

Also, some implementations associated with <FIG>, <FIG>, <FIG>, and <FIG> may make specific use of SRv6 and data fields associated with In-situ OAM. Here, in some implementations, the iOAM "Trace Type" may be set with Bit <NUM> (hop_num) and node_id) and the packet forwarded; each eNB / gNB and other nodes may insert its node_id and hop_num until it the packet reaches the UPF. In other implementations, the next header (NH) details (e.g. eNB address) may be obtained and included in the SRv6 TLV. The former implementation may provide satisfactory operation when most or all nodes understand and insert the iOAM details; the latter may provide satisfactory operation when the UE is able and configured to fetch the address of the eNB / gNB.

Also, as described in relation to <FIG>, <FIG>, <FIG>, and <FIG>, an event which is a handover and/or a newly-added session may be used as part of the triggering mechanism in the technique. In some implementations, the one or more events may be or include one or more network-configurable events associated with the UE.

Moving ahead, it has been observed that many communication issues arise as a result of a performance and/or timing issues, for example, delay or jitter. According to some implementations, a triggering mechanism for session or flow migration for a UE may be based on the detection of a performance degradation (e.g. delay, jitter, etc.), and include the use of UE or base station "stamping" of timestamp data in the header of an SRv6 data packet.

To better illustrate, <FIG> and <FIG> are flowcharts for describing the basic steps in the SRv6 user-plane-based triggering methods for session or flow migration in mobile networks according to some implementations of the present disclosure. More particularly, <FIG> is a flowchart <NUM> for describing a method which may be performed at a UP entity (e.g. a UPF or GW-U), <FIG> is a flowchart <NUM> for describing a method which may be performed at an analytics function (e.g. a NWDAF), and <FIG> is a flowchart <NUM> for describing a method which also may be performed at the analytics function.

Beginning at a start block <NUM> of <FIG>, a UP entity for use in a mobile network may receive a data packet from a UE operative to communicate in one or more sessions via a serving BS (e.g. eNB or gNB) of the mobile network (step <NUM> of <FIG>). The data packet may be an SRv6 data packet. The UP entity may identify a timestamp in a header (e.g. SRH) of the data packet (step <NUM> of <FIG>). The timestamp may be UE- or BS-added data (e.g. iOAM data) that is inserted in the header by the UE or the BS. The UP entity may cause a message which includes timing information to be sent to an analytics function to perform analytics for session or flow migration for the UE based on the timing information (step <NUM> of <FIG>).

The timing information may be indicative of at least a timing of communication of the data packet between the BS and the UP entity, and may include or be derived from the timestamp. For example, the timing information may include the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity, or may include a time differential between the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity.

Continuing with the flowchart <NUM> of <FIG>, the analytics function may receive, from the UP entity, the message which includes the timing information (step <NUM> of <FIG>). In response, the analytics function may perform the analytics for session or flow migration for the UE (step <NUM> of <FIG>). The analytics may include identifying whether the timing information satisfies a requirement or preference associated with a service level agreement (SLA) or profile of the UE (step 1106A of <FIG>). SLA or profile information may be obtained from a policy server (e.g. a PCF). Based on identifying that the timing information fails to satisfy the requirement or preference associated with the SLA or profile of the UE, the analytics function may send to the CP entity for session management one or more messages which may indicate an instruction to perform session or flow migration and/or contain resulting data of the analytics (e.g. information associated with a more suitable or optimal UP entity) (step 1106B of <FIG>).

Continuing with the flowchart <NUM> of <FIG>, the analytics function may perform the analytics further by implementing the following (step <NUM> of <FIG>). The analytics function may receive, from a different UP entity, a message which includes other timing information (step <NUM> of <FIG>). The other timing information may be indicative of at least another timing of communication of a data packet between the BS and the different UP entity, and may include or be derived at least in part from another (UE- or BS-added) timestamp. The analytics function may identify whether the other timing information from the other UP entity (i.e. the other BS-UP entity pairing) satisfies the requirement or preference associated with the SLA or profile of the UE (step <NUM> of <FIG>). The SLA or profile may be obtained from a policy server (e.g. a PCF). Based on identifying that the other timing information from the different UP entity satisfies the requirement or preference associated with the SLA of the UE, the analytics function may send to the CP entity for session management the one or more messages which include an identification of the different UP entity and/or associated information (step <NUM> of <FIG>). Although steps <NUM>-<NUM> are described as being performed in relation to a single additional UE, these steps may be performed for each one of a plurality of additional UEs in actual practice, so as to identify a more (e.g. most) suitable or optimal communication path and/or UP entity for the UE.

<FIG> is a flowchart <NUM> for describing yet another more descriptive, end-to-end SRv6 user-plane-based triggering method for session or flow migration in mobile networks according to some implementations of the present disclosure. The method of <FIG> pertains to an SRv6 user-plane-based triggering method for session or flow migration that is triggered based on a UE mobility event (e.g. handover or change in gNB). The method of <FIG> as described is applied specifically to a <NUM> mobile network and involves multiple entities of the <NUM> mobile network, including a gNB, a UPF, and a SMF.

Beginning at a start block <NUM> of <FIG>, a UE is being served by a gNB and has one or more sessions for communicating data packets that are routed (e.g. anchored) via UPF1. The UE or gNB may insert a timestamp in a header of data packet (step <NUM> of <FIG>). The data packet may be an SRv6 data packet where the header is an SRH. The UPF1 may receive the data packet and read the timestamp from the header (step <NUM> of <FIG>). The UPF1 may communicate to the analytics function a message which includes the timestamp (step <NUM> of <FIG>).

More generally, the message in step <NUM> may include timing information that is indicative of at least a timing of communication of the data packet between the gNB and the UP entity, and may include or be derived from the timestamp. For example, the timing information may include the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity, or may include a time differential between the timestamp and at least one other timestamp associated with receipt of the data packet at the UP entity.

The analytics function may receive, from the UPF1, the timing information (step <NUM> of <FIG>). The analytics function may obtain an SLA or profile information associated with the UE (step <NUM> of <FIG>). The SLA or profile may be obtained from a policy server (e.g. a PCF). The analytics function may determine whether the timing associated with the gNB-UPF1 pairing of the UE fails to satisfy the SLA or profile information (e.g. a requirement or preference) associated with the UE (step <NUM> of <FIG>). If the timing associated with the gNB-UPF1 pairing satisfies the SLA or profile information (e.g. the requirement or preference) as determined at step <NUM>, then the assessment is done (step <NUM> of <FIG>), but the technique may continue (regularly) repeated at step <NUM>.

If the timing associated with the gNB-UPF1 pairing fails to satisfy the SLA or profile information (e.g. the requirement or preference) as determined at step <NUM>, then session or flow migration for the UE may be performed. Here, the analytics function may identify a gNB-UPF pairing or UPF that will satisfy the SLA or profile information based on timing information associated with other gNB-UPF pairings (step <NUM> of <FIG>). The analytics function may send to the CP entity for session management one or more messages which may indicate an instruction to perform session or flow migration and/or contain resulting data of the analytics and/or (step <NUM> of <FIG>). The SMF may receive the message (step <NUM> of <FIG>) and perform the session or flow migration in response (e.g. to a newly-identified UPF) (step <NUM> of <FIG>).

<FIG> is an illustrative representation of a mobility node arrangement <NUM> for illustrating a portion of the methods associated with <FIG>, <FIG>, and <FIG>. In <FIG>, two gNBs 104a and 104b and three UPFs 122a, 122b, and 122c are shown, and various different gNB-UPF paths may be established therebetween. UE 102a may be served by gNB 104a and have one or more sessions for communication of data packets routed via UPF1 122a. Timestamps of the UE 102a or gNB1 104a and the UPF1 122a may be used to deriving timing information and a timing therebetween.

In <FIG>, analytics function <NUM> may obtain, from PCF <NUM>, an SLA or profile information <NUM> for UE 102a. Here, analytics function <NUM> may use the Nb interface to obtain the SLA constraints information, which may be class-based, QoS marking-based, SRv6 color-based, etc. Analytics function <NUM> may perform analytics to provide a determination <NUM> of whether the gNB1-UPF1 timing (e.g. derived from timestamps) satisfies (e.g. meets or exceeds) a requirement or preference of the SLA or profile information <NUM>. Note that many communication issues may result of a timing issue, for example, delay or jitter. If the timing fails to satisfy the requirement or preference as identified by analytics function <NUM>, session or flow migration for UE 102a (e.g. to UPF2 122b or UPF3 122c) may be performed. For example, analytics function <NUM> may send to the SMF a message which may indicate an instruction to perform session or flow migration and/or contain resulting data from the analytics.

More specifically, analytics function <NUM> may perform analytics to provide a determination of whether a gNB1-UPF2 timing or a gNB1-UPF3 timing (e.g. derived from timestamps) satisfies (e.g. meets or exceeds) the requirement or preference of the SLA or profile information <NUM> for UE 102a. Analytics function <NUM> may select or identity either UPF2 122b or UPF3 122c as a preferred UPF for session or flow migration of UE 102a based on determining the associated timing satisfies the requirement or preference of the SLA or profile information <NUM> for UE 102a. Here, analytics function <NUM> may send to the SMF a message which may indicate an instruction to perform session or flow migration and/or contain resulting data from the analytics (e.g. information associated with a more suitable or optimal UPF, i.e. UPF2 122b based on gNB1-UPF2 timing or UPF3 122c based on gNB1-UPF3 timing).

Also, some implementations associated with <FIG>, <FIG>, <FIG>, and <FIG> may make specific use of SRv6 and data fields associated with In-situ OAM. Here, in some implementations, each BS or gNB may be instructed to "punch" the timestamp of the data packet, using "Trace Type" set to relevant bits depending on the SLA constraints (e.g. bits <NUM> and <NUM> for delay/jitter measurement). In other implementations, each BS or gNB may be programmed with a (domain-wide unique) Segment ID (SID) which may be referred to as a timestamp SID (tsSID). For example, the semantic associated with the tsSID may be as follows:
IF match (SID==tsSID),
Insert timestamp in SRv6 TLV
POP and FORWARDThe latter option may be preferred and utilized when the UE is capable and configured to forward SRv6 packets.

<FIG> form a call flow diagram 1400a / 1400b for describing an end-to-end, SRv6 user-plane-based triggering method for session migration in a mobile network, where the UE may be multi-homed. In <FIG>, UE <NUM> may be served by gNB1 104a and establish a PDU session with UPF1 122a (step <NUM> of <FIG>). SRv6 data packets are communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). UE <NUM> is moved to an area of a new gNB (e.g. gNB2 104b); therefore, the PDU session of the UE <NUM> may be handover from (source) gNB1 104a to a (target) gNB2 104b (step <NUM> of <FIG>). A sub-optimal path for the PDU session may result, which may include a (e.g. more lengthy) path between gNB2 104b and UPF1 122a. SRv6 data packets may now be communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>).

In the handover, the UE <NUM> or gNB2 104b may add or insert an ID of the new serving (target) gNB2 104b in a header of a SRv6 data packet as iOAM data (e.g. an iOAM TLV). Upon receipt of the data packet, UPF1 122a may extract (or otherwise read, identify, or detect) the iOAM details (i.e. the ID of the BS) from the header (step <NUM> of <FIG>). UPF1 122a may send a message which includes the iOAM details to the NWDAF <NUM> (step <NUM> of <FIG>). In response, NWDAF <NUM> may perform analytics for session or flow migration for the UE <NUM>. Here, NWDAF <NUM> may consult a database or otherwise determine whether the route for the session/flow is less than optimal (step <NUM> of <FIG>). If so, the NWDAF <NUM> may send to SMF <NUM> a message which indicates an instruction for session or flow migration for the UE <NUM> and/or contains resulting data from the analytics (step <NUM> of <FIG>). Here, in particular, NWDAF <NUM> may send an identification of UPF2 122b and data corresponding to the session context.

Continuing in <FIG>, SMF <NUM> may receive the message from NWDAF <NUM> and select UPF2 122b as a (e.g. more suitable or optimal) route to DN <NUM> (step <NUM> of <FIG>). SMF <NUM> may then establish a connection with UPF2 122b (step <NUM> of <FIG>). SMF <NUM> may then establish a BP / UPCL with a UPF BP (step <NUM> of <FIG>). SMF <NUM> may update the UPF1 122a for downlink traffic to the UE <NUM> (step <NUM> of <FIG>) which is illustrated with indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). SMF <NUM> may update the gNB2 104b for uplink traffic to the UE <NUM> (step <NUM> of <FIG>) which is illustrated with indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). Given the new UPF2 122b, a new IPv6 prefix may be assigned to the UE <NUM> (step <NUM> of <FIG>). SMF <NUM> may then reconfigure the IPv6 prefix for the UE <NUM> (step <NUM> of <FIG>). SRv6 data packets may now be communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, <NUM> of <FIG>).

<FIG> is a call flow diagram <NUM> for describing an end-to-end, SRv6 user-plane-based triggering method for session migration in a mobile network, where the trigger is a mobility event (e.g. UE handover). In <FIG>, UE <NUM> may be served by gNB1 104a and establish a PDU session with UPF1 122a (step <NUM> of <FIG>). SRv6 data packets are communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). UE <NUM> is moved to an area of a new gNB (e.g. gNB2 104b); therefore, the PDU session of the UE <NUM> may be handover from (source) gNB1 104a to a (target) gNB2 104b (step <NUM> of <FIG>). A sub-optimal path for the PDU session may result, which may include a (e.g. more lengthy) path between gNB2 104b and UPF1 122a. SRv6 data packets may now be communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>).

In the handover, the UE <NUM> or gNB2 104b may add or insert an ID of the new serving (target) gNB2 104b in a header of a SRv6 data packet, as iOAM data. Upon receipt of the data packet, UPF1 122a may extract (or otherwise read, identify, or detect) the iOAM details (i.e. the ID of the BS) from the header (step <NUM> of <FIG>). UPF1 122a may send a message which includes the iOAM details to the NWDAF <NUM> (step <NUM> of <FIG>). In response, NWDAF <NUM> may perform analytics for session or flow migration for the UE <NUM>. Here, NWDAF <NUM> may consult a database or otherwise determine whether the route for the session/flow is less than optimal (step <NUM> of <FIG>).

If so, the NWDAF <NUM> may send to SMF <NUM> a message which indicates an instruction for session or flow migration for the UE <NUM> and/or contains resulting data from the analytics (step <NUM> of <FIG>). Here, in particular, NWDAF <NUM> may send an identification of UPF2 122b and data corresponding to the session context. In response, SMF <NUM> may perform session migration for the UE <NUM>. Here, SMF <NUM> may notify the UE <NUM> to reattach (e.g. detach / attach) (step <NUM> of <FIG>). In response, UE <NUM> may detach and attach with the network (step <NUM> of <FIG>). In the reattachment, the SMF <NUM> may select the (more optimal) UPF2 122a for the session migration (step <NUM> of <FIG>). SRv6 data packets may now be communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>).

<FIG> is a call flow diagram <NUM> for describing an end-to-end, SRv6 user-plane-based triggering method for flow migration in a mobile network, with use of uplink classification. In <FIG>, UE <NUM> may be served by gNB1 104a and establish a PDU session with UPF1 122a (step <NUM> of <FIG>). SRv6 data packets are communicated in the PDU session of UE <NUM> between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). UE <NUM> may then establish a new PDU session (step <NUM> of <FIG>). A suboptimal path for this PDU session may result, which may include a (e.g. more lengthy) path between gNB2 104b and UPF1 122a.

For the new session, the UE <NUM> or gNB2 104b may add or insert an ID of the new session (e.g. a session ID) in a header of a SRv6 data packet, as iOAM data. Upon receipt of the data packet, UPF1 122a may extract (or otherwise read, identify, or detect) the iOAM details (i.e. the session ID) from the header (step <NUM> of <FIG>). UPF1 122a may send a message which includes the iOAM details to the NWDAF <NUM> (step <NUM> of <FIG>). In response, NWDAF <NUM> may perform analytics for session or flow migration for the UE <NUM>. Here, NWDAF <NUM> may consult a database or otherwise determine whether the route for the session/flow is less than optimal (step <NUM> of <FIG>).

If so, the NWDAF <NUM> may send to SMF <NUM> a message which indicates an instruction for session/flow migration for the UE <NUM> and/or contains resulting data from the analytics (step <NUM> of <FIG>). Here, in particular, NWDAF <NUM> may send an identification of UPF2 122b and data corresponding to the session context. In response, SMF <NUM> may perform session migration for the UE <NUM>. Here, SMF <NUM> may select (the more optimal) UPF2 122b for one or more notified flows and insert rules in UPCL <NUM> to divert the flows (step <NUM> of <FIG>). SMF <NUM> may send to UPCL <NUM> one or more messages which indicate the rules to divert flows to UPF2 122b (step <NUM> of <FIG>). In response, UPCL <NUM> operates to divert some of its flows to UPF2 122b (step <NUM> of <FIG>). SRv6 data packets are communicated between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>). UPCL <NUM> then operates to divert remaining flows to UPF1 122a (step <NUM> of <FIG>). SRv6 data packets are communicated between the indicator points as shown (see indicator points <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>).

In some alternative implementations of the techniques of FIGs. 14A-15B, <FIG>, and <FIG>, the UPF1 122a may communicate the one or more messages to an application function (AF) instead of NWDAF <NUM>, so that the AF may (determine whether to) request and receive the resulting data from the analytics performed by NWDAF <NUM>. Here, the AF may subsequently (determine whether to) send to SMF <NUM> the one or more messages to indicate an instruction and/or contain the resulting data from the analytics. In other alterative implementations, UPF1 122a may communicate the one or more messages to SMF <NUM> instead of NWDAF <NUM>, so that SMF <NUM> may (determine whether to) request and receive from NWDAF <NUM> the resulting data from the analytics.

Regarding the implementations above, note that <NUM> may or may not allow a UE to insert an SRH and associated metadata in a given data packet. If <NUM> allows a UE to insert the SRH and associated metadata (e.g. ID of base station or session), then in some implementations it is preferred that the UE (instead of the base station) insert the SRH and associated metadata. Otherwise, it is preferred that the base station insert the SRH and associated metadata.

Some implementations of the present disclosure have been shown in the figures to apply to a <NUM> mobile network; however, implementations may be readily applied to other suitable types mobile networks, such as <NUM>, Long Term Evolution (LTE) based networks having a control and user plane separation (CUPS) architecture, as one ordinarily skilled in the art will readily appreciate. In <NUM>/LTE with CUPS, the user plane function may be a gateway - user plane (GW-U). As other examples, the SMF may instead be a GW - control plane (GW-C), the AMF may instead be a mobility management entity (MME), the PCF may instead be a policy and control rules function (PCRF). The SMF and GW-C may be more generally referred to as a CP entity for session management. Other naming conventions may be adopted or realized.

Note that, although in some implementations of the present disclosure, one or more (or all) of the components, functions, and/or techniques described in relation to the figures may be employed together for operation in a cooperative manner, each one of the components, functions, and/or techniques may indeed be employed separately and individually, to facilitate or provide one or more advantages of the present disclosure.

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. These terms are used to distinguish one element from another. For example, a first UPF could be termed a second UPF, and similarly, a second UPF could be termed a first UPF, without changing the meaning of the description, so long as all occurrences of the "first UPF" are renamed consistently and all occurrences of the "second UPF" are renamed consistently. The first UPF and the second UPF are both UPFs, but they are not the same UPF.

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 (<NUM>) comprising:
at a user plane, UP, entity for use in a mobile network,
receiving (<NUM>) a data packet from a user equipment, UE, operative to communicate in one or more sessions via a serving base station, BS, of the mobile network;
detecting (<NUM>), in a header of the data packet, an identifier indicating a new serving BS or session of the UE, the identifier being UE- or BS-added data; and
in response to detecting the identifier indicating the new serving BS or session of the UE, causing (<NUM>) a message to be sent to an analytics function to perform analytics for session or flow migration for the UE,
wherein the header of the data packet comprises a segment routing header, SRH, of a Segment Routing, SR, for IPv6, SRv6, data packet.