Patent Description:
Generally, this disclosure relates to managing a service function chain associated with a user session in a communications network, such as a third generation (<NUM>), fourth generation (<NUM>) or fifth generation (<NUM>) communications network. <FIG> shows a (prior art) configuration of a Third Generation Partnership Project (3GGP) <NUM> reference network architecture that is relevant to some embodiments herein. The <NUM> network reference architecture comprises a plurality of functions, e.g. functional building blocks with well-defined functional behaviors and external interfaces. The functions may be implemented in hardware but are increasingly implemented in software, for example in a service based architecture.

The <NUM> reference architecture in <FIG> comprises a user equipment (UE) <NUM>, a Radio Access Network (RAN) <NUM>, a User Plane Function (UPF) <NUM>, a Data Network (DN) <NUM>, an Access and Mobility Function (AMF) <NUM>, an Authentication Server Function (AUSF) <NUM>, a Session Management Function (SMF) <NUM>, a Network Slice Selection Function (NSSF) <NUM>, a Network Exposure Function (NEF) <NUM>, a Network Repository Function (NRF) <NUM>, a Policy Control Function <NUM>, a Unified Data Management (UDM) node <NUM> and an Application Function (AF) <NUM>. <FIG> shows a (prior art) 3GPP <NUM> core (5GC) architecture for policy, charging and analytics further comprising a Unified Data Repository (UDR) <NUM>, a Network Data Analytics Function (NWDAF) <NUM>, and a Charging Function (CHF) <NUM>. The functionality of these network functions are described, for example, in the Third Generation Partnership Project 3GPP technical standard 3GPP TS <NUM>.

This disclosure is primarily related to the Policy Control Function (PCF) <NUM>, Session Management Function (SMF) <NUM>, User Plane Function (UPF) <NUM> and the Unified Data Repository (UDR) <NUM>, the functionality of which is summarized below.

PCF (Policy Control Function): The Policy Control Function (PCF) <NUM> supports unified policy framework to govern the network behaviour. With respect to the disclosure herein, the PCF <NUM> provides Policy and Charging Control (PCC) rules to the SMF <NUM>.

SMF (Session Management Function): The Session Management function (SMF) <NUM> supports different functionality, e.g. session establishment, modify and release, and policy related functionalities like termination of interfaces towards policy control functions, charging data collection, support of charging interfaces and control and coordination of charging data collection at UPF <NUM>. With respect to the disclosure herein, the SMF <NUM> receives PCC rules from the PCF <NUM> and configures the UPF <NUM> accordingly through the N4 reference point (Packet Forwarding Control Protocol (PFCP) protocol). According to the PFCP protocol, the SMF <NUM> controls the packet processing in the UPF <NUM> by establishing, modifying or deleting PFCP Sessions and by provisioning (e.g. adding, modifying or deleting) Packet Detection Rules (PDRs), Forwarding Action Rules (FARs), QoS Enforcement Rules (QERs) and/or Usage Reporting Rules (URRs) per PFCP session, whereby a PFCP session may correspond to an individual PDU session or a standalone PFCP session not tied to any PDU session. Each PDR contains a PDI specifying the traffic filters or signatures against which incoming packets are matched. Each PDR is associated to the following rules providing the set of instructions to apply to packets matching the PDI: (i) one FAR, which contains instructions related to the processing of the packets, specifically forward, duplicate, drop or buffer the packet with or without notifying the CP function about the arrival of a DL packet; (ii) zero, one or more QERs, which contains instructions related to the QoS enforcement of the traffic; and (iii) zero, one or more URRs, which contain instructions related to traffic measurement and reporting.

UPF (User Plane Function): The User Plane function (UPF) <NUM> supports handling of user plane traffic based on the rules received from SMF, specifically, for this IvD, packet inspection (through PDRs) and different enforcement actions, e.g. traffic steering, QoS, Charging/Reporting (through FARs, QERs, URRs).

DPI (Deep Packet Inspection), embedded in UPF <NUM>, is a technology that supports packet inspection and service classification, which consists of IP packets classified according to a configured tree of rules so that they are assigned to a particular service session. DPI technology, offers two types of analysis:
Shallow packet inspection: extracts basic protocol information such as IP addresses (source, destination) and other low-level connection states. This information typically resides in the packet header itself and consequently reveals the principal communication intent.

Deep Packet inspection (DPI): provides application awareness. This is achieved by analyzing the content in both the packet header and the payload over a series of packet transactions. There are several possible methods of analysis used to identify and classify applications and protocols that are grouped into signatures. One of them uses heuristic signatures which are determined based on behavioural analysis of the user traffic.

In Control and User Plane Separation (CUPS), the UPF reports to the SMF the capabilities it supports. The current standardized capabilities are summarised in 3GPP document <NPL>).

UDR (Unified Data Repository): The <NUM> System architecture allows the UDM <NUM>, PCF <NUM> and NEF <NUM> to store data in the UDR <NUM>, including subscription data and policy subscription data and policy data by UDM <NUM> and PCF <NUM>, structured data for exposure and application data (including Packet Flow Descriptions (PFDs) for application detection and AF <NUM> request information for multiple UEs) by the NEF <NUM>.

Service Function Chaining: Service Function Chaining (SFC), also known as network service chaining, is a capability that creates a service chain of connected Service Functions (SF) (such as L4-<NUM> like firewalls, network address translation (NAT), intrusion protection, QoS, etc.) and connects them in a virtual chain. This capability can be used by network operators to set up suites or catalogs of connected services that enable the use of a single network connection for many services, with different characteristics.

Dynamic Service Chaining enables customer service providers to configure and to control dynamically and programmatically network services. IETF SFC draft RFC <NUM> defines a new data plane protocol specifically for the creation of dynamic service chains and is composed of the following elements: <NUM>) Service Function Path identification (Service Function Classifier, SFC). The SFC is responsible for performing service classification and imposing a Network Service Header (NSH), sending the NSH packet to the first SFF in the path; <NUM>) Transport independent service function chain (Service Function Forwarder). The SFF is responsible for forwarding traffic to one or more service functions according to the information of encapsulation (NSH); <NUM>) Per-packet network and service metadata or optional variable TLV metadata.

