Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), Frequency Division Duplex (FDD), Frequency Division Multiple Access (FDMA), Long Term Evolution (LTE), New Radio (NR), Very Large Scale Integration (VLSI), Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM or Flash Memory), Compact Disc Read-Only Memory (CD-ROM), Local Area Network (LAN), Wide Area Network (WAN), Personal Digital Assistant (PDA), User Equipment (UE), Uplink (UL), Evolved Node B (eNB), Next Generation Node B (gNB), Downlink (DL), Central Processing Unit (CPU), Graphics Processing Unit (GPU), Field Programmable Gate Array (FPGA), Dynamic RAM (DRAM), Synchronous Dynamic RAM (SDRAM), Static RAM (SRAM), Liquid Crystal Display (LCD), Light Emitting Diode (LED), Organic LED (OLED), Orthogonal Frequency Division Multiplexing (OFDM), Radio Resource Control (RRC), Reference Signal (RS), Single Carrier Frequency Division Multiple Access (SC-FDMA), Time-Division Duplex (TDD), Time Division Multiplex (TDM), User Entity/Equipment (Mobile Terminal) (UE), Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX), Protocol Data Unit (PDU), PDU Session Anchor (PSA), data network (DN), Service and Session Continuity (SSC), Data Network (DN), DN Access Identifier (DNAI), uplink classifier (UL classifier or ULCL), User Plane Function (UPF), Branching Point (BP), Session Management Function (SMF), Policy Control Function (PCF), Network Exposure Function (NEF), Application Function (AF), Unified Data Repository (UDR), <NUM> core (5GC), Policy and Charging Control (PCC).

A PDU session is used for exchanging PDU packets between UE and DN. In order to support selective traffic routing to the DN or to support SSC mode <NUM>, a single PDU session may be associated with multiple PDU session anchors (PSAs), as described in 3GPP TS <NUM> and <NUM>.

To support multiple PSAs, uplink classifier (UL classifier or ULCL) or IPv6 multi-homing is necessary. The usage of UL classifier functionality for a PDU session and the usage of an IPv6 multi-homing for a PDU session are described in clause <NUM>. <NUM> of 3GPP TS <NUM>. The forwarding tunnel processing for session continuity upon ULCL relocation are described in clause <NUM>. <NUM> of 3GPP TS <NUM>.

<FIG> illustrates an architecture for the ULCL. An ULCL is implemented in a UPF (shown as UPF Uplink Classifier in <FIG>). The ULCL may apply filtering rules (e.g. to examine the destination IP address or Prefix of UL IP packets sent by the UE) and determine how the packets should be routed to different PDU session anchors. The PDU session anchor (PSA) is also implemented in a UPF (shown as UPF PDU session anchor <NUM> and UPF PDU session anchor <NUM> in <FIG>). Each PDU session anchor may provide a different access to the same DN (deployed in the same or different positions). The data packets from UE will be transmitted to ULCL (UPF Uplink Classifier) via AN, and routed by the ULCL to different PSAs (e.g. UPF PDU session anchor <NUM> and UPF PDU session anchor <NUM> in <FIG>), and transmitted to the DN via different PSAs. Note that two "DN"s are illustrated in <FIG>. They are the same DN deployed at different locations. The usage of ULCL applies to PDU session type of IPv4 or IPv6 or IPv4v6. Incidentally, when data packets are received from different PSAs, the ULCL merges the received packets and transmitted the merged data packets to the UE via the AN.

In case of PDU session type of IPv6, multi-homed PDU session is also supported as illustrated in <FIG>. A PDU session may be associated with multiple IPv6 prefixes. The data packets with different IPv6 prefixes will be branched out at a common UPF (which may be referred to as a Branching Point (BP), shown as "UPF Branching Point" in <FIG>) to different PDU session anchors (e.g. PDU session anchor <NUM> and UPF PDU session anchor <NUM> in <FIG>). The branching is made based on source prefixes of the PDU packets (which may be selected by the UE based on routing information and preferences received from the network).

