WO2024074019A1

WO2024074019A1 - Ue group management for local switch via ran node

Info

Publication number: WO2024074019A1
Application number: PCT/CN2023/085511
Authority: WO
Inventors: Haiyan Luo; Mingzeng Dai; Congchi ZHANG
Original assignee: Lenovo (Beijing) Ltd.
Priority date: 2023-03-31
Filing date: 2023-03-31
Publication date: 2024-04-11

Abstract

Method and apparatus for UE group management are disclosed. In one embodiment, session management function (SMF) comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to determine to perform local switch via RAN node for a PDU session or a combination of the PDU session and QoS flow (s), wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QFI; and transmit, via the transceiver, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s).

Description

UE GROUP MANAGEMENT FOR LOCAL SWITCH VIA RAN NODE

FIELD

The subject matter disclosed herein generally relates to wireless communications, and more particularly relates to UE group management for local switch via Radio Access Network (RAN) node.

BACKGROUND

Figure 1 illustrates a principle of motion control. A motion controller (e.g., controller or master, which is referred to as C/M hereinafter) controls devices (e.g., sensors and/or actuators, which are referred to as S/A hereinafter) . The sensors return actual values to the motion controller. Transfer interval is defined as the time difference between two consecutive transfers of application data from an application via the service interface to 3rd Generation Partnership Project (3GPP) system. A transmission occurs every transfer interval. One typical value of transfer interval is 1ms. That is, the transmission delay between motion controller (i.e., C/M) to device (i.e., S/A) should be less than 0.5ms.

5G Alliance for Connected Industries and Automation (ACIA) provides some options of deployment of C/M. It is assumed that there is one C/M and multiple S/As. One of the options is that each of the C/M and the S/As connect to the same RAN node as a User Equipment (UE) , where C/M communicates with S/As via radio interface towards RAN node. Another of the options is that C/M and S/As may connect to different RAN nodes as the UEs. Generally, if UE1 wants to communicate with UE2, the transmission path is UE1 => RAN node => 5G Core (5GC) => application server => 5GC => RAN node => UE2. That is, the packet will first be forwarded towards application server by 5GC, and then application server triggers packet transmission towards UE2.

3rd Generation Partnership Project (3GPP) has already introduced 5G Local Area Network (LAN) feature to reduce the transmission delay within 5G Virtual Network (VN) group. 5G VN supports local breakout via Protocol Data Unit (PDU) Session Anchor (PSA) User Plane Function (UPF) and N19 based traffic forwarding between two PSA UPFs as shown in Figures 2 (a) and 2 (b) , respectively. It assumes that UE1 (e.g., C/M) sends packets towards UE2 (e.g., S/A) within a same 5G VN group. For local breakout via PSA UPF as shown in Figure 2 (a) , UE 1 sends packets towards RAN node. RAN node forwards the packet towards PSA UPF, where optional intermediate UPFs (I-UPF (s) ) may exist between RAN node and PSA UPF. PSA UPF performs local switch for the packet without forwarding the packets towards application server. Instead, PSA UPF forwards the packets via optional I-UPF (s) to the RAN node that connects to UE 2. As shown in Figure 2 (b) , if the PSA UPF that manages the RAN node that connects to UE 1 and the PSA UPF that manages the RAN node that connects to UE 2 are different PSA UPFs, the packet from UE 1 will be forwarded between the different PSA UPFs via N19 interface without going through application server. Based on 5G LAN feature, the transmission path between 5GC and the application server can be skipped. That is, PSA UPF performs local breakout or N19 based traffic forwarding, which obviously reduces the transmission delay.

This invention targets further reducing transmission delay between C/M and S/As.

BRIEF SUMMARY

Method and apparatus for UE group management are disclosed.

In one embodiment, SMF comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to determine to perform local switch via RAN node for a PDU session or a combination of the PDU session and QoS flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QFI; and transmit, via the transceiver, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .

In some embodiment, the processor is configured to further transmit, via the transceiver, to the serving RAN node of the UE, a UE address or UE ID of the UE.

In some embodiment, the processor is configured to determine to perform local switch via RAN node based on indication of local switch via RAN node associated with the UE group contained in one of the UE’s subscription data from UDM, the UE’s policy information from PCF, and pre-configuration from OAM.

In some embodiment, the processor is configured to determine to perform local switch via RAN node if the serving RAN node of the UE supports local switch via RAN node.

In some embodiment, the processor is configured to transmit, via the transceiver, to the RAN node of the UE, neighbor RAN node IDs and a list of UE address (es) or UE ID (s) associated with each neighbor RAN node ID. The processor may be further configured to transmit, via the transceiver, to the serving RAN node of the UE, a list of QFIs associated with each UE.

In another embodiment, a method at SMF comprises determining to perform local switch via RAN node for a PDU session or a combination of the PDU session and QoS flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QFI; and transmitting, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .

In yet another embodiment, the control plane of a centralized unit of a network node (e.g. RAN node) of a network architecture comprises: a processor and a transceiver coupled to the processor, wherein the processor is configured to receive, via the transceiver, from a SMF, a local switch indication or a UE group ID and a UE address or a UE ID of a UE within a UE group, wherein the local switch indication or the UE group ID and the UE address or UE ID is associated with a PDU session ID or with a combination of the PDU session ID and QFI (s) ; and transmit, via the transceiver, to a UP of the CU of the RAN node, the local switch indication or the UE group ID and the UE address or the UE ID of the UE within the UE group, and the associated PDU session ID.

In some embodiment, the processor is further configured to transmit, via the transceiver, to the UP of the CU of the RAN node, the QFI (s) of the associated PDU session ID.

In some embodiment, the processor is configured to transmit, via the transceiver, to the UP of the CU of the RAN node, UP IDs of the CU of the RAN node and a list of UE address (es) or UE ID (s) associated with each UP ID of the CU of the RAN node.

In some embodiment, the processor is further configured to receive, via the transceiver, from the UP of the CU of the RAN node, UP TNL information related to each UP of other UP (s) of the CU of the RAN node.

In further embodiment, a method at a control plane of a centralized unit of RAN node comprises receiving, from a SMF, a local switch indication or a UE group ID and a UE address or a UE ID of a UE within a UE group, wherein the local switch indication or the UE group ID and the UE address or UE ID is associated with a PDU session ID or with a combination of the PDU session ID and QFI (s) ; and transmitting, to a UP of the CU of the RAN node, the local switch indication or the UE group ID and the UE address or the UE ID of the UE within the UE group, and the associated PDU session ID.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the embodiments briefly described above will be rendered by referring to specific embodiments that are illustrated in the appended drawings. 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:

Figure 1 illustrates a principle of motion control;

Figure 2 (a) illustrates local breakout via PSA UPF;

Figure 2 (b) illustrates local breakout via N19 interface between two PSA UPFs;

Figure 3 (a) illustrates a Next Generation Node B (gNB) with no split architecture;

Figure 3 (b) illustrates a gNB with CU (Centralized Unit) -DU (Distributed Unit) split architecture;

Figure 3 (c) illustrates a gNB with both CU-DU split and CP (Control Plane) -UP(User Plane) split architecture;

Figure 4 (a) illustrates inter-gNB with no split architecture;

Figure 4 (b) illustrates inter-gNB with CU-DU split architecture;

Figure 4 (c) illustrates inter-gNB with CP-UP split and CU-DU split architecture;

Figure 5 illustrates a procedure according to a first embodiment;

Figure 6 (a) illustrates option#1 of determining to perform local switch via RAN node;

Figure 6 (b) illustrates option#2 of determining to perform local switch via RAN node;

Figure 7 illustrates a first procedure of local switch via RAN node;

Figure 8 illustrates a procedure of coordinating gNB-CU-UPs by gNB-CU-CP;

Figure 9 illustrates a second procedure of local switch via RAN node;

Figure 10 illustrates a third procedure of local switch via RAN node;

Figure 11 is a schematic flow chart diagram illustrating an embodiment of a method;

Figure 12 is a schematic flow chart diagram illustrating a further embodiment of a method; and

Figure 13 is a schematic block diagram illustrating another apparatus according to one embodiment.