SFC is standardized by the Internet Engineering Task Force, IETF and the reference architecture is summarised in the <NPL>".

<CIT> discloses method for wireless communications, in which a policy control function may determine a policy and charging control rule comprising one or more Ethernet source MAC addresses and a quality of service policy.

In 3GPP networks, service function chains SFCs are part of the User Plane (UP). The Service functions (SFs) and the SF Forwarder can be deployed in the N6 interface (so called N6-LAN) or within the UPF <NUM>. SFCs are identified by a Chain-ID that is sent from the PCF <NUM> to the SMF <NUM> on a per user basis (e.g. in the PCC rules), and then the SMF <NUM> configures in the UPF <NUM> appropriate Packet Detection Rules (PDR) and Forwarding Action Rules (FAR). The chain-ID is included in the FAR.

The traffic steering policy ID is preconfigured by the PCF <NUM> on a per user basis. The SMF <NUM> translates the traffic steering policy ID to the UPF routing configuration (when it comes to service chaining, the SMF <NUM> includes the chain-ID in the FAR). The UPF <NUM> includes the chain-ID in the traffic that is passed to the SF Forwarder (e.g. in the NSH header). The SF Forwarder has a preconfigured mapping between the chain-ID and the ordered set of SFs for that particular chain.

The disclosure herein aims to improve upon scenarios where a SFC for a session needs to be modified or updated (for example, via the addition or deletion of one or more services in a service function chain), particularly where one or more service functions in the SFC modifies packets in the traffic flow.

Customer Service Providers may need to insert or remove service functions dynamically whilst keeping the state information stored in existing service functions. For example if a user is making a VoIP call by Facebook or whatsapp, a customer service provider may want to optimize this service by directing session traffic to a particular SF (e.g. the customer service provider may specify a particular SF for the VoIP call).

In order to achieve this, a service classifier will use DPI techniques to identify the corresponding traffic flows as a VoIP call and to insert the corresponding NSH packets towards SFF. However, if the service is identified based on a heuristic algorithm then identification/classification can take some time. Heuristic algorithms are used to identify services whose protocol is unknown or proprietary or hidden for security/safety reasons. In such circumstances, heuristic algorithms are applied to effectively "guess" or deduce the traffic packet type. Such heuristic algorithms may be indeterministic, for example, using statistical analysis, packet metadata and application attributes to identify services. As such, heuristic algorithms can take some time (e.g. a number of packets in a service may need to be send and monitored) to classify the traffic. As such, traffic flows may be allocated to a SFC incorrectly until a more accurate classification is determined (e.g. using statistic, signatures/metadata), at which point, once the heuristic algorithm has classified the packets, the session may need to be moved to a new SFC with more appropriate SFs for the session in view of the new classification.

In current implementations of dynamic SFC, modifications to SFCs are supported by destroying the existing service chain completely, followed by creating a new service chain instance that includes new and correct service function instances that properly handle the traffic (e.g. SFs to increase voice quality or comprising voice to save resources in a VoIP call).

However, this solution affects the service and impacts user experience since there are services that once packets are being handled by a SF, cannot be handled by a new SFC without dropping TCP connection and restarting the connection again. For example, if a SF acts as a HTTP proxy, this SF will open a new connection to the HTTP destination server on behalf of the user. The HTTP proxy will keep two TCP connections, one towards user, another one towards HTTP server. If this service needs to be migrated to another SF, the new SF must start again the TCP connection towards the user and the HTTP user.

In summary, a service classifier can take time to classify session packets and identify the most appropriate SFs for a session. This can result in traffic packets being be handled by a wrong (or sub-optimal) SF for some time until the service classifier changes or improves the identification. As such, a SFC may need to be migrated to a new SFC when the heuristic engine has finished its transient period. This may lead to the connection being reset, particularly if the SFC modifies the behavior of the connection and there is a need to migrate, modify (include/delete) a new SF in the SFC.

It is an object of embodiments herein to improve on such scenarios.

Thus according to a first aspect herein there is a method in a policy control function, PCF, of moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. The method comprises determining to update a second SF in the SFC for the session; determining a new SFC for the session comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF; and sending a first message to a session management function, SMF, comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of the new SFC for the session. The method is performed responsive to receiving a service continuity indicator for the session wherein the service continuity indicator indicates that the session should be maintained. The service continuity indicator is obtained by the PCF from a unified data repository, UDR, as part of a session establishment procedure for the session.

In this manner, the PCF pre-configures a new service function chain for the session, that comprises the update to the second service function, whilst taking account of the modification to packets associated with the first service function, so as to ensure a smooth transition of the session from the SFC to the new SFC. Preconfiguring a new SFC in this manner, ensures that the TCP connection does not drop as the session is moved to the new SFC. Thus service traffic can be diverted to the correct SFC without dropping any session. This is efficient from a resource perspective to avoid impacting user experience.

According to a second aspect, there is a method in a session management function, SMF, of moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. The method comprises: receiving from a policy control function, PCF, as part of a session establishment procedure for the session, an indication of a service continuity indicator for the session, wherein the service continuity indicator indicates that the session should be maintained; responsive to receiving a third message from a user plane function, UPF, associated with the session, the third message indicating that the first SF is modifying packets in the session, sending a second message to a policy control function, PCF, comprising a request for updated policy control rules for the session, wherein the second message comprises information related to the modification being performed by the first SF; receiving a first message from the PCF comprising the updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session, wherein the new SFC comprises new SFs selected by the PCF; and sending a fourth message to the UPF, the fourth message comprising the updated policy control rules for the session.

According to a third aspect there is a method in a user plane function, UPF, of moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. The method comprises receiving a service continuity indicator associated with the session in a PFCP Session Establishment Request or a PFCP Session Modification Request as part of a session establishment procedure for the session, wherein the service continuity indicator indicates that the session should be maintained; sending a third message to a session management function, SMF, the third message indicating that the first SF is modifying packets in the session; receiving from the SMF a fourth message, the fourth message comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session; and moving the session from the SFC to the new SFC, based on the received updated policy control rules.