In the above usage of ULCL or Branching Point, when the ULCL and/or the BP and/or the PSAs are to be changed (e.g. relocated) due to various reasons (e.g. UE mobility, load balance etc.), there is an issue of service continuity for the offload traffic via the additional PSA. Some data packets for the PDU session may be lost during the relocation of the ULCL and/or the BP and/or the PSAs. For example, when a PSA and/or a ULCL and/or a BP is relocated, the user plane path for the offload traffic via the additional PSA to a DN will be relocated. Source PSA and/or source ULCL and/or source BP may be released before completion of data transportation thereon. In this condition, some data transportation may be lost, which means that service continuity (or seamless service continuity) for the offload traffic via the additional PSA is not fulfilled. Some application may require seamless data transportation, i.e. no data loss is allowed. This can be achieved by releasing source PSA and/or source ULCL and/or source BP after completion of data transportation thereon, which may occupy resources thereon. On the other hand, other application may not be sensitive to data loss. It is preferable to release resources on source PSA and/or source ULCL and/or source BP as early as possible. The present application aims to provide a method to improve the flexibility of supporting service continuity (or seamless service continuity) for the offload traffic via the additional PSA. For the seamless service continuity used in this application other terms like (seamless) session continuity upon additional PSA relocation, (seamless)session continuity upon local PSA relocation, etc may be used.

Claim <NUM> defines an apparatus. Claim <NUM> defines a method.

Method and apparatus for improving the flexibility of supporting service continuity are disclosed.

Understanding that these drawings depict only some embodiments, and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:.

As will be appreciated by one skilled in the art that certain aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may generally all be referred to herein as a "circuit", "module" or "system". Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine-readable code, computer readable code, and/or program code, referred to hereafter as "code".

Certain functional units described in this specification may be labeled as "modules", in order to more particularly emphasize their independent implementation. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.

Nevertheless, the executables of an identified module need not be physically located together, but, may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose for the module.

Indeed, a module of code may contain a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. This operational data may be collected as a single data set, or may be distributed over different locations including over different computer readable storage devices.

The computer readable storage medium may be a storage device storing code. The storage device may be, for example, but need not necessarily be, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

A non-exhaustive list of more specific examples of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash Memory), portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Code for carrying out operations for embodiments may include any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages. The code may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the very last scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Furthermore, described features, structures, or characteristics of various embodiments may be combined in any suitable manner. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid any obscuring of aspects of an embodiment.

Aspects of different embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. This code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the schematic flowchart diagrams and/or schematic block diagrams for the block or blocks.

The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices, to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function specified in the schematic flowchart diagrams and/or schematic block diagrams block or blocks.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices, to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code executed on the computer or other programmable apparatus provides processes for implementing the functions specified in the flowchart and/or block diagram block or blocks.

The description of elements in each Figure may refer to elements of proceeding figures.

The present application aims to improve the flexibility of supporting service continuity. This is achieved by introducing a parameter to indicate whether the service continuity for offload traffic is supported or not. When service continuity for offload traffic is supported for a relocation of PSAs and/or ULCLs and/or BPs, a seamless user data transportation should be fulfilled, that is, no data loss is allowed for the relocation of PSAs and/or ULCLs and/or BPs. On the other hand, when service continuity for offload traffic is not supported for a relocation of PSAs and/or ULCLs and/or BPs, data loss is allowed. The PSA mentioned is the additional PSA for transmitting offload traffic. Detailed embodiments are described in detail.

<FIG> illustrates a method of relocating local PSA for a PDU session according to a first embodiment. <FIG> illustrate the user plane path change. In the first embodiment, uplink classifier (ULCL) is used for routing data packets to different PSAs and merging data packets received from different PSAs.

As shown in <FIG>, various entities are included. The UE is connected via an AN (access network, not shown in <FIG>) to the ULCL. The source local PSA is UPF1; the target local PSA is UPF2; the central PSA is C-UPF. SMF is a network function to perform the process. PCF(s), UDR, NEF and AF, that are involved in supporting service continuity, will be discussed later.

In step <NUM>, a PDU session is established from the UE with the C-UPF to access a central DN (shown as C-DN in each of <FIG>). The central DN is a central deployment of a DN. The central DN is not shown in <FIG>. As described earlier with reference to <FIG>, the UE is connected to UPF via the AN. The AN is omitted in <FIG>. Incidentally, if the AN cannot connect the C-UPF directly, one or more intermediate UPFs may be present between the AN and the C-UPF. The connection among the UE, the AN, the C-UPF and the C-DN is shown in <FIG>.