DETAILED DESCRIPTION

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” . The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing 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. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in code and/or software for execution by various types of processors. An identified module of code may, for instance, include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. 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. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer readable storage devices.

Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. 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) .

Reference throughout this specification to “one embodiment” , “an embodiment” , or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” , “in an embodiment” , and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including” , “comprising” , “having” , and variations thereof mean “including but are not limited to” , unless otherwise expressly specified. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, otherwise unless expressly specified. The terms “a” , “an” , and “the” also refer to “one or more” unless otherwise expressly specified.

Furthermore, described features, structures, or characteristics of various embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. 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. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. 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 schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function (s) .

It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may substantially be executed concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, to the illustrated Figures.

Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart diagrams, and combinations of blocks in the block diagrams and/or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code.

The description of elements in each Figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

This disclosure proposes UE group management for local switch via RAN node, i.e., without going through PSA UPF.

Before describing the invention, CU-DU split architecture and CP-UP split architecture are explained, where CU stands for Centralized Unit, DU stands for Distributed Unit; and CP stands for Control Plane, UP stands for User Plane.

Figure 3 (a) illustrates a scenario of single gNB with no split architecture. As shown in Figure 3 (a) , a gNB connects to a C/M and two S/As (e.g., S/A#1 and S/A#2) . For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB =>S/A#1; and transmission path from C/M to S/A#2 is C/M => gNB => S/A#2.

Figure 3 (b) illustrates a scenario of single gNB with CU-DU split architecture. As shown in Figure 3 (b) , one gNB is composed of one gNB-CU and at least one gNB-DU (e.g., two gNB-DUs: gNB-DU#1 and gNB-DU#2) . There is F1 interface between gNB-CU and each gNB-DU.F1 interface is composed of F1-C (i.e., for control plane) and F1-U (i.e., for user plane) . gNB-CU is responsible for Service Data Adaptation Protocol (SDAP) layer and Packet Data Convergence Protocol (PDCP) layer of the radio interface.gNB-DU is responsible for Radio Link Control (RLC) layer, Media Access Control (MAC) layer and physical (PHY) layer of the radio interface. In this disclosure, it is assumed that local switch via RAN node (e.g., gNB) does not have impact on the protocol layers of the radio interface. That is, SDAP, PDCP, RLC, MAC and PHY layers of radio interface shall encapsulate or decapsulate all the packets. Therefore, the packets shall be transferred towards gNB-CU handling SDAP layer and PDCP layer. For example, gNB-CU decapsulates SDAP and PDCP layers of the packet from the source UE and encapsulate SDAP and PDCP layers of the packet towards target UE before sending the packet to target UE (e.g., via gNB-DU) . As shown in Figure 3 (b) , C/M and S/A#1 connect to gNB-DU#1, and S/A#2 connects to gNB-DU#2. For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB-DU#1 => gNB-CU => gNB-DU#1 =>S/A#1; and transmission path from C/M to S/A#2 is C/M => gNB-DU#1 => gNB-CU => gNB-DU#2 => S/A#2.

In addition to CU-DU split, one gNB-CU may be further split into one gNB-CU-CP and at least one gNB-CU-UP (e.g., two gNB-CU-UPs) . Figure 3 (c) illustrates a scenario of single gNB with both CU-DU split and CP-UP split architecture (which may be referred to as single gNB with CP-UP split architecture) . gNB-CU-CP is responsible for control plane. gNB-CU-UP is responsible for user plane. E1 interface is between gNB-CU-CP and each gNB-CU-UP. F1-C interface is between gNB-CU-CP and each gNB-DU. F1-U interface is between gNB-CU-UP and each gNB-DU. In addition, it is assumed that there is X interface between gNB-CU-UP#1 and gNB-CU-UP#2. X interface may be Xn interface between two gNBs, and in particular Xn-U between two gNB-CU-UPs. As shown in Figure 3 (c) , C/M and S/A#1 connect to gNB-DU#1, and S/A#2 connects to gNB-DU#2. For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB-DU#1 => gNB-CU-UP#1 => gNB-DU#1 => S/A#1; and transmission path from C/M to S/A#2 is C/M => gNB-DU#1 => gNB-CU-UP#1 => gNB-CU-UP#2 => gNB-DU#2 => S/A#2.

Figures 4 (a) , 4 (b) and 4 (c) illustrate inter-gNB (e.g., two gNBs) scenario architectures, in which Figure 4 (a) illustrates inter-gNB with no split architecture; Figure 4 (b) illustrates inter-gNB with CU-DU split (i.e., without CP-UP split) architecture; and Figure 4 (c) illustrates inter-gNB with CP-UP split (i.e., in addition to CU-DU split) architecture.

As shown in Figure 4 (a) , C/M (e.g., UE#1) and S/A#1 connect to gNB#1, and S/A#2 (e.g., UE#2) connects to gNB#2. Xn interface is between gNB#1 and gNB#2. For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB#1 =>S/A#1; and transmission path from C/M to S/A#2 is C/M => gNB#1 => gNB#2 => S/A#2.

As shown in Figure 4 (b) , C/M (e.g., UE#1) and S/A#1 connect to gNB-DU#1, and S/A#2 (e.g., UE#2) connects to gNB-DU#2. Xn interface is between gNB#1 (i.e., gNB-CU#1) and gNB#2 (i.e., gNB-CU#2) . F1 interface is between gNB-DU and gNB-CU. For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB-DU#1 => gNB-CU#1 => gNB-DU#1 => S/A#1; and transmission path from C/M to S/A#2 is C/M =>gNB-DU#1 => gNB-CU#1 => gNB-CU#2 => gNB-DU#2 => S/A#2.

As shown in Figure 4 (c) , C/M and S/A#1 connect to gNB-DU#1, and S/A#2 connects to gNB-DU#2. Xn-U interface is between gNB-CU-UP#1 and gNB-CU-UP#2. Xn-C interface is between gNB-CU-CP#1 and gNB-CU-CP#2. E1 interface is between gNB-CU-CP and gNB-CU-UP. F1-C interface is between gNB-CU-CP and gNB-DU. F1-U interface is between gNB-CU-UP and gNB-DU. For local switch via RAN node (e.g., gNB) , transmission path from C/M to S/A#1 is C/M => gNB-DU#1 => gNB-CU-UP#1 => gNB-DU#1 => S/A#1; and transmission path from C/M to S/A#2 is C/M => gNB-DU#1 => gNB-CU-UP#1 => gNB-CU-UP#2 => gNB-DU#2 => S/A#2. Incidentally, Figure 4 (c) is a simplified structure of two gNBs with CP-UP split and CU-DU split architecture, in which there is only one gNB-CU-UP (i.e., gNB-CU-UP #1) in gNB-CU#1, and there is only one gNB-CU-UP (i.e., gNB-CU-UP#2) in gNB-CU#2. It is possible that that there are multiple gNB-CU-UPs in gNB-CU#1 and/or there are multiple gNB-CU-UPs in gNB-CU#2.

This disclosure proposes that Session Management Function (SMF) determines to perform local switch via RAN node. Figure 5 illustrates a procedure 500 of a first embodiment. In step 510, SMF determines to perform local switch via RAN node for PDU session or for a combination of PDU session and Quality of Service (QoS) flows; and in step 520, SMF provides the RAN node with local switch indication (or UE group ID) associated with PDU session ID or with a combination of PDU session ID and QoS Flow ID (s) (QFI (s) ) . In addition, SMF may also provide the RAN node with UE address (or UE ID) associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Detailed implementations of each of steps 510 and 520 are described as follows.

There are five options (e.g., Option#1, Option#2, Option#3, Option#4, Option#5) for the SMF to determine to perform local switch via RAN node for a PDU session or a combination of PDU session and QoS flows (s) of a UE.

Option#1: SMF determines to perform local switch via RAN node based on indication of local switch via RAN node contained in subscription data.

Figure 6 (a) illustrates Option#1.

The Application Function (AF) provides the indication of local switch via RAN node. For example, External Parameter Provisioning based on Technical Specification (TS) 23.502 4.15.6.2 may be used for the AF to provide the indication of local switch via RAN node. Other procedures may alternatively be utilized by AF to provide the indication of local switch via RAN node.

For example, AF provides 5GC (e.g., Unified Data Management (UDM) via Network Exposure Function (NEF) ) with local switch indication as well as UE group information. The local switch indication and the UE group information provided from AF to UDM or UDR via NEF can be collectively referred to as UE group configuration.

UE group information may include group data (e.g., Data Network Name (DNN) , Single Network Slice Selection Assistance Information (S-NSSAI) , application descriptor, PDU type, secondary authorization and etc. ) and group membership management parameters (e.g., external group ID, and list of Generic Public Subscription Identifiers (GPSIs) (i.e., list of UEs within the UE group) .

The local switch indication can be an indication of local switch via RAN node for data transmission within the UE group. That is, if no local switch indication is provided (i.e., no indication of local switch via RAN node) is provided, 5G VN shall be performed if the UE group information is provided. It means that local switch via UPF will be performed. If local switch indication is provided (i.e., indication of local switch via RAN node) is provided, local switch via RAN node will be performed based on the UE group information (e.g., for the UE group identified by the external group ID) . Alternatively, the local switch indication can be an indication of local switch via UPF or an indication of local switch via RAN node. For example, if the value of local switch indication is ‘0’ or false, local switch via UPF shall be performed. On the other hand, if the value of local switch indication is ‘1’ or true, local switch via RAN node shall be performed.

The local switch indication can be implemented as a local switch indication Information Element (IE) . The local switch indication IE can be contained either in group data IE or in group membership management parameters IE. Alternatively, the local switch indication IE can be a standalone IE, which is parallel to group data IE and group membership management parameters IE.

UDM assigns internal group ID for the external group ID. In addition, UDM translates each GPSI in the list of GPSIs to SUbscription Permanent Identifier (SUPI) . The internal group ID is referred to as UE group ID in this disclosure. UDM stores the UE group configuration (i.e., local switch indication and UE group information changed by UDM (e.g., at least including UE group ID (i.e., internal group ID) and SUPIs (each of which identifies a UE) within the UE group identified by the UE group ID) in Unified Data Repository (UDR) .

For each UE identified by the SUPI translated from each GPSI contained in the UE group information, the UE group ID (i.e., internal group ID) and the indication of local switch via RAN node associated with the UE group ID is contained in the UE’s subscription data (i.e., Session Management Subscription data) .

During the PDU session establishment procedure (including steps 1-21 based on TS 23.502 4.3.2.2.1) of a UE, SMF obtains the UE’s subscription data (e.g., Session Management Subscription data) from UDM, e.g., in step 4. Based on the SUPI of the UE initiating the PDU session establishment procedure, SMF obtains the UE’s subscription data containing UE group ID and the associated indication of local switch via RAN node.

SMF may determine to perform local switch via RAN node for the PDU session of the UE within a UE group based on the indication of local switch via RAN node associated with the UE group ID identifying the UE group contained in the UE’s subscription data.

Option#2: SMF determines to perform local switch via RAN node based on indication of local switch via RAN node contained in Policy and Charging Control (PCC) rule.

Figure 6 (b) illustrates Option#2.

AF provides 5GC (e.g., UDM via NEF) with UE group configuration (i.e., local switch indication as and UE group information) by using External Parameter Provisioning based on TS 23.502 4.15.6.2, in the same manner as described in Option#1. Accordingly, for each UE identified by the SUPI translated from each GPSI contained in the UE group information, the UE group ID (i.e., internal group ID) and the indication of local switch via RAN node associated with the UE group ID is stored in the UE’s subscription data (e.g., Session Management Subscription data) in UDR by UDM.

During UE’s registration procedure based on TS 23.502 clause 4.2.2, Access and Mobility Management Function (AMF) obtains Access and Mobility subscription data from UDM, which contains internal group (i.e., local group) ID list for the UE. AMF provides Policy Control Function (PCF) with the local group ID list of the UE, and SUPI of the UE. PCF queries, from UDR, UE group configuration based on each internal group ID contained in the local group ID list. UDR provides PCF with the local switch indication (e.g., indication of local switch via RAN node) associated with each internal group ID (i.e., each UE group ID) . PCF generates the corresponding UE Route Selection Policy (URSP) rules for each internal group ID.

During the PDU session establishment procedure (including steps 1-21 based on TS 23.502 4.3.2.2.1) of a UE, SMF obtains the UE’s subscription data from UDM, e.g., in step 4. In Option#2, the UE’s subscription data from UDM contains at least internal group ID associated with the PDU session ID. Then, SMF triggers SM policy association procedure to PCF by providing the internal group ID. In response, PCF provides SMF with session rule (e.g., PDU session related policy information) containing the local switch indication associated with internal group ID, e.g., in step 7b of the PDU session establishment procedure. SMF determines to perform local switch via RAN node for the PDU session (identified by the PDU session ID) based on the local switch indication provided by PCF, which is contained in session rule, e.g., PDU session related policy information.

Alternatively, the local switch indication can be associated with service data flow (s) in PCF. As described above, the group data in UE group information includes application descriptor. The application descriptor describes service data flow (s) . So, when PCF queries, from UDR, UE group configuration, the UDR provides PCF with local switch indication along with the UE group information. Accordingly, PCF may generate the corresponding UE Route Selection Policy (URSP) rules for each service data flow. That is, the local switch indication can be associated with service data flow (s) for an internal group. In this manner, when SMF triggers SM policy association procedure to PCF by providing the internal group ID, PCF provides SMF with PCC rule containing the local switch indication associated with service data flow (s) , e.g., in step 7b of the PDU session establishment procedure. Accordingly, SMF may include the service data flow (s) associated with local switch indication in one or multiple QoS flows.

For Option#1 or to Option#2, if SMF finds that RAN node does not support local switch, SMF determines to perform local switch via UPF. In this condition, SMF may indicate AF that local switch via RAN node is not available or is not performed. The indication path may be SMF=>PCF=>NEF=>AF or SMF=>PCF=>AF or SMF=>AF.

Option#3: SMF determines to perform local switch via RAN node based on pre-configuration, e.g., pre-configuration from Operations and Maintenance (OAM) .

Different from Option#1 or Option#2 in which the indication of local switch via RAN node comes from AF, in Option#3, the indication of local switch via RAN node comes from OAM. That is, OAM provides SMF with external group ID and local switch indication (e.g., indication of local switch via RAN node) associated with the external group identified by the external group ID, as a pre-configuration. During the PDU session establishment procedure (including steps 1-21) of a UE based on TS23.502 4.3.2.2.1, SMF obtains the UE’s subscription data from UDM, e.g., in step 4. In Option#3, the UE’s subscription data contains a mapping relation between internal group ID and external group ID. The UE is within an internal group identified by an internal group ID. If the external group ID corresponding to the internal group ID is associated with local switch indication (e.g., indication of local switch via RAN node) according to the pre-configuration, SMF determines to perform local switch via RAN node for the PDU session of the UE within the internal group, for the serving RAN node of the UE. Incidentally, if SMF finds that the serving RAN node of the UE does not support local switch, then 5G VN feature (i.e., local switch via UPF) is determined.

Option#4: SMF determines to perform local switch via RAN node by itself.

In Option#4, AF does not provide UDM with local switch indication associated with UE group information. SMF does not receive pre-configuration including local switch indication from OAM, either. Upon PDU session establishment procedure (including steps 1-21) of a UE based on TS23.502 4.3.2.2.1, SMF obtains, from UDM, the UE’s subscription data containing internal group ID of the UE. SMF determines to perform legacy 5G VN feature (i.e., local switch via UPF) or local switch via RAN node by itself. For example, SMF may check whether UPF supports 5G VN feature and whether the serving RAN node of the UE supports local switch. In particular, SMF may determine to perform local switch via RAN node if the serving RAN node of the UE supports local switch.

In step 510, SMF determines to perform local switch via RAN node for the PDU session of the UE or for a combination of the PDU session and QFI (s) of the UE according to any of Options#1 to 4. In addition, SMF may take other factors into consideration when determining to perform local switch via RAN node.

A first example of the other factors is: all UEs of the same UE group are in the same RAN node. That is, if all UEs of the same UE group are not in the same RAN node, SMF may determine not to perform local switch via RAN node (e.g., determine to perform local switch via UPF) .

A second example of the other factors is: all UEs of the same UE group are in different RAN nodes each of which has Xn interface. That is, if all UEs of the same UE group are in different RAN nodes, while at least one of the different RAN nodes does not have Xn interface, SMF may determine not to perform local switch via RAN node (e.g., determine to perform local switch via UPF) .

An Xn interface is between two RAN nodes (e.g., between RAN node#1 and RAN node#2) if one of the RAN nodes (e.g., RAN node#1) is a neighbor RAN node of the other of the RAN nodes (e.g., RAN node#2) .

There are three mechanisms for SMF to know whether there is Xn interface between two RAN nodes and/or whether RAN node supports local switch.

Mechanism#1 (pre-configuration) : It is assumed that OAM may provide SMF with a neighbor RAN node list for each RAN node in the serving area of the SMF. For example, OAM may provide SMF with the neighbor RAN node list for RAN node ID#1 including RAN node ID#2, RAN node ID#5, and RAN node ID#8. In addition, OAM may also provide SMF with RAN node ID and the local switch support indicator. For example, OAM may provide SMF that RAN node ID#1 supports local switch, and RAN node ID#2 supports local switch, RAN node ID#5 does not support local switch, RAN node ID#8 does not support local switch, etc.

Mechanism#2: RAN node may report its neighbor RAN node list and/or local switch support indicator to AMF. AMF may provide SMF with RAN node ID (e.g., gNB ID) and the corresponding neighbor RAN node list and/or local switch support indicator, e.g., upon PDU session establishment procedure at step 3.

Mechanism#3: RAN node may report its neighbor RAN node list and/or local switch support indicator to AMF. AMF registers in Network Repository Function (NRF) with RAN node ID and the corresponding neighbor RAN node list and/or local switch support indicator. Upon PDU session establishment, AMF provides SMF with user location info, which includes cell ID (e.g., NR Cell Global Identifier (CGI) ) , Tracking Area Identity (TAI) etc. NR CGI includes Public Land Mobile Network (PLMN) identity and NR Cell Identity. The leftmost bits of the NR Cell Identity IE correspond to the gNB ID. SMF provides NRF with the NR CGI or NR Cell Identity or gNB ID to check the neighbor RAN node list and/or local switch support indicator. If SMF provides NR CGI or NR Cell Identity, NRF may compare the left most bits of NR Cell Identity with RAN node ID to determine the RAN node ID. NRF provides SMF the neighbor RAN node list and/or local switch support indicator associated with the NR CGI or NR Cell Identity or gNB ID provided by SMF.

In all of the above-described Options#1 to 4, SMF determines to perform local switch via RAN node during or after a UE performs PDU session establishment procedure. Alternatively, if some QoS flow (s) are used for UE group transmission (i.e., UE address or UE ID is associated with a combination of PDU session ID and QoS Flow ID (s) (QFI (s) ) , the determination by SMF can be made during or after PDU session modification procedure.

Option#5: SMF determines to perform local switch via RAN node, if the local switch via RAN node has been determined for the same RAN node for the same UE group.

As described above, SMF may determine to perform local switch via RAN node for a PDU session (or a combination of PDU session and QoS flow (s) ) of a first UE according to any of Option#1, Option#2, Option#3 and Option#4. That is, the local switch via RAN node will be performed via the serving RAN node of the first UE, who is within a UE group. When a PDU session of a second UE performs PDU session establishment or modification procedure, SMF needs to determine whether to perform local switch via RAN node for the PDU session (or a combination of PDU session and QoS flow (s) ) of the second UE, who is within the same UE group as the first UE. In this condition, if the serving RAN node of the second UE is the same as the serving RAN node of the first UE, while SMF has determined to perform local switch via RAN node for the serving RAN node, then SMF may directly determine to perform local switch via RAN node (i.e., for the same serving RAN node) for the PDU session (or a combination of PDU session and QoS flow (s) ) of the second UE.

In step 520, SMF provides RAN node with at least local switch indication (or UE group ID) , which is associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Local switch via RAN node indication can be used instead of local switch indication.

If there is only one UE group, the UE group ID is not needed. SMF may provide RAN node with local switch indication associated with PDU session ID or with a combination of PDU session ID and QFI (s) . If there is more than one UE group, SMF may provide RAN node with the UE group IDs or combinations of UE group IDs and local switch indication, each of which is associated with PDU session ID or a combination of PDU session ID and QFI (s) . It means that if SMF does not provide RAN node with UE address or UE ID (associated with PDU session ID or a combination of PDU session ID and QFI (s) ) , RAN node can obtain UE address later from the IP header or MAC header of DL packets or UL packets. UE address may be UE’s Internet Protocol (IP) address for the PDU session, or UE’s MAC address. E.g., for DL packets, RAN node obtains UE address from the target address of IP header or MAC header. For UL packets, RAN node obtains UE address from the source address of IP header or MAC header. Alternatively, SMF may also provide UE address (or UE ID) together with local switch indication (or UE group ID) . UE ID refers to a UE ID for each UE within the UE group. Two examples of configuration provided by SMF to RAN node are as follows. Example#1 is for local switch indication or UE group ID associated with PDU session ID. Example#2 is for local switch indication or UE group ID associated with a combination of PDU session ID and QFI (s) .

Example#1:

>PDU session ID

>Local switch indication

>UE group ID

>UE address or UE ID

>list of QoS flows

>>QFI

Example#2:

>PDU session ID

> UE group ID

> UE address or UE ID

>list of QoS flows

>>QFI

>>local switch indication

In addition, SMF determines that all the UEs are within the same RAN node and no CU-CP split (e.g., in scenario shown in Figure 3 (a) or Figure 3 (b) ) , SMF may not provide RAN node with the UE group ID) .

The UE ID within the UE group may be allocated by AF and contained in UE group information. That is, SMF obtains the UE ID within UE group from subscription data from UDM. If the whole PDU session is utilized for UE group transmission, the UE address or UE ID may be associated with PDU session ID. Alternatively, if specific QoS flow (s) of the PDU session is/are utilized for UE group transmission, UE address or UE ID may be associated with a combination of PDU session ID and QoS flow ID (s) (i.e., QFI (s) ) . For example, if the local switch indication (or UE group ID) provided by SMF is associated with PDU session ID, it means that the whole PDU session is utilized for UE group transmission; while if the local switch indication (or UE group ID) provided by SMF is associated with a combination of PDU session ID and QFI (s) , it means that the QoS flow (s) identified by QFI (s) of the PDU session identified by the PDU session ID are utilized for UE group transmission. Alternatively, SMF may provide RAN node with a specific indication on whether the whole PDU session or specific QoS flow (s) of the PDU session is utilized for UE group transmission.

If SMF provides RAN node with UE ID (i.e., UE ID allocated within the UE group) and the associated PDU session ID or associated combination of PDU session ID and QFI(s) , SMF may also provide UE with the allocated UE ID. For example, SMF may contain the allocated UE ID in the Non Access Stratum (NAS) message sent to UE, e.g., via PDU Session Establishment or Modification Accept message. Alternatively, RAN node may provide UE with the allocate UE ID. For example, RAN node may contain the allocated UE ID in RRC message sent to UE. If all UEs of the UE group are within the same RAN node, SMF may even trigger RAN node to allocate UE ID for each UE of the UE group.

It is assumed that UE#1 (e.g., C/M) and UE#2 (e.g., S/A#1 or S/A#2) have known the UE address or UE ID between each other. The detailed manner to achieve this may be that UEs (e.g., UE#1, UE#2, etc. ) exchange UE address or UE ID via application layer, which is out of the scope of 3GPP. An example is described as follows: NAS layer provides UE address or UE ID to application layer. Application layer provides application server with UE address or UE ID. Application server has the mapping relationship between UE ID in application layer and UE address or UE ID for all the UEs within the UE group. Application server provides UE’s application layer the mapping relationship between UE ID in application layer and UE address or UE ID within the UE group. When UE#1 wants to communicate with UE#2, it first determines UE#2’s UE address or UE ID based on UE#2 ID in application layer. Then UE#1 inserts UE address or UE ID in the packet header, e.g., inserts UE address into IP header or MAC header.

Upon receiving the local switch indication (or UE group ID) and UE address (or UE ID) associated with PDU session ID or with a combination of PDU session ID and QFI (s) , RAN node preserves the mapping relationship among (1) UE group ID, (2) UE’s Cell Radio Network Temporary Identifier (C-RNTI) (i.e., UE’s ID over air interface) , (3) UE address or UE ID, and (4) PDU session ID or combination of PDU session ID and QFI (s) . That is, RAN node has the mapping relationship among UE’s PDU session or combination of PDU session ID and QFI (s) and UE’s C-RNTI, UE address (or UE ID) and/or UE group ID.

Note that the procedure 500 is performed each time a UE performs PDU session Establishment or Modification procedure. It means that each serving RAN node of the UEs preserves the mapping relationship for the same UE group (e.g., identified by UE group ID#1) like follows:

- UE group ID#1

○ UE address#1 or UE ID#1 of UE#1 (e.g., C/M) , C-RNTI#1, PDU session ID#1, QFI#1

○ UE address#2 or UE ID#2 of UE#2 (e.g., S/A#1) , C-RNTI#2, PDU session ID#2, QFI#2

○ UE address#3 or UE ID#3 of UE#3 (e.g., S/A#2) , C-RNTI#3, PDU session ID#3, QFI#3

SMF determines to perform local switch via RAN node for PDU session (or a combination of PDU session and QoS flow (s) ) of a UE in step 510. Step 510 can be performed after SMF receives necessary information to make the determination during or after the PDU session Establishment or Modification procedure. For example, in Option#1, SMF can make determination after step 4 of the PDU session Establishment procedure; in Option#2, SMF can make determination after step 7b of the PDU session Establishment procedure; in Option#3, SMF can make determination after step 4 of the PDU session Establishment procedure; and in Option#4, SMF can make determination after step 4 of the PDU session Establishment procedure. If other factors are considered in making determination, SMF can make determination after receiving necessary information of the other factors.

SMF provides RAN node with local switch indication (or UE group ID) and UE address (or UE ID) , where the UE address (or UE ID) is associated with PDU session ID or with a combination of PDU session ID and QFI (s) , in step 520. Step 520 can be implemented in step 11 (in which SMF provides N2 SMF information to AMF) and step 12 (in which AMF provides N2 SM information to RAN node) of the PDU session Establishment procedure, if the determination has been made before step 11 of the PDU session Establishment procedure.

Alternatively, both step 510 and step 520 can be performed after the PDU session Establishment or Modification procedure.

Suppose that there are a number of UEs within a UE group, the procedure 500 shall be performed upon each UE within the UE group performing the PDU session Establishment or Modification procedure. Although a UE may belong to more than one UE group, for each PDU session, the UE can only belong to one UE group.

The RAN node (s) serving the UEs within a UE group can be one RAN node, or multiple RAN nodes (e.g., two RAN nodes that have Xn interface) .

When the RAN node (s) serving the UEs within a UE group are 2 or more, in step 520, the SMF provides each of the serving RAN nodes with local switch indication (or UE group ID) , neighbor RAN node IDs, and a list of UE addresses (or UE IDs) associated with each neighbor RAN node ID ( “an UE address (or UE ID) associated with a neighbor RAN node ID”means that the UE that has the UE address (or UE ID) is served by the neighbor RAN node identified by the neighbor RAN node ID) , where local switch indication (or UE group ID) is associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Incidentally, the list of UE addresses (or UE IDs) associated with each RAN node ID to be provided to a specific RAN node may not include the UE addresses (or UE IDs) associated with each RAN node ID that have been provided to the specific RAN node.

In the following description, detailed procedures related to local switch via RAN node are described in a second embodiment, in which it is assumed that the UEs within a UE group are served by one RAN node, and in a third embodiment, in which it is assumed that the UEs within a UE group are served by two RAN nodes that have Xn interface.

In the second embodiment, the one RAN node can be implemented as gNB shown in Figure 3 (a) , or gNB-CU shown in Figure 3 (b) , or gNB-CU-CP shown in Figure 3 (c) .

In the condition that all UEs of the UE group are in the same RAN node implemented as gNB shown in Figure 3 (a) , or gNB-CU shown in Figure 3 (b) , when at least the C/M (e.g., UE#1) and a S/A (e.g., UE#2) have performed the PDU session Establishment or Modification procedure, SMF determines, in step 510, local switch via RAN node for the serving RAN node and transmit, in step 520, for each of UE#1 and UE#2, the local switch indication (or UE group ID) associated with PDU session ID or with a combination of PDU session ID and QFI(s) . SMF may further provide UE address (or UE ID) associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Accordingly, the serving RAN node decides to perform local switch via RAN node (e.g., via itself) for the UL packets sent by UE#1 (e.g., C/M) , e.g., to UE#2 (e.g., S/A) .

Figure 7 illustrates a first procedure 700 of local switch via RAN node (e.g., via serving RAN node) , in which the serving RAN node can be gNB shown in Figure 3 (a) , or gNB-CU shown in Figure 3 (b) .

In step 710, UL packets are sent from UE#1 (e.g., C/M) to RAN node. In condition of Figure 3 (a) , the UL packets are sent to gNB. In condition of Figure 3 (b) , the UL packets are sent via gNB-DU#1 to gNB-CU.

In step 720, RAN node (e.g., gNB or gNB-CU) decides to perform local switch via RAN node for the UL packets sent by UE#1, where the UL packets are sent within the PDU session identified by the PDU session ID or the QoS flow (s) identified by the QFI (s) of the PDU session identified by the PDU session ID. In addition, RAN node determines target UE (i.e., UE#2) ’s C-RNTI and PDU session ID, and determines the DL QoS Data Radio Bearer (DRB) directly or based on the QoS requirement of the UL DRB.

In particular, RAN node may recognize the logical channel, DRB and PDU session associated with the UL packets. RAN node further determines QoS flow based on logical channel or DRB or based on QFI contained in UL packet’s SDAP header. Therefore, RAN node decides to perform local switch via RAN node for the UL packets based on the UE’s C-RNTI, PDU session ID, or based on the UE’s C-RNTI, PDU session ID, and QFI.

Alternatively, RAN node may decide to perform local switch via RAN node based on the target UE’s C-RNTI. There are two options for the RAN node to determine the target UE’s C-RNTI and the associated PDU session or the associated combination of PDU session and QoS flow (s) .

Option#21: RAN node obtains the target IP address (or MAC address) contained in the IP header (or Ethernet header) of the UL packets. RAN node determines target UE’s C-RNTI and the associated PDU session (or associated combination of PDU session and QoS flow (s) ) based on the target UE address (e.g., IP address or MAC address) .

Option#22: if SMF provides RAN node with UE ID associated with PDU session or combination of PDU session and QoS flow (s) in PDU session establishment or modification procedure, UE#1 (e.g., C/M) inserts the allocated UE ID of the target UE in protocol header of the radio interface, e.g., SDAP header, or PDCP header, or RLC header, or MAC header, or PHY header. Other headers may be used instead, e.g., IP header. RAN node acquires target UE address in the protocol header (e.g., SDAP or PDCP or RLC or MAC or PHY header) and determines target UE’s C-RNTI and the associated PDU session or combination of PDU session and QoS flow (s) based on the target UE ID.

In step 730, RAN node decapsulates the protocol header of the UL packets sent by UE#1 (e.g., C/M) and encapsulates the UL packets as the DL packets for UE#2 (e.g., S/A#2) . It is assumed that the DL packets are encrypted as usual in PDCP layer using the encrypt key of UE#2 (e.g., S/A) .

If UE address or UE ID is associated with combination of PDU session and one QoS flow, RAN node is able to determine the target UE’s C-RNTI, PDU session and also QoS flow based on UE address or UE ID. RAN node sends the DL packets through the DRB associated with the identified PDU session and QoS flow. RAN node shall also guarantee the QoS requirement of the QoS flow.

If UE address or UE ID is associated with PDU session or associated with combination of PDU session and multiple QoS flows, RAN node is able to determine the target UE’s C-RNTI and PDU session based on UE address or UE ID. It is assumed that each UL packet is associated with one QoS flow. RAN node identifies the QoS flow of the associated PDU session of the UL packet (e.g., RAN node identifies the QoS flow associated with the UL packet by checking the QFI contained in SDAP header of the UL packet) , acquires the corresponding QoS requirement of the QoS flow of UE#1 (e.g., C/M) . RAN node determines the DL QoS flow for the target UE which matches the QoS requirement of the UL packet. In this way, RAN node is able to determine the DRB for the DL packets towards target UE#2 (e.g., S/A#2) based on the determined DL QoS flow of UE#2.

In the condition that all UEs of the same UE group are in the same RAN node implemented as gNB-CU-CP shown in Figure 3 (c) , in user plane, C/M and S/A may be served by the same gNB-CU-UP (e.g., gNB-CU-UP#1) or by different gNB-CU-UPs (e.g., gNB-CU-UP#1 and gNB-CU-UP#2) . So, the gNB-CU-CP needs to coordinate gNB-CU-UPs, as in the procedure 800 illustrated in Figure 8.

It is assumed that UE#1 (e.g., C/M) is served by gNB-CU-UP#1; and that UE#2 (e.g., S/A#2) is served by gNB-CU-UP#2. It is also assumed that gNB-CU-CP preserves the mapping relationship among (1) UE group ID, (2) UE’s C-RNTI (i.e., UE’s ID over air interface) , (3) UE address or UE ID, and (4) PDU session ID or combination of PDU session ID and QFI (s) , for both UE#1 and UE#2.

In step 810, gNB-CU-CP configures gNB-CU-UP#1 with local switch indication (or UE group ID) and UE address (or UE ID) associated with PDU session ID or combination of PDU session ID and QFI (s) , e.g., for UE#1. gNB-CU-CP may provide DRB ID to replace QFI.

In step 820, gNB-CU-UP#1 preserves UE group ID (optional) , UE UP ID, UE address or UE ID associated with PDU session ID or combination of PDU session ID and QFI (s) or combination of PDU session ID and DRB ID (s) , for UE#1. UE UP ID is the UE ID used by gNB-CU-UP to identify UE, e.g., gNB-CU-CP UE E1AP ID, gNB-CU-UP UE E1AP ID or RAN UE ID. That is, gNB-CU-UP#1 has the mapping relationship among (1) UE UP ID, (2) UE’s PDU session or combination of PDU session ID and QFI (s) or combination of PDU session ID and DRB ID (s) , (3) UE address or UE ID, and (4) UE group ID (optional) , for UE#1.

In step 830, gNB-CU-CP configures gNB-CU-UP#2 with local switch indication (or UE group ID) , UE address (or UE ID) associated with PDU session ID or combination of PDU session ID and QFI (s) or combination of PDU session ID and DRB ID (s) , e.g., for UE#2.

In step 840, gNB-CU-UP#2 preserves UE group ID (optional) , UE UP ID, UE address or UE ID associated with PDU session ID or combination of PDU session ID and QFI (s) or combination of PDU session ID and DRB ID (s) , for UE#2. That is, gNB-CU-UP#2 has the mapping relationship among (1) UE UP ID, (2) UE’s PDU session or combination of PDU session ID and QFI (s) or combination of PDU session ID and DRB ID (s) , (3) UE address or UE ID, and (4) UE group ID (optional) , for UE#2.

In step 850, gNB-CU-CP provides gNB-CU-UP#1 with local switch indication (or UE group ID) , neighbor gNB-CU-UP ID (s) , a list of UE address (es) or UE ID (s) , and a QFI list (which is optional) associated with each of neighbor gNB-CU-UP (s) managed by gNB-CU-CP, e.g., including gNB-CU-UP#2. gNB-CU-UP ID can be an index assigned to gNB-CU-UP. Besides, gNB-CU-CP may further provide combinations of PDU session ID and QFI (s) associated with each of the neighbor gNB-CU-UP (s) , e.g., including gNB-CU-UP#2.

If the PDU session is associated with UE group transmission, gNB-CU-CP provides gNB-CU-UP#1 with local switch indication (or UE group ID) , gNB-CU-UP#2, UE#2 (e.g., S/A) address or UE#2 ID associated with gNB-CU-UP#2. If combination of PDU session ID and QFI (s) is associated with UE group transmission, gNB-CU-CP provides gNB-CU-UP#1 with local switch indication (or UE group ID) , gNB-CU-UP#2, UE#2 (e.g., S/A) address or UE#2 ID and QFI (s) associated with gNB-CU-UP#2. The QFI may be replaced by DRB ID.

If, as shown in Figure 3 (c) , 3 UEs of UE group#1 are located in 2 gNB-CU-UPs, in which UE#1 (e.g., C/M) and UE#3 (e.g., S/A#1) are in gNB-CU-UP#1, and UE#2 (e.g., S/A#2) is in gNB-CU-UP#2, one example of information provided by gNB-CU-CP to gNB-CU-UP#1 may be as follows:

Local switch indication (or UE group ID#1)

gNB-CU-UP#2, (UE address#2 of UE#2, QFI#2)

In step 860, gNB-CU-UP#1 responds to gNB-CU-CP with local switch indication (or UE group ID) , neighbor gNB-CU-UP ID (s) and the corresponding User Plane (UP) Transport Network Layer (TNL) information (s) (or called as UP Transport Layer information) at UP#1 side. TNL information includes Endpoint IP address and General Packet Radio Services (GPRS) Tunneling Protocol Tunnel Endpoint Identifier (GTP-TEID) . If gNB-CU-CP provides multiple neighbor gNB-CU-UP IDs in step 850, gNB-CU-UP#1 shall provide a list of neighbor gNB-CU-UP IDs and the UP TNL information associated with each neighbor gNB-CU-UP ID. For example, gNB-CU-UP#1 provides gNB-CU-CP with the following information:

Local switch indication (or UE group ID#1)

gNB-CU-UP#2, UP TNL information#1 at UP#1 side

If there is an extra gNB-CU-UP#3 connected with gNB-CU-CP in the gNB-CU, and gNB-CU-UP#3 connects with S/A#3 via gNB-DU#3, gNB-CU-UP#1 may provide gNB-CU-CP with the following information:

Local switch indication (or UE group ID#1)

gNB-CU-UP#2, UP TNL information#1 at UP#1 side

gNB-CU-UP#3, UP TNL information#2 at UP#1 side

In step 870, which is similar to step 850, gNB-CU-CP provides gNB-CU-UP#2 with local switch indication (or UE group ID) , neighbor gNB-CU-UP ID (s) , a list of UE address (es) or UE ID (s) , and a QFI list (which is optional) associated with each of neighbor gNB-CU-UP (s) managed by gNB-CU-CP, e.g., including gNB-CU-UP#1. In addition, gNB-CU- CP may also provide gNB-CU-UP#2 with the UP TNL information at gNB-CU-UP#1 in step 870. Alternatively, the UP TNL information at gNB-CU-UP#1 can be provided by a separate signaling.

In step 880, gNB-CU-UP#2 responds to gNB-CU-CP with local switch indication (or UE group ID) , neighbor gNB-CU-UP ID (s) and the corresponding UP TNL information (s) at UP#2 side, for example,

Local switch indication (or UE group ID#1)

gNB-CU-UP#1, UP TNL information at UP#2 side

In step 890, gNB-CU-CP provides gNB-CU-UP#1 with local switch indication (or UE group ID) , neighbor gNB-CU-UP ID (s) and the associated UP TNL information at UP#2 side.

As a whole, a General Packet Radio Services (GPRS) Tunneling Protocol User Plane (GTP-U) tunnel between gNB-CU-UP#1 and gNB-CU-UP#2 is established in the granularity of UE group level. That is, all UE group transmissions within the UE group are transmitted over the same GTP-U tunnel.

In the above steps 850 and 870, a list of UE address (es) or UE ID (s) is provided. In addition, a GTP-U tunnel between gNB-CU-UP#1 and gNB-CU-UP#2 is established in the granularity of UE group. Alternatively, a GTP-U tunnel between gNB-CU-UP#1 and gNB-CU-UP#2 can be established in the granularity of UE as follows if there are multiple (e.g., two) UEs (e.g., UE#A and UE#B) connected to gNB-CU-UP#2:

Local switch indication (UE group ID#1)

gNB-CU-UP#2

UE address#1 of UE#A, UP TNL information#1 at UP#1 side

UE address#2 of UE#B, UP TNL information#2 at UP#1 side

Figure 9 illustrates a second procedure 900 of local switch via RAN node, in which the RAN node can be gNB-CU-CP shown in Figure 3 (c) .

In step 910, gNB-DU#1 forwards UL packets from UE#1 (e.g., C/M) toward gNB-CU-UP#1 through GTP-U tunnel between them, which is in the granularity of DRB level.

In step 920, gNB-CU-UP#1 identifies UE UP ID (of UE#1) , PDU session ID and DRB ID. gNB-CU-UP#1 may further acquire QFI contained in SDAP layer. gNB-CU-UP#1 decides to perform local switch via RAN node for the UL packets based on UE UP ID, PDU session ID and QFI. Alternatively, gNB-CU-UP#1 decides to perform local switch via RAN node based on target UE address or UE ID (i.e., UE address or UE ID of UE#2) , which is acquired from IP header (Option#21) or protocol header (Option#22) described in step 720. Based on information provided by gNB-CU-CP in step 850, gNB-CU-UP#1 determines the serving gNB-CU-UP (i.e., gNB-CU-UP#2) of the target UE#2 (e.g., S/A#2) and the corresponding UP TNL information at gNB-CU-UP#2 side. If gNB-CU-CP provides gNB-CU-UP#1 with the QFI associated with the UE address in step 850, then gNB-CU-UP#1 determines the QFI for the packet directly based on the target UE address. If gNB-CU-CP provides gNB-CU-UP#1 with multiple QFIs and the associated QoS requirements in step 850, gNB-CU-UP#1 determines QoS requirement as described in step 720 based on QFI (s) of the UL packets, and determines QFIs for the packets towards gNB-CU-UP#2 based on the QoS requirements.

In step 930, gNB-CU-UP#1 inserts QFI (s) and UE ID (optional) into the GTP-U header of the packets. The packets are sent from gNB-CU-UP#1 to gNB-CU-UP#2 through the GTP-U tunnel established for the UE group transmission.

In step 940, gNB-CU-UP#2 determines UE group ID based on the GTP-U tunnel from which gNB-CU-UP#2 receives the packets. The gNB-CU-UP#2 obtains the target UE address (e.g., UE address of UE#2) from IP header or Ethernet header. Alternatively, gNB-CU-UP#2 obtains UE ID contained in GTP-U header. gNB-CU-UP#2 determines UE#2 (e.g., S/A#2) ’s C-RNTI based on either UE address or UE ID.

In step 950, gNB-CU-UP#2 determines target UE’s DRB to forward the packets from UE#1 based on QFI (s) contained in GTP-U header.

In the third embodiment, the two RAN nodes (e.g., RAN node#1 and RAN node#2) that have Xn interface can be implemented as gNB#1 and gNB#2 shown in Figure 4 (a) , or gNB-CU#1 and gNB-CU#2 shown in Figure 4 (b) , or gNB-CU-CP#1 and gNB-CU-CP#2 shown in Figure 4 (c) .

In the condition that at least one UE, e.g., UE#1 (e.g., C/M) , is served by RAN node#1 (e.g., gNB#1 as shown in Figure 4 (a) or gNB-CU#1 as shown in Figure 4 (b) ) , and at least one UE, e.g., UE#2 (e.g., S/A#2) , is served by RAN node#2 (e.g., gNB#2 as shown in Figure 4 (a) or gNB-CU#2 as shown in Figure 4 (b) ) , when both UE#1 and UE#2 have performed the PDU session Establishment or Modification procedure, SMF determines, in step 510, local switch via RAN node (e.g., gNB#1 and gNB#2) and transmit, in step 520, for UE#1 to RAN node#1, and for UE#2 to RAN node#2, the local switch indication (or UE group ID) , RAN node IDs (e.g., RAN node#1 and RAN node#2) and a list of UE addresses or UE IDs of each RAN node ID, where each UE address or UE ID is associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Accordingly, both RAN node#1 and RAN node#2 decide to perform local switch via RAN node. For example, RAN node#1 decides to perform local switch via RAN node (i.e., via gNB#1 and gNB#2 in Figure 4 (a) , or via gNB-CU#1 and gNB-CU#2 in Figure 4 (b) ) for the UL packets sent by UE#1 (e.g., C/M) to UE#2 (e.g., S/A#2) .

A GTP-U tunnel for UE group transmission shall be established between RAN node#1 and RAN node#2. For example, RAN node#2 provides RAN node#1 with UE group ID and UP TNL information at RAN node#2. If SMF does not provide QoS requirement associated with QFI in step 520, then QoS requirement may be provided between RAN node#1 and RAN node#2 when GTP-U tunnel is established between RAN node#1 and RAN node#2.

Figure 10 illustrates a third procedure 1000 of local switch via RAN node, in which RAN node#1 can be gNB#1 shown in Figure 4 (a) or gNB-CU#1 shown in Figure 4 (b) and RAN node#2 can be gNB#2 shown in Figure 4 (a) or gNB-CU#2 shown in Figure 4 (b) .

In step 1010, UL packets are sent from UE#1 (e.g., C/M) to RAN node#1. In condition of Figure 4 (a) , the UL packets are sent to gNB#1. In condition of Figure 4 (b) , the packets are sent via gNB-DU#1 to gNB-CU#1.

In step 1020, RAN node#1 (e.g., gNB#1 or gNB-CU#1) decides to perform local switch via RAN node for the UL packets sent by UE#1. RAN node#1 obtains target UE address or UE ID (i.e., UE address or UE ID of UE#2) contained in UL packets. RAN node#1 determines that the target UE (i.e., UE#2) is served by RAN node#2 based on the information provided by SMF in step 520. RAN node#1 inserts QFI in the GTP-U header of the packet.

In step 1030, RAN node#1 forwards the packets via GTP-U tunnel established for UE group transmission to RAN node#2.

In step 1040, RAN node#2 obtains target UE address contained in the packets, and determines target UE (UE#2) ’s C-RNTI and PDU session ID. RAN node#2 determines the DL QoS DRB directly or based on the QoS requirement based on UE address or a combination of UE address and QFI (s) .

In step 1050, RAN node#2 forwards the DL packets to UE#2. In condition of Figure 4 (a) , the packets are sent from gNB#2 to UE#2 (S/A#2) . In condition of Figure 4 (b) , the packets are sent from gNB-CU#2 via gNB-DU#2 to UE#2 (S/A#2) .

In the condition that at least one UE, e.g., UE#1 (e.g., C/M) , is served by RAN node#1 (e.g., gNB-CU-CP#1 as shown in Figure 4 (c) ) , and at least one UE, e.g., UE#2 (e.g., S/A#2) , is served by RAN node#2 (e.g., gNB-CU-CP#2 as shown in Figure 4 (c) ) , when both UE#1 and UE#2 have performed the PDU session Establishment or Modification procedure, SMF determines, in step 510, local switch via RAN node for the serving RAN nodes (e.g., gNB-CU-UP#1 and gNB-CU-UP#2) and transmit, in step 520, for UE#1 to RAN node#1 (e.g., gNB-CU-CP#1) , and for UE#2 to RAN node#2 (e.g., gNB-CU-CP#2) , the local switch indication (or UE group ID) , RAN node IDs (e.g., RAN node#1 and RAN node#2) and a list of UE addresses or UE IDs of each RAN node ID, where each UE address or UE ID is associated with PDU session ID or with a combination of PDU session ID and QFI (s) . Accordingly, both RAN node#1 and RAN node#2 decide to perform local switch via RAN node. For example, RAN node#1 decides to perform local switch via RAN node (i.e., via gNB-CU-UP#1 and gNB-CU-UP#2 in Figure 4 (c) ) for the UL packets sent by UE#1 (e.g., C/M) to UE#2 (e.g., S/A#2) .

To enable local switch via RAN node for both gNB-CU-UP#1 and gNB-CU-UP#2 in Figure 4 (c) , a GTP-U tunnel shall be established between gNB-CU-UP#1 and gNB-CU-UP#2. This can be done by communicating the UP TNL information at UP#1 and UP TNL information at UP#2, e.g., by gNB-CU-CP#1 and gNB-CU-CP#2.

The local switch via RAN node procedure in which the RAN node is both gNB-CU-CP#1 and gNB-CU-CP#2 shown in Figure 4 (c) is substantially the same as the procedure 900, except that the gNB-CU-UP#1 is managed by gNB-CU-CP#1 and the gNB-CU-UP#2 is managed by gNB-CU-CP#2.

Incidentally, in Figure 4 (c) , there is only one gNB-CU-UP (i.e., gNB-CU-UP #1) in gNB-CU#1, and there is only one gNB-CU-UP (i.e., gNB-CU-UP#2) in gNB-CU#2. It is possible that there are multiple gNB-CU-UPs in gNB-CU#1 and there are multiple gNB-CU-UPs in gNB-CU#2. In this condition, a GTP-U tunnel shall be established between each pair of two gNB-CU-UPs where one of the gNB-CU-UPs is in gNB-CU#1 and the other of the gNB-CU-UPs is in gNB-CU#2.

Figure 11 is a schematic flow chart diagram illustrating an embodiment of a method 1100 according to the present application. In some embodiments, the method 1100 is performed by a network function such as an SMF or a network function with an SMF. In certain embodiments, the method 1100 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 1100 may comprise: 1102 determining to perform local switch via RAN node for a PDU session or a combination of the PDU session and QoS flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QFI; and 1104 transmitting, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .

In some embodiment, the method further comprises transmitting, to the serving RAN node of the UE, a UE address or UE ID of the UE.

In some embodiment, the method comprises determining to perform local switch via RAN node based on indication of local switch via RAN node associated with the UE group contained in one of the UE’s subscription data from UDM, the UE’s policy information from PCF, and pre-configuration from OAM.

In some embodiment, the method comprises determining to perform local switch via RAN node if the serving RAN node of the UE supports local switch via RAN node.

In some embodiment, the method comprises transmitting, to the RAN node of the UE, neighbor RAN node IDs and a list of UE address (es) or UE ID (s) associated with each neighbor RAN node ID. The method may further comprises transmitting, to the serving RAN node of the UE, a list of QFIs associated with each UE.

Figure 12 is a schematic flow chart diagram illustrating an embodiment of a method 1200 according to the present application. In some embodiments, the method 1200 is performed by a network node such as a control plane of a centralized unit of a RAN node (e.g. NG-RAN node) . In certain embodiments, the method 1200 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method 1200 may comprise 1202 receiving, from a SMF, a local switch indication or a UE group ID and a UE address or a UE ID of a UE within a UE group, wherein the local switch indication or the UE group ID and the UE address or UE ID is associated with a PDU session ID or with a combination of the PDU session ID and QFI (s) ; and 1204 transmitting, to a UP of the CU of the RAN node, the local switch indication or the UE group ID and the UE address or the UE ID of the UE within the UE group, and the associated PDU session ID.

In some embodiment, the method further comprises transmitting, to the UP of the CU of the RAN node, the QFI (s) of the associated PDU session ID.

In some embodiment, the method comprises transmitting, to the UP of the CU of the RAN node, UP IDs of the CU of the RAN node and a list of UE address (es) or UE ID(s) associated with each UP ID of the CU of the RAN node.

In some embodiment, the method further comprises receiving, from the UP of the CU of the RAN node, UP TNL information related to each UP of other UP (s) of the CU of the RAN node.

Figure 13 is a schematic block diagram illustrating apparatuses according to one embodiment.

The network function or network node or network entity (e.g. SMF or control plane of centralized unit of RAN node) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are proposed in Figure 11 or 12.

SMF comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to determine to perform local switch via RAN node for a PDU session or a combination of the PDU session and QoS flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QFI; and transmit, via the transceiver, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .

The control plane of a centralized unit of RAN node comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to receive, via the transceiver, from a SMF, a local switch indication or a UE group ID and a UE address or a UE ID of a UE within a UE group, wherein the local switch indication or the UE group ID and the UE address or UE ID is associated with a PDU session ID or with a combination of the PDU session ID and QFI (s) ; and transmit, via the transceiver, to a UP of the CU of the RAN node, the local switch indication or the UE group ID and the UE address or the UE ID of the UE within the UE group, and the associated PDU session ID.

Layers of a radio interface protocol may be implemented by the processors. 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.

Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects to be only illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

A session management function (SMF) of a network architecture, comprising:

a processor; and

a transceiver coupled to the processor,

wherein the processor is configured to

determine to perform local switch via Radio Access Network (RAN) node for a Protocol Data Unit (PDU) session or a combination of the PDU session and Quality of Service (QoS) flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QoS flow ID (QFI) ; and

transmit, via the transceiver, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .
The SMF of claim 1, wherein, the processor is configured to further transmit, via the transceiver, to the serving RAN node of the UE, a UE address or UE ID of the UE.
The SMF of claim 1, wherein, the processor is configured to determine to perform local switch via RAN node based on indication of local switch via RAN node associated with the UE group contained in one of the UE’s subscription data from Unified Data Management (UDM) , the UE’s policy information from Policy Control Function (PCF) , and pre-configuration from Operations and Maintenance (OAM) .
The SMF of claim 1, wherein, the processor is configured to determine to perform local switch via RAN node if the serving RAN node of the UE supports local switch via RAN node.
The SMF of claim 1, wherein, the processor is configured to transmit, via the transceiver, to the RAN node of the UE, neighbor RAN node IDs and a list of UE address (es) or UE ID(s) associated with each neighbor RAN node ID.
The SMF of claim 5, wherein, the processor is configured to further transmit, via the transceiver, to the serving RAN node of the UE, a list of QFIs associated with each UE.
A method performed at a session management function (SMF) , comprising:

determining to perform local switch via Radio Access Network (RAN) node for a Protocol Data Unit (PDU) session or a combination of the PDU session and Quality of Service (QoS) flow (s) , wherein the PDU session has an PDU session ID associated with an UE within a UE group having a UE group ID, and each QoS flow has a QoS flow ID (QFI) ; and

transmitting, to a serving RAN node of the UE, a local switch indication or the UE group ID associated with PDU session ID or with a combination of the PDU session ID and QFI (s) .
A control plane (CP) of a centralized unit (CU) of a Radio Access Network (RAN) node of a network architecture, comprising:

a processor; and

a transceiver coupled to the processor,

wherein the processor is configured to

receive, via the transceiver, from a session management function (SMF) , a local switch indication or a UE group ID and a UE address or a UE ID of a UE within a UE group, wherein the local switch indication or the UE group ID and the UE address or UE ID is associated with a PDU session ID or with a combination of the PDU session ID and Quality of Service (QoS) Flow ID (s) (QFI (s) ) ; and

transmit, via the transceiver, to a user plane (UP) of the CU of the RAN node, the local switch indication or the UE group ID and the UE address or the UE ID of the UE within the UE group, and the associated PDU session ID.
The CP of the CU of the RAN node of claim 8, wherein, the processor is further configured to

transmit, via the transceiver, to the UP of the CU of the RAN node, the QFI (s) of the associated PDU session ID.
The CP of the CU of the RAN node of claim 8, wherein, the processor is configured to transmit, via the transceiver, to the UP of the CU of the RAN node, UP IDs of the CU of the RAN node and a list of UE address (es) or UE ID (s) associated with each UP ID of the CU of the RAN node.
The CP of the CU of the RAN node of claim 8, wherein, the processor is further configured to:

receive, via the transceiver, from the UP of the CU of the RAN node, UP Transport Network Layer (TNL) information related to each UP of other UP (s) of the CU of the RAN node.