According to a fourth aspect there is a network function, NF, node for Policy Control, in a communications network, suitable for moving a session from a service function chain, SFC, to a new SFC. The SFC comprises a first SF that modifies packets in the session. The NF node comprises processing circuitry configured to perform the method of the first aspect.

According to a fifth aspect there is a network function, NF, node for session management, in a communications network, suitable for moving a session from a service function chain, SFC, to a new SFC. The SFC comprises a first SF that modifies packets in the session. The NF node comprises processing circuitry configured to perform the method of the second aspect.

According to a sixth aspect there is a network function, NF, node in the user plane, in a communications network, suitable for moving a session from a service function chain, SFC, to a new SFC. The SFC comprises a first SF that modifies packets in the session. The NF node comprises processing circuitry configured to perform the method of the third aspect.

According to a seventh aspect there is a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any embodiment of the first, second or third aspects.

For a better understanding and to show more clearly how embodiments herein may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:.

As described above, it is an object of embodiments herein to provide improved service function chain (SFC) management particularly where a service function (SF) in the service function chain needs to be modified (e.g. added, deleted or reconfigured). This may occur, for example, when packets belonging to a session that is served by a SFC are classified by a heuristic algorithm. Often a number of packets are transferred across the communications network using a (generic) service chain before the heuristic algorithm is able to properly classify the packets. The session may then need to be moved to a new SFC better able to handle, or optimised for, that packet type. If a SFC is terminated and the new SFC initiated as in current methods, then this can result in loss of TCP connection, affecting user experience. In particular, this occurs when one of the SFs in the SFC is modifying packets in the traffic. For example, a HTTP proxy opens a new connection to the destination server in behalf of client. This allows new HTTP headers to be inserted or the HTTP connection to be modified for optimisation (comprising payload, etc). With a http proxy module, the TCP connection that is seen by the destination server is different from TCP connection that is seen from the client. So, it is necessary to keep both TCP connections up and running to avoid impacting in client/destination experience. If HTTP proxy is destroyed, some other element else is needed to keep this TCP seq. number correlation between client/server to avoid impacting in both connections. In embodiments herein a new SF for the new SFC may be selected by a PCF so as to keep the TCP seq. number correlation between the client and server.

As will be explained in detail below, methods herein relate to moving a session from a service function chain (SFC) to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. Briefly, embodiments herein propose that responsive to determining to update a SF in the SFC for a session, the policy control function, PCF will determine a new SFC for the session comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF. In other words, the PCF will preconfigure a new SFC that takes the packet modification into account, so as to provide a smooth transition and enable the session to be moved to the new SFC without disruption to the session.

By means of a summary, embodiments herein may comprise elements such as, for example: i) a registration procedure whereby each UPF <NUM> registers its SFs with the SMF, along with the capability each SF supports (e.g. firewalling, nat, etc.) and the SFs corresponding traffic behavior modification (e.g. in terms of proxy, address translation, stateful connections, etc.); ii) a session establishment procedure whereby at PDU session establishment, based on the traffic steering info, the SMF may decide how to change traffic when needed, based on the registered SF characteristics; iii) a service continuity indicator or profile whereby the UDR <NUM> may store (per service) a service continuity indicator for each user session (or type of user session) that describes how a session should be handled from a service continuity perspective; iv) the UPF <NUM> may inform the SMF of traffic modifications performed by a SF; v) the SMF may inform the PCF <NUM> about the modifications; vi) the PCF <NUM> may the update the forwarding policies (SFCs) to be activated in the UPF <NUM> on a per user and application basis, based on the traffic modifications done by UPF <NUM> and SFs for the session; and vii) the UPF <NUM> may divert traffic to a new SFC comprising the corresponding SFs without impacting traffic, in consideration of the reported traffic modifications. In examples where they are handled by the same SFF, including light SF and notifying the changes (for example the TCP state information for both connections, etc) applied using NSH. In examples where they are handled by different SFF, including light SF and notifying those changes using PFCP signalling.

In more detail, <FIG> illustrate methods according to various embodiments herein for moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. In other words, methods for managing SFs in a service function chain, without loss of TCP connection for a session associated with the SFC.

<FIG> illustrates a registration procedure between a UPF <NUM> and a SMF <NUM> for registering SFs of the UPF <NUM> with the SMF <NUM> according to some embodiments herein. The registration procedure gives the SMF <NUM> visibility of the SFs available to each UPF <NUM>. This enables the SMF <NUM> to select an appropriate UPF <NUM> for a session (e.g. a UPF able to provide SFs needed for the session).

At <NUM> of the registration procedure, in <FIG>, the UPF <NUM> sends a registration message to the SMF <NUM>. The registration message comprises information to register one or more SFs associated with the UPF <NUM>. For example, for each SF in the one or more SFs, the registration message may comprise i) an identifier for the respective SF and ii) an indication of any packet modifications performed by the respective SF. Additionally, the registration message may comprise a count of the one or more SFs to be registered.

In the embodiment of <FIG>, the registration message <NUM> comprises a PFCP association message. PFCP association message <NUM> comprises a list of tuples, each tuple comprising, for example, the following fields:.

At <NUM>, the SMF <NUM> sends a PFCP association response message to the UPF <NUM> to acknowledge signal <NUM> from the UPF <NUM>.

In some embodiments, the existing PFCP association response message may be modified to comprise one or more of the following bits:.

An example PFCP Association Request according to some embodiments is illustrated in signal <NUM> of <FIG> which shows a PFCP Association request from a UPF having four SFs; a first with traffic behaviour of type "http proxy", a second with no traffic modification, a third with traffic behaviour of type "top modification" and a fourth with traffic behaviour of type network address translation "NAT". The SMF <NUM> may use registration messages of this type to select, from a plurality of UPFs, a UPF for a particular session.

A summary of User plane (UP) function features according to some embodiments herein is provided in Annex I.