In step <NUM>, the AF may request to influence traffic routing for PDU sessions. The AF request influences UPF selection (or reselection) and allows routing user traffic to a local access to a data network (identified by a DNAI). The AF request includes a parameter "Application Relocation Possibility", among other parameters. The parameter "Application Relocation Possibility" indicates whether an application can be relocated once a location of the application is selected by the 5GC. According to the present application, a new parameter "service continuity for offload traffic" for indicating whether service continuity for offload traffic is supported or not may be introduced into the parameters of the AF request. As an alternative to be an independent parameter, the indication on whether service continuity for offload traffic is supported or not may be implemented as an extension to the existing parameter "Application Relocation Possibility". For example, when application relocation is possible, the parameter "Application Relocation Possibility" may be extended to "Application relocation is possible with Service continuity for offload traffic supported or not supported".

In step <NUM>, the AF request is sent to PCF directly or via NEF. The PCF determines if existing PDU sessions are potentially impacted by the AF request. For each of the existing PDU Sessions, the PCF updates the SMF with corresponding new PCC rule(s) by invoking "Npcf_SMPolicyControl_UpdateNotify" service operation. The PCC rule, that is transmitted by the PCF and received by the SMF, contains a traffic steering control information per AF request which includes the indication on whether service continuity for offload traffic is supported or not. Accordingly, the indication on whether service continuity for offload traffic is supported or not, either as an independent parameter "service continuity for offload traffic" or as an extension to the existing parameter "Application Relocation Possibility" contained in the AF request, can be known by the SMF by updating the PCC rule(s).

As a whole, in steps <NUM> and <NUM>, the AF request including at least an indication on whether service continuity for offload traffic is supported or not is sent to the PCF and the related PCC rule(s) is/are updated to the SMF. The service continuity for offload traffic (supported or not supported) may influence traffic to be routed for existing or future PDU sessions. The information from the AF request including at least the indication on whether service continuity for offload traffic is supported or not may be also transmitted and stored in UDR. When a future session is established, the SMF may obtain the information from the information stored in the UDR and know the indication on whether service continuity for offload traffic is supported or not. According to the first embodiment, when the service continuity for offload traffic is supported, no data loss is allowed for the offload traffic of the PDU sessions when the PSA and/or the ULCL are relocated. When the service continuity for offload traffic is not supported, some data loss is allowed for offload traffic of the PDU sessions when the PSA and/or the ULCL are relocated. Incidentally, the service continuity for offload traffic may be the service continuity for local offload traffic.

In step <NUM>, based on network environment and policy, the SMF decides that some selective traffic should be routed to the DN via local PSA. Accordingly, for the PDU session, the SMF establishes UPF1 for a local access to a local DN (shown as L-DN in each of <FIG>) for the PDU session. The local DN is a local deployment of the DN.

In step <NUM>, the SMF establishes a ULCL for the PDU session to support data transportation through multiple PSAs (i.e. UPF1 and C-UPF). The ULCL routes the data packets from the UE via the AN to different PSAs (C-UPF or UPF1). The ULCL also merges the data packets received from different PSAs (C-UPF or UPF1) and sends the merged data packets to the UE via the AN.

In step <NUM>, the C-UPF is updated so that the C-UPF is connected to the ULCL for the PDU session.

As a whole, in steps <NUM> to <NUM>, a local PSA (i.e. UPF1) as well as a ULCL are updated for the PDU session, so that the UE can access the DN (L-DN) with a new user plane path through UPF1. <FIG> shows the connection among the UE, the AN, the ULCL, the C-UPF, the C-DN, the UPF1 and the L-DN.

In step <NUM>, the SMF decides to relocate the local PSA (e.g. change from UPF1 to UPF2). The decision may be triggered by UE mobility and/or load balance. When the local PSA is relocated, a DNAI change may take place or not.

In step <NUM>, the SMF reports the PSA change (may be represented by DNAI change) to the AF, e.g. by invoking "Nsmf_EventExposure_Notify" service operation.

In step <NUM>, the AF acknowledges the report of the PSA change with related information (e.g. smf_EventExposure_AppRelocationInfo). The related information sent to the SMF may include indication on whether service continuity for offload traffic is supported or not for the PDU session.

As described above, the indication on whether service continuity for offload traffic is supported or not (for all existing PDU sessions) may be indicated in steps <NUM> and <NUM>. If the indication on whether service continuity for offload traffic is supported or not for the PDU session is received in step <NUM>, the SMF uses the indication received in step <NUM>. Otherwise, the SMF uses the information received in step <NUM>.

In step <NUM>, the SMF decides whether service continuity is supported during the PSA relocation from UPF1 to UPF2 according to the information received in step <NUM> and/or in step <NUM>.

In step <NUM>, the SMF establishes the UPF2 for the PDU session for the local access to the L-DN.

In step <NUM>, the SMF updates the ULCL for the PDU session. Two different situations may occur.