Turning now to <FIG>, which illustrates how the SMF <NUM> may trigger reporting of traffic modifications performed by service functions according to some embodiments herein. In some embodiments, the SMF <NUM> sends a message <NUM> to the UPF <NUM>, the message <NUM> comprising an instruction to the UPF <NUM> to commence SF Traffic behaviour reporting. The message <NUM> may comprise, for example, a list of target SF-IDs corresponding to SFs for which the UPF <NUM> should report on. The message <NUM> may further comprise an indication of a reporting trigger, for example, an indication of when the UPF <NUM> should provide the traffic behaviour reports. This may, for example, indicate that the traffic behaviour reports should be send e.g. periodically, after a predetermined time interval, etc. The message <NUM> may comprise a different reporting trigger for each SF-ID.

At <NUM> the UPF <NUM> acknowledges the subscription request. And at <NUM>, in response to the message <NUM>, the UPF <NUM> then sends the traffic behaviour modification report(s) to the SMF. The message <NUM> may comprise an indication that a SF is modifying packets in the session. The message <NUM> may comprise a list of SF-IDs and Traffic Modifications, for example the message <NUM> may comprise i) a <NUM> Tuple for the session, ii) a New <NUM> Tuple for the session iii) a TCP ACK Number for the session iv) a TCP Sequence Number for the session.

The SMF <NUM> can use this information to provide a smooth reselection/handover between SFCs when those chains are inter UPF. If the handover is intra UPF, the new UPF may be provided with all the information to provide a smooth reselection/handover between SFCs.

Turning now to <FIG>, which illustrates a Session Establishment Procedure according to some embodiments herein. In some embodiments, the UDR <NUM> may be used to store information for each user and each application/session for each user, an indication of a service continuity level that should be applied to traffic for that user and/or application/session. The service continuity level may be used to determine how to manage a session associated with a SFC when a SF in the SFC needs to be modified. For example, whether it is appropriate to initiate a new SFC (e.g. according to prior art methods) or whether service continuity should be applied, e.g. whether SFC modification should be handled according to the methods described herein.

Thus, according to the embodiment of <FIG>, a session may be established as follows. In signals <NUM>-<NUM>, the UE (e.g. end user) makes a session Establishment Request <NUM> to the AMF which sends a Nsmf Session Create request <NUM> to the SMF. The SMF sends an Npcf_SMPolicyControl_CreateRequest <NUM> to the PCF. The PCF <NUM> then sends a Nudr_Query_Request <NUM> to the UDR <NUM>. Signals <NUM> to <NUM> may be sent using standard messages.

In signal <NUM>, the UDR <NUM> sends an indication of a service continuity indicator for the session to the PCF <NUM>. The service continuity indicator may indicate, for example, one of the following levels of continuity for the service i) that the session can be restarted; ii) that the session can be broken and continued; or iii) that the session should be continuous. In some embodiments, the UDR <NUM> may send the subscriber policy and the service continuity for each service to the PCF <NUM> in a Nudr_Query_Response message. A service continuity indicator in the Nudr_Query_Response message may indicate one of several profiles, for example, one of the following profiles:.

At signal <NUM>, the PCF <NUM> sends PCC Rules with the service continuity profile to the SMF <NUM>. In this embodiment, if a session has a service continuity with profile <NUM> (Service Continuity) as above, the SMF <NUM> may then select a UPF for the session with Traffic Modification capacity, e.g. a UPF configured to perform the SFC modification procedure herein.

The SMF selects a UPF (with Traffic Behavior Modification and the corresponding enforcement actions: FARs, URRs, etc) for the PDU session. Specifically, SMF will provision the Service Continuity information (e.g. Profile <NUM>). At signal <NUM>, the SMF <NUM> signals the (selected) UPF, and sends the UPF <NUM> an indication of the service continuity profile for the session. In some embodiments, the service continuity profile is sent to the UPF <NUM> in a PFCP Session Establishment Request. In some embodiments, the PFCP protocol comprises an IE comprising the service continuity in the "PFCP Session Establishment/Modification Request". An example of how the PFCP Session Establishment/Modification Request could be modified to comprise the service continuity indicator is illustrated in Annex II. An example IE that may be used to transmit the service continuity profile is illustrated in Annex III.

In signal <NUM>, the UPF <NUM> acknowledges the SMF request and in signals <NUM> and <NUM>, the user session is established.

Thus in summary, using the methods outlined in <FIG>, a UPF may register its SFs with PCF and a service continuity profile may be saved in the UDR <NUM> for each user session. According to <FIG>, when a set up procedure is initiated for a session, this enables the PCF to select an appropriate UPF for the session, taking the SFs required for the session and the continuity profile into account.

Turning now to <FIG> which illustrate a method of moving a session comprising a facebook call from a default service function chain, SFC, to a new SFC "Service Chain <NUM>", wherein the default SFC comprises a first SF "http proxy" that modifies packets in the session. The new SFC, "Service Chain <NUM>" comprises new SFs, one of which is a light proxy which is added to account for the modification that was performed by the http proxy of the default SFC.

In <FIG> the UPF is composed internally by:.

The skilled person will appreciate however, that this configuration is an example only and that these elements may be implemented in the UPF <NUM> or in other nodes.

The method of the embodiment illustrated in <FIG> assumes that the UPF <NUM> has registered its SFs with the SMF, for example using the method described above with respect to <FIG>. In <FIG>, the SMF requests UPF traffic modifications, for example, according to the method set out in <FIG>. The SMF may be configured to request traffic modification information because, on session establishment, the SMF received an indication that the service continuity profile for the session should be "continuous" (e.g. Session Continuity for Services are Profile <NUM>, as described above with respect to <FIG>). In other words, in this embodiment, in signal <NUM> of <FIG>, on session establishment, the SMF will send the following IE to the UPF:.

The UPF receives an indication of the SFC that should be used for the session, from the Forwarding Policy IE received from the SMF, and the UPF then routes the traffic to the corresponding chain.

In more detail, the signals in <FIG> comprise:.