In a first situation, ULCL is relocated. That is, a new ULCL (e.g. ULCL2) is established for the PDU session so that UE is connected to UPF2 via the new ULCL (ULCL2). Incidentally, UE is usually connected via a new access network (e.g. AN2) to the ULCL2. In this condition, AN is not used in the PDU session.

<FIG> shows the connection among the UE, the ULCL, the C-UPF, the C-DN, the UPF1, the AN2, the ULCL2, the UPF2 and the L-DN at this time.

After the ULCL2 is established for the PDU session, the C-UPF is updated to connect to the ULCL2.

When service continuity for offload traffic is supported, steps <NUM> and <NUM> are performed.

In step <NUM>, a forwarding tunnel is established between the ULCL and the ULCL2. In consideration that the C-UPF is updated to connect to the ULCL2, the DL data packets sent to the ULCL can be forwarded to the ULCL2 using the forwarding tunnel.

In step <NUM>, the forwarding tunnel is released based on policy. For example, the policy may be one of:.

In addition, the source PSA (UPF1) may send one or more "end marker" packets to the ULCL to indicate the last DL data packets transmitted from the UPF1 to the ULCL. The ULCL forwards the end marker packets to ULCL2 using the forwarding tunnel. If ULCL (e.g. ULCL2) supports reordering function, the "end marker" packets assist the reordering function at the ULCL2 to reorder the packets from the UPF1 through the forwarding tunnel and the packets from the UPF2 and the C-UPF. After the ULCL2 receives the end marker packets, the forwarding tunnel may be released.

As a whole, the forwarding tunnel ensures no data loss during the PSA relocation from UPF1 to UPF2 (as well as the relocation from ULCL to ULCL2).

In step <NUM>, the SMF releases the UPF1 for the PDU session. The ULCL is also released for the PDU session. <FIG> shows the connection among the UE, the AN2, the ULCL2, the C-UPF, the C-DN, the UPF2 and the L-DN at this time.

When service continuity for offload traffic is not supported, steps <NUM> and <NUM> are not performed. The SMF may release the UPF1 as well as the ULCL for the PDU session immediately after establishing UPF2 and ULCL2 for the PDU session and updating the C-UPF to connect to the ULCL2. That is, the connection shown in <FIG> will be changed directly to that shown in <FIG>. In this condition, some data may be lost.

In step <NUM>, in a second situation of updating the ULCL, the UE may connect to the UPF2 still with the ULCL. That is, the ULCL is not relocated. <FIG> shows the connection among the UE, the AN, the ULCL, the C-UPF, the C-DN, the UPF1, the UPF2 and the L-DN in the second situation at this time.

In the second situation, when service continuity for offload traffic is supported, a step 312a is performed. In the step 312a, the packets that had been transmitted to UPF1 are transmitted to the ULCL. In particular, one or more "end marker" packets may be sent to the ULCL to indicate the last DL data packets transmitted from the UPF1 to the ULCL.

Similar to the first situation, in step <NUM>, the SMF releases the UPF1 for the PDU session. <FIG> shows the connection among the UE, the AN, the ULCL, the C-UPF, the C-DN, the UPF2 and the L-DN at this time.

As whole, depending on whether service continuity for offload traffic is supported or not, the SMF performs the PSA relocation differently. When service continuity for offload traffic is determined as being supported in step <NUM>, the steps <NUM> and <NUM> or the step 312a are performed to ensure no data loss. Incidentally, as the information including the indication on whether the service continuity for offload traffic is supported or not is received in step <NUM>, the determination made in the step <NUM> may be at least partially performed in step <NUM> (i.e. determining whether service continuity for offload traffic is supported or not according to the information received in step <NUM>). That is, when the related information received in the step <NUM> does not include the indication on whether service continuity for offload traffic is supported or not, the determination made in the step <NUM> applies. When service continuity for offload traffic is determined as not being supported in step <NUM>, the steps <NUM> and <NUM> or the step 312a are not performed (that is, after performing the step <NUM>, step <NUM> is performed).

In the first embodiment, the UE is not aware of the relocation of PSAs.

<FIG> illustrates a method of relocating local PSA for a PDU session according to a second embodiment. In the second embodiment, branching point (BP) is used for routing data packets to different PSAs and merging data packets received from different PSAs.