In this case, a default Service Chain is assigned to HTTP traffic. This default Service Chain is composed by a single Service Function that provides HTTP proxy functionality.

VoIP call are assigned to a Service Chain <NUM> that is composed by a voice optimizer.

SC routes the traffic to Service Function Forwarder (SFF) indicating a default Service Function Chain (SFC) using for example NSH.

Service Function (SF)<NUM> is a HTTP proxy to optimize HTTP traffic (adding new HTTP headers or comprising HTTP content or optimizing TCP connection). SF1 will create a new TCP connection to HTTP server. SF1 will keep a TCP connection to user and another one to HTTP server. SF1 needs to save ACK numbers from user TCP connection to correlate them with new TCP connection. So, Facebook traffic is altered.

Modified Facebook traffic is sent to SFF. As SFF knows that SF1 modifies the traffic. SFF checks those changes in the traffic.

SFF sent traffic from SF1 to the Application Function (AF).

UPF reports the modification of traffic towards SMF according to procedure defined in <FIG> with the information provided in step <NUM> by SFF. During the whole end user session while traffic modification is still valid, UPF reports these modifications.

SMF answers to the previous reporting of UPF.

SMF asks to PCF for new PCC Rules due to the fact that there is traffic modification in some services. SMF consolidates per service those traffic modifications in each SF. SMF sent towards PCF information about the Service that is matched, and the traffic modification done.

The method is continued in <FIG>. The signals in <FIG> comprise:.

In this manner, the session (facebook VoIP call) is moved from a (default) SFC to a new SFC (service chain <NUM>) without dropping TCP connection. The default SFC comprised a first SF "http proxy" that modified packets in the session. An update is determined whereby a second SF "SF <NUM> voice optimizer" needs to be added to the SFC serving the session. Thus a new SFC is configured comprising new SFs including the second SF "SF <NUM> voice optimizer" and a light proxy SF3 which is added in view of the modification that was made to traffic packets by the http proxy in the default SFC.

Turning now to <FIG> which illustrate an example embodiment whereby a facebook session (facebook call initiated in signal <NUM> as described below) is initially served by a default SFC that comprises two SFs that modify packets in the session a first SF labelled "SF4 NAT" and a third SF labelled "SF1 HTTP proxy". After heuristic analysis is performed, the UPF classifies the facebook session as VoIP, and the traffic is moved to a new SFC "Service Chain <NUM>". The new SFC comprises new SFs - "SF2 Voice Optimizer" and a light proxy which compensates for the traffic modifications performed by the first SF and third SF in the default SFC.

The method of the embodiment illustrated in <FIG> assumes:.

In this case, Service Chain <NUM> is assigned to HTTP traffic. This default Service Chain is composed by two Service Functions that provides HTTP proxy and NAT functionality.

SC routes the traffic to Service Function Forwarder (SFF) indicating the Service Function Chain (SFC) <NUM> using for example NSH Service Function (SF)<NUM> is a HTTP proxy to optimize HTTP traffic (adding new HTTP headers or comprising HTTP content or optimizing TCP connection). SF1 will create a new TCP connection to HTTP server. SF1 will keep a TCP connection to user and another one to HTTP server. SF1 needs to save ACK numbers from user TCP connection to correlate them with new TCP connection. So, Facebook traffic is altered.

SFF sent traffic towards the next element in the Chain. In this case the Service Function of NAT. SF changes the IP address.

SF of NAT sends the traffic back to SFF.

SFF sent traffic to the Application Function (AF). As SFF knows that this chain modifies traffic characteristics, SFF tracks those changes. So, it tracks how traffic is altered. UPF reports the modification of traffic towards SMF according to procedure defined in <FIG> with the information provided in step <NUM> by the SFF. During the whole end user session while traffic modification is still valid, UPF reports these modifications.

SMF answers to the previous reporting of UPF.

When there is a UPF reselection, the new UPF, using the flow information stored in the UDR can maintain the changes performed in the traffic from the other UPF.

Turning now to other embodiments, <FIG> illustrate methods in various network function (NF) nodes of a communications network according embodiments herein. Generally, a communications network (or telecommunications network) may comprise any type of communications network, for example, the communications network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the communications network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, in some embodiments, the communications network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and/or other suitable <NUM>, <NUM>, <NUM>, or <NUM> standards; wireless local area network (WLAN) standards, such as the IEEE <NUM> standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

The communications network may comprise or interface with one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide-area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

The functionality of parts of the communications network may be divided into functions, such as the functions briefly described in the background section and <FIG> and <FIG> above. Briefly, a function comprises a functional building block with well-defined functional behaviors and external interfaces. Functions may be implemented in hardware or software, for example in a service based architecture. Functions may further be implemented in a distributed or cloud-based manner.

Generally, the method <NUM> as shown in <FIG> may be performed by a function of the communications network. For example, in some embodiments the method <NUM> may be performed by a policy control function, PCF. It will be appreciated that generally a function may comprise (or be comprised on) any network node, processing circuitry, virtual machine or other software or computational arrangement suitable for performing the function. Furthermore, it will be appreciated that other functions or nodes (e.g. having similar functionality to a PCF) may also perform the method <NUM> or parts of the method <NUM> thereof.

In some embodiments, the PCF may comprise the PCF as illustrated in any of <FIG>. <FIG> or <FIG> and it will be appreciated that the functionality described therein applies equally to the method <NUM>.

In more detail, the method <NUM> comprises a method in a policy control function, PCF, of moving a session (e.g. a traffic stream associated with a user application) from a SFC to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. In a first block <NUM> the method <NUM> comprises determining to update a second SF in the SFC for the session. In a second block <NUM>, the method <NUM> comprises determining a new SFC for the session comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF. In a third block <NUM>, the method <NUM> comprises sending a first message to a session management function, SMF, comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of the new SFC for the session.

In block <NUM>, determining to update a second SF in the SFC for the session, may comprise determining to add, modify, delete, or replace the second SF in the service function chain.

In block <NUM>, the method <NUM> comprises determining a new SFC for the session (e.g. to accommodate or initiate the update to the second SF), the new SFC comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF. For example, the PCF may determine that the first SF will not be included in the new SFC, and/or that the second SF may be included instead of the first SF. In such embodiments, a compensatory SF may also be added as one of the new SFs, wherein the compensatory SF is selected, or configured to ensure TCP ACK number consistency between the SFC and the new SFC in view of the packet modification performed by the first SF in the SFC.

This was described above, for signal <NUM> of <FIG> whereby a compensatory SF comprising a light proxy was added to the new SFC (SFC <NUM> of <FIG>) to compensate for removal of the first SF comprising the http proxy that was removed from the (default) SFC.

Thus, in some embodiments, the first SF may comprise a server proxy, such as a http proxy and one of the new SFs may comprise a light proxy. In some embodiments, the first SF may comprise a NAT and one of the new SFs may comprise a light proxy. In other words, a light proxy may be used to compensate for removal of a SF that modifies traffic in a session without losing TCP connection.

In some embodiments, a new SF for the new SFC may be selected by a PCF so as to keep the TCP seq. number correlation between the client and server.

In some embodiments, a network address translation NAT SF may be used, to perform remapping of a first IP to a second IP. In such an embodiment, the NAT server needs may save both IPs to maintain TCP connections.

In block <NUM> a first message is sent to the session management function, SMF <NUM>, comprising updated policy control rules for the session. The updated policy control rules comprise an indication of the new SFC for the session. Examples of the first message were described with respect to signals <NUM> of <FIG> and <NUM> of <FIG> above and the detail therein will be understood to apply equally to block <NUM>.

In some embodiments, the method <NUM> may be performed responsive to receiving a second message from the SMF <NUM> comprising a request for updated policy control rules for the session, wherein the second message further comprises the information related to the packet modification performed by the first SF. The second message may comprise, for example, signal <NUM> of <FIG> or signal <NUM> of <FIG> as described above and the detail therein will be understood to apply equally to the method <NUM> herein.

The method <NUM> is performed responsive to receiving a service continuity indicator for the session wherein the service continuity indicator indicates that the session should be maintained (for example, that the session is "Profile <NUM>" as described above).

The service continuity indicator is obtained by the PCF from a unified data repository, UDR, as part of a session establishment procedure for the session, for example, according to signal <NUM> of <FIG> described above.

Turning now to <FIG>, which illustrates a method <NUM> in a session management function, SMF <NUM>. Generally, the method <NUM> as shown in <FIG> may be performed by a function of the communications network. For example, in some embodiments the method <NUM> may be performed by a session management function or any other network function node configured to manage sessions in a communications network. It will be appreciated that generally a function may comprise (or be comprised on) any network node, processing circuitry, virtual machine or other software or computational arrangement suitable for performing the function. Furthermore, it will be appreciated that other functions or nodes (e.g. having similar functionality to a SMF) may also perform the method <NUM> or parts of the method <NUM> thereof.

In some embodiments, the SMF <NUM> may comprise the SMF <NUM> as illustrated in any of <FIG>, <FIG>, <FIG>, <FIG> or <FIG> and it will be appreciated that the functionality described therein applies equally to the method <NUM>.

Briefly, the method <NUM> comprises a method of moving a session associated with an SFC to a new SFC, whereby the SFC comprises a first SF that modifies packets in the session. In a first block <NUM> the method <NUM> comprises, responsive to receiving a third message from a user plane function, UPF, <NUM> associated with the session, the third message indicating that the first SF is modifying packets in the session, sending a second message to a policy control function, PCF, <NUM> comprising a request for updated policy control rules for the session, wherein the second message comprises information related to the modification being performed by the first SF. In a second block <NUM>, the method comprises receiving a first message from the PCF <NUM> comprising the updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session, wherein the new SFC comprises new SFs selected by the PCF <NUM>. In a third block <NUM>, the method comprises sending a fourth message to the UPF <NUM>, the fourth message comprising the updated policy control rules for the session.

In more detail, in block <NUM>, the third message may comprise a message such as signal <NUM> in <FIG>, signal <NUM> in <FIG>, or <NUM> in <FIG>. In some embodiments, the third message may thus comprise a Nsmf_ReporingReport message, as described above. In some embodiments, the third message may comprise one or more of a <NUM> tuple for the session; a new <NUM> tuple for the session; a TCP ACK number for the session; and a TCP Sequence number for the session. The SMF can use such information to provide a smooth handover from the SFC and the new SFC.

In some embodiments, the SMF <NUM> triggers the UPF <NUM> to commence traffic modification reporting. In other words, the method <NUM> may further comprise (e.g. preceding steps <NUM>, <NUM> and <NUM>) the SMF <NUM> sending a fifth message to the UPF <NUM>, the fifth message comprising an instruction to the UPF <NUM> to commence SF Traffic behaviour reporting. The fifth message may be sent (e.g. traffic modification reporting may be initiated) in response to the SMF <NUM> receiving a service continuity indicator for the session (e.g. of "profile <NUM>"), as described below. The fifth message may comprise, for example, a message such as the signal <NUM> in <FIG> as was described above. In some embodiments, the third message is therefore received from the UPF <NUM> in response to the fifth message.

In block <NUM>, the SMF <NUM> sends a second message to a policy control function, PCF, comprising a request for updated policy control rules for the session. The second message comprises information related to the modification being performed by the first SF. In some embodiments, the second message may comprise a message such as signal <NUM> in <FIG> above, or signal <NUM> of <FIG>. In some embodiments, the second message may comprise a Npcf message, for example.

In <NUM>, the SMF <NUM> receives a first message from the PCF <NUM>, comprising the updated policy control rules. In some embodiments, the first message may comprise the first message as described with respect to block <NUM> <FIG> as described above. Examples of the first message were described with respect to signals <NUM> of <FIG> and <NUM> of <FIG> above and the detail therein will be understood to apply equally to block <NUM>.