As shown in <FIG>, compared with <FIG>, the entities in the second embodiment differ from those in the first embodiment in that the ULCL in <FIG> is replaced with BP in <FIG>. The user plane path change according to the second embodiment is similar to that according to the first embodiment as shown in <FIG>, except that the ULCL (as well as ULCL2) will be replaced with BP (as well as BP2). Therefore, <FIG> may roughly reflect the user plane path change according to the second embodiment.

Steps <NUM>-<NUM> are similar to steps <NUM>-<NUM>.

In particular, in step <NUM>, a PDU session is established from the UE with the C-UPF to access a central DN. The SMF notifies the UE of the availability of a IPv6 prefix (IP@C) assigned for C-UPF, e.g. by using an IPv6 Router Advertisement message. The UE will use IP@C to send data packets through the C-UPF.

In step <NUM>, the AF may request to influence traffic routing for PDU sessions. The AF request may include a new parameter "Service continuity for offload traffic" for indicating whether service continuity for offload traffic is supported or not. Alternatively, the indication on whether service continuity for offload traffic is supported or not may be implemented as an extension to the existing parameter "Application Relocation Possibility".

In step <NUM>, the AF request may be sent to PCF directly or via NEF. The PCF updates the SMF with new PCC rule(s). The PCC rule contains a traffic steering control information per AF request which includes the indication on whether service continuity for offload traffic is supported or not. According to the second embodiment, when the service continuity for offload traffic is supported, no data loss is allowed for the offload traffic of the PDU sessions when the PSA and/or the BP are relocated. When the service continuity for offload traffic is not supported, some data loss is allowed for the offload traffic of the PDU sessions when the PSA and/or the BP are relocated. Incidentally, the service continuity for offload traffic may be the service continuity for local offload traffic.

In step <NUM>, the SMF decides that some selective traffic should be routed to the DN via local PSA. Accordingly, for the PDU session, the SMF establishes UPF1 for a local access a local DN (i.e. local deployment of the DN, referred to as L-DN). In particular, the SMF notifies the UE of the availability of a IPv6 prefix (IP@<NUM>) assigned for UPF1, e.g. by using an IPv6 Router Advertisement message. The UE will use IP@<NUM> to send data packets through the UPF1.

In step <NUM>, the SMF establishes a BP for the PDU session to support data transmissions through multiple PSAs (i.e. UPF1 and C-UPF).

In step <NUM>, the C-UPF is updated so that the C-UPF is connected to the BP.

In particular, the data packets with IPv6 prefix IP@C are routed by the BP to the C-UPF and the data packets with IPv6 prefix IP@<NUM> are routed by the BP to the UPF1.

In step <NUM>, the SMF decides to relocate the local PSA (e.g. change from UPF1 to UPF2) triggered by UE mobility and/or load balance.

In step <NUM>, the SMF reports the PSA change (indicating the relocation of the local PSA) to the AF.

In step <NUM>, the AF acknowledges the report of the PSA change with related information that may include indication on whether service continuity for offload traffic is supported or not. The related information is sent to the SMF.

In step <NUM>, the SMF decides whether service continuity is supported for the relocation from UPF1 to UPF2 according to the information received in step <NUM> and/or in step <NUM>.

In step <NUM>, the SMF establishes the UPF2 for the PDU session for local access to the L-DN.

In step 510a, the SMF notifies the UE of the availability of a IPv6 prefix (IP@<NUM>) assigned for UPF2, e.g. by using an IPv6 Router Advertisement message. The UE will use IP@<NUM> to send data packets through the UPF2.

In step 510b, the SMF sends a second Router Advertisement to the UE via the old PSA (UPF1) with the old prefix (IP@<NUM>) to set preferred lifetime for IP@<NUM>. In particular, if service continuity for offload traffic is supported in relocation of the local PSA, the preferred lifetime field is set to zero, and a value is set to the valid lifetime field according to RFC <NUM>. The valid lifetime value indicates the time period during which the SMF is willing to keep the old prefix (IP@<NUM>). On the other hand, if service continuity for offload traffic is not supported in relocation of the local PSA, the preferred lifetime field and the valid lifetime field are both set to zero according to RFC <NUM>. When the valid lifetime value is set to zero, the old prefix (IP@<NUM>) will become invalid immediately.

In step <NUM>, the SMF updates the BP for the PDU session. Two different situations may occur.

In a first situation, BP is relocated. That is, a new BP (e.g. BP2) is established for the PDU session so that UE is connected to UPF2 via the new BP (BP2). Incidentally, UE is usually connected via a new access network (e.g. AN2) to the BP2. In this condition, AN is not used in the PDU session.