In block <NUM>, the SMF <NUM> sends a fourth message to the UPF <NUM> comprising updated policy control rules for the session. The fourth message in block <NUM> may comprise, for example, signal <NUM> of <FIG> or signal <NUM> of <FIG> as described above. Thus, in some embodiments, the fourth message may comprise a PFCP update request, comprising an app-ID and SFC ID that is to serve the session.

In some embodiments, the step of sending <NUM> a fourth message to the UPF <NUM>, the fourth message comprising the updated policy control rules for the session may further comprise: determining one or more detection rules (e.g. PDRs) and/or instruction rules (for example, such as different enforcement actions, e.g. traffic steering, QoS, Charging/Reporting through FARs, QERs, and/or URRs) based on the updated policy control rules for the session wherein at least one instruction rule comprises an indication of the new SFC; and sending the one or more detection rules and/or instruction rules to the UPF <NUM> in the fourth message.

The SMF <NUM> may also be involved in a registration procedure, such as was described with respect to <FIG> above whereby a UPF <NUM> may register its SFs with the SMF <NUM>. For example, in some embodiments, the method <NUM> may further comprise (e.g. preceding blocks <NUM>-<NUM>) receiving registration messages from a plurality of UPFs. Each registration message comprising registration information to register one or more SFs associated with the UPF, the registration information comprising: for each SF in the one or more SFs, i) an identifier for the respective SF and ii) an indication of any packet modifications performed by the respective SF. Each registration message may comprise a message such as the signal <NUM> or <NUM> of <FIG> above. For example, in some embodiments, each registration message comprises a PFCP Association Request. The PFCP Association request may, for example, be in the format shown in Annex I which describes different Octet/Bits corresponding to different indications of supported features. PFCP association request could reuse this to indicate that it is allowed in UPF.

In some embodiments, the method <NUM> may comprise determining a UPF for a session. For example, the SMF <NUM> may determine an appropriate UPF for the session as part of a session establishment procedure. The SMF <NUM> may use the registration messages described above, to select, from a plurality of UPFs, the UPF to associate with the session.

The method <NUM> comprises receiving from the PCF <NUM>, as part of a session establishment procedure for the session, an indication of a service continuity indicator for the session. As described above, the service continuity indicator may indicate one of the following: that the session can be restarted; that the session can be broken and continued; or that the session should be continuous. In the invention as claimed, the service continuity indicator indicates that the session should be maintained. The service continuity indicator is obtained from the PCF <NUM> (via the UDR) according to signal <NUM> of <FIG>. The method <NUM> may further comprise sending the service continuity indicator to the UPF <NUM> associated with the session in a PFCP Session Establishment Request or a PFCP Session Modification Request as part of a session establishment procedure for the session. This was illustrated above in signal <NUM> of <FIG>. A possible format of such a PFCP Session Establishment Request or a PFCP Session Modification Request according to some examples herein is given in Annex II.

The SMF <NUM> may use the service continuity indicator when selecting a UPF <NUM> for the session. For example, if the service continuity indicator indicates that that the session should be continuous, the method <NUM> may comprise selecting, from the plurality of UPFs, a UPF with traffic modification capability as the UPF associated with the session.

Turning now to <FIG>, there is a method in a user plane function, UPF, according to some embodiments herein. Generally, the method <NUM> as shown in <FIG> may be performed by a function of the communications network. For example, in some embodiments the method <NUM> may be performed by a user plane function or any other network function node which performs functions similar to a user plane function. It will be appreciated that generally a function may comprise (or be comprised on) any network node, processing circuitry, virtual machine or other software or computational arrangement suitable for performing the function. Furthermore, it will be appreciated that other functions or nodes (e.g. having similar functionality to a UPF) may also perform the method <NUM> or parts of the method <NUM> thereof.

In some embodiments, the UPF may comprise the UPF <NUM> as illustrated in any one of <FIG>, <FIG>, <FIG>, <FIG> or <FIG> and it will be appreciated that the functionality described therein applies equally to the method <NUM>.

Briefly, the method <NUM> comprises a method in a user plane function, UPF, of moving a session from an SFC to a new SFC. The SFC comprises a first SF that modifies packets in the session. In a first block <NUM>, the method <NUM> comprises sending a third message to a session management function, SMF <NUM>, the third message indicating that the first SF is modifying packets in the session. In a second block <NUM>, the method comprises receiving from the SMF <NUM> a fourth message, the fourth message comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session. In a third block <NUM> the method comprises moving the session from the SFC to the new SFC, based on the received updated policy control rules.

In block <NUM>, the third message may comprise a message such as the signal <NUM> in <FIG> or the message <NUM> in <FIG>. In some embodiments, the step of sending a third message to the SMF <NUM> may be performed responsive to receiving a fifth message from the SMF <NUM>, the fifth message comprising an instruction to the UPF <NUM> to commence SF Traffic behaviour reporting. The fifth message was described above, with respect to the method <NUM> and the detail therein will be understood to apply equally to the method <NUM>. In some embodiments, the fifth message comprises a signal such as signal <NUM> in <FIG>. As noted above, in some embodiments, the fifth message comprises one or more of a <NUM> tuple for the session, a new <NUM> tuple for the session, a TCP ACK number for the session and a TCP Sequence number for the session.

In block <NUM>, the UPF <NUM> receives updated policy control rules for the session in a fourth message. The fourth message may comprise a message such as the signal <NUM> in <FIG> or the signal <NUM> in <FIG>. The updated policy control rules may be in the form of updated detection rules (e.g. PDRs) and/or instruction rules (for example, such as different enforcement actions, e.g. traffic steering, QoS, Charging/Reporting through FARs, QERs, and/or URRs).

In block <NUM>, the method may comprise moving the session from the SFC to the new SFC based on the updated policy control rules. The session may be moved, for example, using a signal such as the signal <NUM> of <FIG> or the signal <NUM> in <FIG>.

In some embodiments the step of moving the session from the SFC to the new SFC in block <NUM> further comprises classifying packets comprised in the session using heuristic analysis and determining from the updated policy control rules that the session should be moved to the new SFC based on the results of the step of classifying packets. In other words, a session may be served by an (initial or default) SFC whilst a heuristic algorithm classifies packets in the session. Once the heuristic algorithm has classified the packets, the UPF <NUM> may use the received updated policy control rules to move the session to the new SFC. Because the new SFC is preconfigured for the session, based on the reported traffic modifications that were being performed on the original SFC, the session can be moved to the new SFC seamlessly, and without losing TCP connection.

As described above with respect to <FIG>, in some embodiments, the method <NUM> may be preceded by a registration procedure whereby the UPF <NUM> registers SFs available to it with a SMF <NUM>. For example, the method <NUM> may further comprise (for example, preceding the steps <NUM>, <NUM> and <NUM>) sending a registration message to the SMF <NUM>, the registration message comprising information to register one or more SFs associated with the UPF <NUM>, the information comprising: for each SF in the one or more SFs, i) an identifier for the respective SF and ii) an indication of any packet modifications performed by the respective SF. The registration message may, for example, be of the format of signal <NUM> or <NUM> in <FIG>. If the UE registers itself in this way, the SMF <NUM> may better select an appropriate UPF for any given session (e.g. an appropriate UE may be selected at session establishment). In some embodiments, the registration message comprises a PFCP Association Request.

The method <NUM> comprises the UPF <NUM> receiving a service continuity indicator associated with the session in a PFCP Session Establishment Request or a PFCP Session Modification Request as part of a session establishment procedure for the session, wherein the service continuity indicator indicates that the session should be maintained.

The method may further comprise routing session traffic from the SFC to the new SFC, based on the service continuity indicator. For example, if the service continuity indicator is "profile <NUM>" as described above, the UPF <NUM> may determine that the service should not be interrupted and should thus be routed to the new SFC to ensure uninterrupted service. The service continuity procedure was described in detail above and the details therein will be understood to apply equally to the method <NUM>.

Turning now to other embodiments, <FIG> illustrates a network function (NF) node <NUM> comprising processing circuitry (or logic) <NUM>. It will be appreciated that the NF node <NUM> may comprise one or more virtual machines running different software and/or processes. The NF node <NUM> may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

In some embodiments, the NF node <NUM> may comprise a Policy Control function (PCF) as described above. The processing circuitry <NUM> controls the operation of the PCF <NUM> and can implement the method <NUM> described herein in relation to a PCF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the PCF <NUM> in the manner described herein. In some implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method <NUM> described herein in relation to the PCF <NUM>.

The NF node <NUM> may be configured for moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. Briefly, the processing circuitry <NUM> of the NF node <NUM> may be configured to: determine to update a second SF in the SFC for the session; determining a new SFC for the session comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF; and send a first message to a session management function, SMF, comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of the new SFC for the session.

In some embodiments, the NF node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the NF <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the NF <NUM> can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of NF <NUM> may be configured to control the communications interface <NUM> of the NF <NUM> to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the NF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the NF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the NF <NUM> to perform any embodiment of the method <NUM> described herein. Alternatively or in addition, the memory <NUM> of the NF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the NF <NUM> may be configured to control the memory <NUM> of the NF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

In some embodiments, the NF node <NUM> may comprise a Session Management Function (SMF) as described above. The processing circuitry <NUM> controls the operation of the SMF <NUM> and can implement the method <NUM> described herein in relation to a SMF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the SMF <NUM> in the manner described herein. In some implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method <NUM> described herein in relation to the SMF <NUM>.

The NF node <NUM> may be configured for moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. Briefly, the processing circuitry <NUM> of the NF node <NUM> may be configured to: responsive to receiving a third message from a user plane function, UPF, associated with the session, the third message indicating that the first SF is modifying packets in the session, sending a second message to a policy control function, PCF, comprising a request for updated policy control rules for the session, wherein the second message comprises information related to the modification being performed by the first SF; receive a first message from the PCF comprising the updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session, wherein the new SFC comprises new SFs selected by the PCF; and send a fourth message to the UPF, the fourth message comprising the updated policy control rules for the session.

Optionally, the NF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the NF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the NF <NUM> to perform any of the embodiments of method <NUM> described herein. Alternatively or in addition, the memory <NUM> of the NF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the NF <NUM> may be configured to control the memory <NUM> of the NF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

In some embodiments, the NF node <NUM> may comprise a User Plane Function (UPF) as described above. The processing circuitry <NUM> controls the operation of the UPF <NUM> and can implement the method <NUM> described herein in relation to a UPF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the UPF <NUM> in the manner described herein. In some implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method <NUM> described herein in relation to the UPF <NUM>.

The NF node <NUM> may be configured for moving a session from a service function chain, SFC to a new SFC, wherein the SFC comprises a first SF that modifies packets in the session. Briefly, the processing circuitry <NUM> of the NF node <NUM> may be configured to: send a third message to a session management function, SMF, the third message indicating that the first SF is modifying packets in the session; receive from the SMF a fourth message, the fourth message comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of a new SFC for the session; and move the session from the SFC to the new SFC, based on the received updated policy control rules.

Turning to other embodiments, there is also a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform any of the embodiments of the methods <NUM>, <NUM> or <NUM> described herein.

A single processor or other unit may fulfil the functions of several items recited in the claims.

Claim 1:
A method in a policy control function, PCF, of moving a session from a service function chain, SFC, to a new SFC, wherein the SFC comprises a first service function, SF, that modifies packets in the session, the method comprising:
- determining (<NUM>) to update a second SF in the SFC for the session;
- determining (<NUM>) a new SFC for the session comprising new SFs, wherein the new SFs are selected based on the determined update to the second SF and information related to the packet modification performed by the first SF; and
- sending (<NUM>) a first message to a session management function, SMF, comprising updated policy control rules for the session, wherein the updated policy control rules comprise an indication of the new SFC for the session;
wherein the method is performed responsive to receiving a service continuity indicator for the session wherein the service continuity indicator indicates that the session should be maintained; and
wherein the service continuity indicator is obtained by the PCF from a unified data repository, UDR, as part of a session establishment procedure for the session.