After the BP2 is established for the PDU session, the C-UPF is updated to connect to the BP2.

In step <NUM>, a forwarding tunnel is established between the BP and the BP2. In consideration that the C-UPF is updated to connect to the BP2, the DL data packets sent to the BP can be forwarded to the BP2 using the forwarding tunnel.

In step <NUM>, the forwarding tunnel may be released based on policy. For example, the policy may be one of:.

In addition, the source PSA (UPF1) may send one or more "end marker" packets to the BP to indicate the last DL data packets transmitted from the UPF1 to the BP. The BP forwards the end marker packets to BP2 using the forwarding tunnel. If BP (e.g. the BP2) supports reordering function, the "end marker" packets assist the reordering function at the BP2 to reorder the packets from the UPF1 through the forwarding tunnel and the packets from the UPF2 and the C-UPF. After the BP2 receives the end marker packets, the forwarding tunnel may be released.

In step <NUM>, the SMF releases the UPF1 for the PDU session. The BP is also released for the PDU session.

When service continuity for offload traffic is not supported, steps <NUM> and <NUM> are not performed. The SMF may release the UPF1 as well as the BP for the PDU session immediately after establishing UPF2 and BP2 for the PDU session and updating the C-UPF to connect to the BP2.

In step <NUM>, in a second situation of updating the BP, the UE may connect to the UPF2 still with the BP. That is, the BP is not relocated.

In the second situation, when service continuity for offload traffic is supported, a step 512a is performed. In the step 512a, the packets that had been transmitted to UPF1 are transmitted to the BP within the valid lifetime value. In particular, one or more "end marker" packets may be sent to the BP to indicate the last DL data packets transmitted from the UPF1 to the BP.

Similar to the first situation, in step <NUM>, the SMF releases the UPF1 for the PDU session.

As a whole, depending on whether service continuity for offload traffic is supported or not, the SMF performs the PSA relocation differently. When service continuity for offload traffic is determined as being supported in step <NUM>, the steps <NUM> and <NUM> or the step 512a are performed to ensure no data loss. Incidentally, as the information including the indication on whether the service continuity for offload traffic is supported or not is received in step <NUM>, the determination made in the step <NUM> may be at least partially performed in step <NUM> (i.e. determining whether service continuity for offload traffic is supported or not according to the information received in step <NUM>). That is, when the related information received in the step <NUM> does not include the indication on whether service continuity for offload traffic is supported or not, the determination made in the step <NUM> applies. When service continuity for offload traffic is determined as not being supported in step <NUM>, the steps <NUM> and <NUM> or the step 512a are not performed (that is, after performing the step <NUM>, step <NUM> is performed).

<FIG> is a schematic block diagram illustrating apparatuses according to one embodiment.

Referring to <FIG>, the network function (e.g. SMF) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method. The memories are connected with the processors to store various pieces of information for driving the processors. The transceivers are connected with the processors to transmit and/or receive message or information. Needless to say, the transceiver may be implemented as a transmitter to transmit the information and a receiver to receive the information.

The memories may be positioned inside or outside the processors and connected with the processors by various well-known means.

In the embodiments described above, the components and the features of the embodiments are combined in a predetermined form. Each component or feature should be considered as an option unless otherwise expressly stated. Each component or feature may be implemented not to be associated with other components or features. Further, the embodiment may be configured by associating some components and/or features. The order of the operations described in the embodiments may be changed. Some components or features of any embodiment may be included in another embodiment or replaced with the component and the feature corresponding to another embodiment. It is apparent that the claims that are not expressly cited in the claims are combined to form an embodiment or be included in a new claim.

The embodiments may be implemented by hardware, firmware, software, or combinations thereof. In the case of implementation by hardware, according to hardware implementation, the exemplary embodiment described herein may be implemented by using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, and the like.

Claim 1:
A session management function, SMF, for wireless communication, comprising:
at least one memory; and
at least one processor coupled with the at least one memory and configured to cause the SMF to:
receive (<NUM>), from a policy control function, PCF, a policy and charging control, PCC, rule containing a traffic steering control information per application function, AF, request which includes an indication indicating that service continuity for offload traffic is supported; and
perform (<NUM>) a protocol data unit session anchor, PSA, relocation based on the traffic steering control information, wherein, a source PSA is relocated to a target PSA, wherein the source PSA is connected to a source uplink classifier, ULCL, or branching point, BP, and the target PSA is connected to a target ULCL or BP, and a forwarding tunnel is established between the source ULCL or BP and the target ULCL or BP.