WO2018167359A1

WO2018167359A1 - Methods and apparatuses for multiplexing of service flows from different network slices into a radio bearer

Info

Publication number: WO2018167359A1
Application number: PCT/FI2018/050161
Authority: WO
Inventors: Vinh Van Phan; Ling Yu; Diomidis Michalopoulos; Peter Rost; Mark Doll
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2017-03-17
Filing date: 2018-03-06
Publication date: 2018-09-20

Abstract

Systems, methods, apparatuses, and computer program products for multiplexing of service flows from different network slices into a radio bearer are provided. One method includes PDCP multiplexing of different service flows from different network slice instances on a configured radio bearer between PDCP peer entities of a radio access network and a user equipment (UE), and configuring at least one of a NSI-SF ID and a RAN-NSI ID for the UE.

Description

METHODS AND APPARATUSES FOR MULTIPLEXING OF SERVICE FLOWS FROM DIFFERENT NETWORK SLICES INTO A RADIO

BEARER

BACKGROUND:

Field:

[0001] Embodiments of the invention generally relate to wireless or mobile communications networks, such as, but not limited to, the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE- A), LTE-A Pro, and/or 5G radio access technology or new radio access technology (NR). Some embodiments may generally relate to radio access network level support of network slicing.

Description of the Related Art:

[0002] Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) refers to a communications network including base stations, or Node Bs, and for example radio network controllers (RNC). UTRAN allows for connectivity between the user equipment (UE) and the core network. The RNC provides control functionalities for one or more Node Bs. The RNC and its corresponding Node Bs are called the Radio Network Subsystem (RNS). In case of E-UTRAN (enhanced UTRAN), no RNC exists and radio access functionality is provided by an evolved Node B (eNodeB or eNB) or many eNBs. Multiple eNBs are involved for a single UE connection, for example, in case of Coordinated Multipoint Transmission (CoMP) and in dual connectivity.

[0003] Long Term Evolution (LTE) or E-UTRAN refers to improvements of the UMTS through improved efficiency and services, lower costs, and use of new spectrum opportunities. In particular, LTE is a 3GPP standard that provides for uplink peak rates of at least, for example, 75 megabits per second (Mbps) per carrier and downlink peak rates of at least, for example, 300 Mbps per carrier. LTE supports scalable carrier bandwidths from 20 MHz down to 1.4 MHz and supports both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD).

[0004] As mentioned above, LTE may also improve spectral efficiency in networks, allowing carriers to provide more data and voice services over a given bandwidth. Therefore, LTE is designed to fulfill the needs for high-speed data and media transport in addition to high capacity voice support. Advantages of LTE include, for example, high throughput, low latency, FDD and TDD support in the same platform, an improved end-user experience, and a simple architecture resulting in low operating costs.

[0005] Certain releases of 3GPP LTE (e.g., LTE Rel-10, LTE Rel-1 1, LTE Rel-12, LTE Rel-13) are targeted towards international mobile telecommunications advanced (IMT-A) systems, referred to herein for convenience simply as LTE- Advanced (LTE-A).

[0006] LTE- A is directed toward extending and optimizing the 3 GPP LTE radio access technologies. A goal of LTE-A is to provide significantly enhanced services by means of higher data rates and lower latency with reduced cost. LTE-A is a more optimized radio system fulfilling the international telecommunication union-radio (ITU-R) requirements for IMT-Advanced while maintaining backward compatibility. One of the key features of LTE-A, introduced in LTE Rel-10, is carrier aggregation, which allows for increasing the data rates through aggregation of two or more LTE carriers.

[0007] 5^th generation (5G) or new radio (NR) wireless systems refer to the next generation (NG) of radio systems and network architecture. 5G is expected to provide higher bitrates and coverage than the current LTE systems. It is estimated that 5G will provide bitrates one hundred times higher than LTE offers. 5G is also expected to increase network expandability up to hundreds of thousands of connections. The signal technology of 5G is anticipated to be improved for greater coverage as well as spectral and signaling efficiency. 5G is expected to deliver extreme broadband and ultra-robust, low latency connectivity and massive networking to support the Internet of Things (IoT). With IoT and machine-to- machine (M2M) communication becoming more widespread, there will be a growing need for networks that meet the needs of lower power, low data rate, and long battery life. In 5G or NR, the node B or eNB may be referred to as a next generation node B (gNB).

SUMMARY:

[0008] One embodiment is directed to a method including packet data convergence protocol (PDCP) multiplexing of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE). The method may then include configuring at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE. The NSI-SF ID is used to identify a SF corresponding to a NSI for the UE, the RAN-NSI ID is used to identify a corresponding NSI in RAN level signalling for the UE, and the NSI-SF ID or network slice instance service flow specific packet sequence number (NSI-SF SN) of a SF being multiplexed in the configured RB is included in a header of one or more PDCP protocol data units (PDUs) sent on the configured RB.

[0009] Another embodiment is directed to an apparatus, which may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to packet data convergence protocol (PDCP) multiplex of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE), and to configure at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE. The NSI-SF ID is used to identify a SF corresponding to a NSI for the UE, the RAN-NSI ID is used to identify a corresponding NSI in RAN level signalling for the UE, and the NSI-SF ID or network slice instance service flow specific packet sequence number (NSI-SF SN) of a SF being multiplexed in the configured RB is included in a header of one or more PDCP protocol data units (PDUs) sent on the configured RB.

[0010] Another embodiment is directed to an apparatus, which may include multiplexing means for packet data convergence protocol (PDCP) multiplexing of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE), and configuring means for configuring at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE. The NSI-SF ID is used to identify a SF corresponding to a NSI for the UE, the RAN-NSI ID is used to identify a corresponding NSI in RAN level signalling for the UE, and the NSI-SF ID or network slice instance service flow specific packet sequence number (NSI-SF SN) of a SF being multiplexed in the configured RB is included in a header of one or more PDCP protocol data units (PDUs) sent on the configured RB.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0011] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[0012] Fig. 1 illustrates an example of a PDCP structure for PDCP multiplexing of SFs from different NSIs into one RB, according to an embodiment;

[0013] Fig. 2 illustrates an example block diagram depicting the PDCP multiplexing of SFs from different NSIs into one RB, according to an embodiment;

[0014] Fig. 3 illustrates an example signaling diagram of adding a NSI-SF into a multiplexing RB, according to an embodiment;

[0015] Fig. 4 illustrates an example signaling diagram of SN mapping inquiry procedure of PDCP, according to an embodiment;

[0016] Fig. 5 illustrates a block diagram depicting an embodiment to cover NSI specific C-plane RRC (RRC Slice), according to an embodiment; [0017] Fig. 6a illustrates an example block diagram of an apparatus, according to an embodiment;

[0018] Fig. 6b illustrates an example block diagram of an apparatus, according to another embodiment;

[0019] Fig. 7a illustrates an example flow chart of a method, according to an embodiment; and

[0020] Fig. 7b illustrates an example flow chart of a method, according to another embodiment.

DETAILED DESCRIPTION:

[0021] It will be readily understood that the components of the invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of systems, methods, apparatuses, and computer program products for multiplexing of service flows from different network slices into a radio bearer, as represented in the attached figures and described below, is not intended to limit the scope of the invention but is representative of selected embodiments of the invention.

[0022] The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of the phrases "certain embodiments," "some embodiments," or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases "in certain embodiments," "in some embodiments," "in other embodiments," or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. [0023] Additionally, if desired, the different functions discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions may be optional or may be combined. As such, the following description should be considered as merely illustrative of the principles, teachings and embodiments of this invention, and not in limitation thereof.

[0024] Certain embodiments relate to radio access network (RAN) level support of network slicing. Network slicing has been considered as one of the most important issues for 5G network systems in 3GPP, listed as the first among over 20 prioritized key issues in 3GPP technical report (T ) 23.799 2.0.0 released in December 2016. 3GPP TR 23.799 captures the current study on architecture for next generation systems in 3 GPP SA2. The agreements on support of network slicing are summarized in 3GPP TR 23.799 section 8 and the contents thereof are incorporated herein by reference in their entirety.

[0025] As outlined in 3GPP TR 23.799, a network slice is a complete logical network (providing telecommunication services and network capabilities) including access network (AN) and core network (CN). The agreements provided from 3GPP TR 23.799 include that AN can be common to multiple network slices, network slices may differ for features supported and Network Functions optimisations use cases, and networks may deploy multiple network slice instances delivering exactly the same optimisations and features but dedicated to different groups of UEs, e.g., as they deliver a different committed service and/or because they may be dedicated to a customer.

[0026] A UE may provide network slice selection assistance information (NSSAI) including a set of parameters to the network to select the set of RAN and CN part of the network slice instances (NSIs) for the UE. The NSSAI can have standard values or public land mobile network (PLMN) specific values. The NSSAI (which may be used to select the common control network functions (CCNF)) is a collection of SM-NSSAIs, each allowing the network to select a particular slice. The UE may store a configured and/or accepted NSSAI per PLMN. The configured NSSAI may be a NSSAI configured by default in a UE to be used in a PLMN before any interaction with the PLMN ever takes place. The accepted NSSAI may be the NSSAI used by the UE after the PLMN has accepted an attach request from the UE. The attach accept message may include the accepted NSSAI, and the accepted NSSAI may be updated by MM procedures.

[0027] A UE may access multiple slices simultaneously via a single RAN. In such a case, those slices may share some control plane functions, e.g., access and mobility management function (AMF) and network slice instance selection function. These common functions are collectively identified as common control network functions (CCNF). The UE may need to be able to associate an application with one out of multiple parallel established protocol data unit (PDU) sessions. Different PDU sessions may belong to different slices.

[0028] RAN level support of network slicing is still rather undeveloped in 3GPP. However, based on the above agreements on support of network slicing in 3 GPP so far, RAN level support of network slicing is expected to at least facilitate the case where a UE is having different PDU sessions, also referred to as service flows (SF) herein, from different network slices being served by the same gNB on the same carrier. In this case, provided that a UE may be provided with a limited number of radio bearers (RBs) including signalling RBs (SRB) and data RBs (DRB) for the sake of scalability and inter-operability, packet data convergence protocol (PDCP) multiplexing of SFs from different network slices, which have more or less the same quality of service (QoS) requirements from RAN perspective, into one RB is one of potential options. The PDCP multiplexing option also has minimum impact on the lower layer RAN protocol stack and therefore requires a least amount of standardization and implementation efforts for RAN.

[0029] Fig. 1 and Fig. 2 illustrate examples of PDCP structure and operation behind PDCP multiplexing of SFs from 3 different network slice instances (NSI) into one configured RB for radio packet transmission between a given UE and a serving RAN. More specifically, Fig. 1 illustrates an example of a PDCP structure for PDCP multiplexing of SFs from different NSIs into one RB. Fig. 2 illustrates an example diagram depicting the PDCP multiplexing of SFs from different NSIs into one B.

[0030] It is assumed that the multiplexing function of PDCP (PDCP MUX in Fig.2), based on pre-configured properties of individual SFs from corresponding individual slice-specific control entities coupled with pre-configured QoS scheduling rules applied on the RB across all the multiplexed SFs, is able to sort out and maintain the first-in first-out (FIFO) order of incoming packets from the individual SFs (FIFO queue after PDCP multiplexing in Fig.2) for transmitting on the multiplexing RB. It is noted that at least a RB wise sequence number (SN) and sufficient multiplexing control information per a PDCP PDU are provided to facilitate, for example, duplication-detected-and-discarded, lossless and in-order delivery for the RB as well as de-multiplexing and routing of individual PDCP PDUs received on the RB for the belonging individual SFs and serving NSIs.

[0031] It is also expected that RAN should be able to support NSI specific configurations and functions to be applied on individual SF of serving NSI. For example, QoS and security context of a SF can be specific to serving NSI. In this regard, the PDCP multiplexing option is to facilitate NSI specific configurations and functions on a corresponding SF and therefore maintain NSI specific contexts of individual SFs. NSI specific contexts, related to QoS and ciphering on PDCP level, may include, for example, SN of packets per individual multiplexed SF and specified requirements in terms of duplication-detected-and-discarded, lossless and in-order delivery and latency.

[0032] It is further expected that the given UE may be served in multi- connectivity and the multiplexing RB may be split and served by different access nodes. Hence, the receiving peer may receive PDCP PDUs in different orders from different serving access nodes (due to different delays thereof). The in-sequence delivery operation of the multiplexing RB based on RB wise SN (RB-SN) overall may cause unnecessary delay to some of the individual multiplexed NSI-SFs. Hence, it is beneficial that the receiving peer may be able to check and proceed with in-sequence delivery for at least some determined or prioritized NSI-SF without further delay.

[0033] One embodiment, looking into details of PDCP, is directed to a method to enable PDCP multiplexing of SFs from different network slices into a RB with minimized protocol overhead and optimized operation of individual multiplexed NSI-SFs. An embodiment is also directed to a possible extension to enable slice- specific RRC functions and procedures, referred to as RRC Slice, to be multiplexed and signalled over a common SRB for a UE.

[0034] In current cellular networks, such as LTE, setting up a bearer service comprising an EPC bearer and a corresponding RB for a UE is initiated from the core network (CN), such as Mobility Management Entity (MME) in LTE. The setting-up refers to general network control of bearer services including initial configuration and reconfiguration of a bearer service. In this regard, whereas setting up a SF for a UE may be initiated from a corresponding NSI, setting up the multiplexing RB may be initiated from the common control network functions (CCNF) across all involved serving NSIs of which SFs are to be carried over the multiplexing RB for the UE. In an alternative, setting up the multiplexing RB may be delegated to the common serving RAN or gNB. That is, the common serving RAN or gNB may determine to configure and control the multiplexed RB based on bearer service configuration and control initiated from individual serving NSIs. .

[0035] The PDCP multiplexing option requires that NSI specific contexts of individual SFs being multiplexed in the configured RB are applied and maintained. To enable and facilitate that, one possible solution is to have ID and SN per a NSI specific SF, denoted as NSI-SF ID and NSI-SF SN, included in the control header of individual PDCP PDUs being transmitted on the configured RB, in addition to SN of the configured RB, denoted as RB SN. Note that RB ID may be omitted from the header of PDCP PDU as in LTE, assuming that there is 1 : 1 mapping between a RB and a logical channel (LC) of MAC and LC ID is included in the header of MAC PDU. However, this solution requires that the header of individual PDCP PDU carries two SN fields plus a NSI-SF ID, even when there is no actual multiplexing of different SFs from different NSIs, or no such multiplexing takes place on the RB, resulting in high protocol overhead. It should be noted that if NSI-SFs are always independent and PDCP ciphering is always NSI specific then RB-SN may not be needed. In this case, PDCP is operating on individual NSI-SFs.

[0036] In view of the above, one embodiment provides configuration of NSI-SF ID to be used for addressing a multiplexed SF in the multiplexing RBwith zero signalling overhead. In an embodiment, there is one NSI-SF from each NSI being multiplexed into the configured multiplexing RB and NSI-SF ID is configured implicitly. That is, no additional signalling overhead is needed by setting the value of NSI-SF ID to a specified RAN level identifier or index of the corresponding NSI, referred to as RAN-NSI-ID. RAN-NSI-ID can be derived from the pre-configured or accepted NSSAI of the given UE and unique to the given UE and the configured RB. The NSI-SF ID may be included in the header of PDCP PDUs transmitted on the configured RB only when actual multiplexing of different SFs from different NSIs is taking place on the configured RB.

[0037] In one embodiment, UE specific RAN-NSI-ID may be configured and used for, for instance, identifying the corresponding network slice on RAN level in all relevant RAN level signalling for the given UE. RAN-NSI-ID may be either implicitly or explicitly configured for the given UE. In the implicit option, RAN- NSI-ID can be uniquely mapped or derived from, for example, unique identity of the corresponding NSI specific to the given UE. For example, RAN-NSI-ID may be realized with, for instance, 4 bits (provided that UE may be allowed to have access to a maximum of 16 different NSIs) and the value of RAN-NSI-ID may be set to the increasing decimal order of the given unique identities of the corresponding NSIs within the pre-configured or accepted NSSAI of the given UE, starting from, say, 1 to 10, provided that a maximum of 10 different NSI-SFs may be multiplexed into one RB for the given UE. The values of 0 and 1 1 to 15 can be reserved for, e.g., specified common purpose slices including no-slicing option.

[0038] For one example in which the given UE has the pre-configured or accepted NSSAI comprised of 2 particular NSIs, RAN-NSI-IDs of those 2 particular NSIs for the given UE will be 1 and 2. Notice that this particular example implies that RAN-NSI-ID is UE specific, depending on the pre-configured or accepted NSSAI of the given UE. That is, RAN-NSI-ID of the same NSI may take different values from one UE to another UE. In case that the serving RAN has explicit knowledge beforehand about which NSIs the serving RAN is providing services for or serving, the serving RAN may explicitly configure RAN-NSI-IDs of those NSIs commonly applied to all relevant UEs and indicate that to all relevant UEs using either common broadcast signalling or dedicated signalling. In this case, NSI-SF ID, as set to NSI-RAN ID when being used on the multiplexing RB, from the same NSI is identical across different relevant UEs.

[0039] In another embodiment, a RRC RB Reconfiguration message from the serving RAN to the given UE for adding or removing a NSI specific SF to or from the configured RB may cause PDCP peers of the RB to change PDU format, regarding if actual multiplexing is taking place or not. For reassuring the synchronization between the sending and receiving PDCP peers upon changing PDU format, the sending side may issue a C-PDU to indicate a start of using the updated PDCP format. Referring to the example illustrated in Fig. 2, the first 3 PDUs from NSI-SF#1 may be transmitted with non-multiplexing format and then multiplexing format may be applied from RB SN=3 onward.

[0040] Fig. 3 illustrates an example of a signalling diagram for a RB reconfiguration procedure to add NSI-SF#2 to be multiplexed into the existing RB carrying NSI-SF#1, in accordance with some embodiments. As illustrated in Fig. 3, as depicted in 310, RAN-NSI-IDs may be mapped on a preconfigured or accepted NSSAI, and NSI-SF#1 is carried on the configured RB as depicted in 320. In an embodiment, RRC of RAN 301 may reconfigure PDCP at 330. Then, at 340, RAN 301 may transmit a RB reconfiguration to UE 300 to add NSI-SF#2 to the configured RB. It is noted that, in other embodiments, the RB reconfiguration may be to remove a NSI-SF from the configured RB. In response to receiving the RB reconfiguration, at 350, RRC of UE 300 may reconfigure the PDCP. In addition, at 360, RAN 301 may transmit a PDCP C-PDU on the configured RB to UE 300 to indicate a start of using the updated PDCP format. At 370, UE 300 may initiate use of the updated PDCP format with RB-SN=3 mapped on NSI-SF#2 SN=0. Then, at 380, NSI-SF#1 and NSI-SF#2 may be multiplexed on the RB in DL.

[0041] Another embodiment facilitates efficient maintaining of NSI specific contexts on PDCP, in particular SN of packets per a multiplexed SF, for an optimized delivery of individual SFs over the multiplexing RB. This embodiment is based on exploring trade-offs between using explicit per-PDU signalling (control elements included in the header of each PDU) and once-off C-/U-plane control signalling procedures (RRC message or PDCP C-PDU) when needed instead of per- PDU signalling of certain control elements. Thus, PDCP peer-to-peer entities of the multiplexing RB may maintain in-sequence delivery for each multiplexed SF without providing NSI-SF ID and/or NSI-SF SN in the header of each and every PDCP PDU but only selected PDCP PDUs. In an embodiment, the NSI-SF ID and/or NSI-SF SN of a SF being multiplexed in the configured RB is not included in a header of each PDCP PDU, but is included in one or more selected PDCP PDUs of the corresponding SF sent on the configured RB. Some alternatives are discussed below. It is noted that certain hybrid combinations of these alternatives are also possible.

[0042] In one embodiment, explicit NSI-SF ID but implicit or no NSI-SF SN may be included in the header of individual PDCP PDUs. The NSI-SF SN may be maintained and synchronized between the sending and receiving PDCP peers in the given UE and the serving RAN with simple and effective once-off C-plane or U- plane signalling procedures as follows.

[0043] According to an embodiment, an initiation or update of the SN mapping between RB SN and NSI-SF SN may be signalled from the sending PDCP peer to the receiving PDCP peer using either RRC signalling such as RRC RB Reconfiguration or PDCP C-PDU. As an example, this message indicates, for instance, RB-SN=3 is mapped on NSI-SF#2 SN=0; RB-SN=9 is mapped on NSI- SF#1 SN=4, as for the example shown in Fig. 2. It is noted that RRC RB Reconfiguration may be issued by the serving RAN to reconfigure a RB for both UL and DL. Hence, for UL transmissions in which the sending peer is the given UE, the indication of the initial or updated SN mapping may be sent by the given UE in response to C RB Reconfiguration from the serving RAN.

[0044] According to an embodiment, the receiving peer may issue an inquiry of the SN mapping of a particular in-order but out-of-sequence received PDCP PDU, the inquiry may include at least RB-SN of the PDCP PDU and the response from the sending peer may include at least the NSI-SF ID and NSI-SF SN of the inquired PDCP PDU. The inquiry and the response may be realized using U-plane PDCP in- band control procedure with corresponding PDCP C-PDUs introduced or C-plane RRC signalling. The latter option may indicate the corresponding RB ID or LC ID as well. This embodiment is to facilitate that the receiving peer may be able to check and proceed with the in-sequence delivery for at least some determined NSI- SF without further delay.

[0045] In another embodiment, a 1 bit flag may be introduced to indicate whether the given PDCP PDU RB-SN=n is of the same NSI-SF (Flag=0) or not (Flag=l) as that of the previous PDCP PDU RB-SN=n-l . In the example shown in Fig. 2, PDUs with SN=0, 3, 5, 7, 9 have Flag=l . It should be noted that this type of 1 bit Flag may also be introduced to any of the embodiments or alternatives discussed above. In an example embodiment, a flag=l indication may be followed by a SN-Delta pointing to the last PDU SN that belongs to the same NSI SF. In the example shown in Fig. 2, PDU with RB-SN=9 will have SN-Delta=7 pointing to the last PDU RB- SN=2 of the same NSI-SF#1. SN-Delta allows that, for example, if RB-SN=8 and RB-SN=9 in Fig. 2 are received while RB-SN=7 is still missing, then RB-SN=8 should be buffered for in-order delivery of NSI-SF#2 but SN=9 could be delivered right away for NSI-SF#1. NSI-SF ID is assumed to be associated with at least some selected PDU of a NSI-SF within a SN-Delta space (the first PDU with Flag=l , SN- Delta=0 for example). In another option, all PDUs with Flag=l include NSI-SF ID.

[0046] In another embodiment, the NSI-SF-ID and NSI-SF SN may not be included in the header of each and every PDCP PDU but: i) only included in selected PDCP PDU, or ii) indicated by a C-PDU. When the NSI-SF-ID and NSI-SF SN are included in selected PDCP PDU, the first PDCP PDU in the sequence of PDCP PDUs of the same SF may attach NSI-SF ID and NSI-SF SN in the PDU header. The NSI specific SN of the following PDUs can be derived accordingly. For this, two PDCP PDU header types with and without NSI specific control elements may be provided. If the first PDU with NSI-SF SN and NSI-SF ID is lost, the PDCP receiving peer entity, denoted as PDCP x, may not know the following sequence of PDUs are for the new NSI SF. In this case, the PDCP Rx should be able to detect the loss of the first PDU by in-order but not in-sequence received PDUs. This may then trigger sending a C-PDU to request a synchronization of NSI SF specific SN and common PDCP SN, i.e., RB wise SN, from the PDCP transmitting peer entity, denoted as PDCP Tx.

[0047] When the NSI-SF-ID and NSI-SF SN is indicated by a C-PDU, the PDCP Tx may send C-PDU every time before the PDU from different NSI. This compares to the C-PDU of the previous PDU, and is transmitted to inform the PDCP Rx to receive the PDCP PDU and derive the NSI specific SN for the right NSI-SF.

[0048] Due to the introduction of PDCP PDU header with NSI specific information or C-PDU for the first PDU in the sequence of PDUs of the same NSI SF, the protocol overhead becomes higher if the number of PDUs in the sequence of the same NSI SF is small, highest if the sequence is comprised of only one PDU. Therefore, this option may be more optimized when being coupled with some predefined multiplexing patterns. For example, a PDCP PDU pattern may be configured for multiplexed NSI-SF PDUs to allow the PDCP Tx and PDCP Rx to synchronize NSI specific SN from common PDCP SN or, i.e., RB wise SN. For example, the pattern may be configured with length of N, PDCP SN mod N = 0, 1,..., X-l may be configured for NSI-SF#1, PDCP SN mod N = X, X+l,..., Y-l may be configured for NSI-SF#2 and PDCP SN mod N= Y, Y+l,..., N-l may be configured for NSI-SF#3.

[0049] In an embodiment, the NSI specific PDCP entity may fill the common PDCP buffer with the PDUs according to the configured pattern. If there is no PDCP PDU from one NSI-SF to fill the buffer according to the configured pattern, it can be either filled with PDCP PDU header only PDU or filled with PDCP C- PDU in the PDCP Tx to indicate the missing of PDCP PDUs of the NSI-SF so that the PDCP Rx can derive the PDCP PDU and corresponding NSI specific SN for the right NSI SF. If there is temporarily more PDCP PDUs from one NSI-SF and less PDCP PDUs from another NSI-SF than that according to the configured pattern, another C-PDU may be provided to allow to use the configured PDCP PDUs' portion of one NSI in the configured pattern for another NSI. For example, after X PDCP PDUs from NSI-SF#1, C-PDU may be transmitted to indicate to the PDCP Rx that the following Y-X PDUs are also for NSI-SF#1 instead of NSI-SF#2.

[0050] Fig. 4 illustrates an example signaling diagram of an inquiry of the SN mapping of a particular in-order but out-of-sequence received PDCP PDU, in accordance with some embodiments. In this example, it is assumed that the UE receives PDCP PDU of RB-SN=9 but has not received PDCP PDUs of RB-SN=6, 7, 8; and the RB is configured for delay sensitive services. It is noted that, for a high-reliable but delay tolerable RB, the UE may be configured to proceed with the configured RB wise (common PDCP) reordering window and not need to consider advancing for individual NSI-SFs. In this case, there may be no need for initiating on-the-fly inquiry of a certain received out-of-sequence PDU.

[0051] In the example of Fig. 4, as depicted in 410, RAN-NSI-IDs may be mapped on a preconfigured or accepted NSSAI, and NSI-SF#1 and NS-SF#2 are multiplexed on the configured RB as depicted in 420. AT 430, UE 400 may determine an inquiry of SN mapping of PDCP PDU RB-SN=9. Then, at 440, UE 400 may transmit a C-PDU with RB-SN=9 to RAN 401. In response to receiving the C-PDU from UE 400, RAN 401 may transmit a C-PDU indicating NSI-SF#1 and SN=3. After receiving the C-PDU from RAN 401, UE 400 may determine to advance NSI-SF#1 to NAS without further delay.

[0052] Fig. 5 illustrates a block diagram depicting a further embodiment to cover RRC Slice multiplexing on a common SRB. Option (a) illustrated in Fig. 5 is to have PDCP multiplexing of RRC_Slice# on a specified SRB directly. This option can be realized using some embodiments directly. Option (b) illustrated in Fig. 5 makes NSI specific C internal to RRC and hidden from PDCP. In option (b), RRC may be responsible for addressing NSI specific RRC information elements (IE) or messages (PDU).

[0053] Fig. 6a illustrates an example of an apparatus 10 according to an embodiment. In an embodiment, apparatus 10 may be a node, host, or server in a communications network or serving such a network. For example, apparatus 10 may be a base station, a node B, an evolved node B, 5G node B or access point, next generation node B (NG-NB or gNB), WLAN access point, mobility management entity (MME), or subscription server associated with a radio access network, such as a GSM network, LTE network or 5G radio access technology. It should be noted that one of ordinary skill in the art would understand that apparatus 10 may include components or features not shown in Fig. 6a.

[0054] As illustrated in Fig. 6a, apparatus 10 may include a processor 12 for processing information and executing instructions or operations. Processor 12 may be any type of general or specific purpose processor. While a single processor 12 is shown in Fig. 6a, multiple processors may be utilized according to other embodiments. In fact, processor 12 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[0055] Processor 12 may perform functions associated with the operation of apparatus 10 which may include, for example, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 10, including processes related to management of communication resources.

[0056] Apparatus 10 may further include or be coupled to a memory 14 (internal or external), which may be coupled to processor 12, for storing information and instructions that may be executed by processor 12. Memory 14 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 14 can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, hard disk drive (HDD), or any other type of non-transitory machine or computer readable media. The instructions stored in memory 14 may include program instructions or computer program code that, when executed by processor 12, enable the apparatus 10 to perform tasks as described herein.

[0057] In some embodiments, apparatus 10 may also include or be coupled to one or more antennas 15 for transmitting and receiving signals and/or data to and from apparatus 10. Apparatus 10 may further include or be coupled to a transceiver 18 configured to transmit and receive information. The transceiver 18 may include, for example, a plurality of radio interfaces that may be coupled to the antenna(s) 15. The radio interfaces may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, radio frequency identifier (RFID), ultrawideband (UWB), and the like. The radio interface may include components, such as filters, converters (for example, digital-to-analog converters and the like), mappers, a Fast Fourier Transform (FFT) module, and the like, to generate symbols for a transmission via one or more downlinks and to receive symbols (for example, via an uplink). As such, transceiver 18 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) 15 and demodulate information received via the antenna(s) 15 for further processing by other elements of apparatus 10. In other embodiments, transceiver 18 may be capable of transmitting and receiving signals or data directly.

[0058] In an embodiment, memory 14 may store software modules that provide functionality when executed by processor 12. The modules may include, for example, an operating system that provides operating system functionality for apparatus 10. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 10. The components of apparatus 10 may be implemented in hardware, or as any suitable combination of hardware and software.

[0059] In certain embodiments, apparatus 10 may be a network node or RAN node, such as a base station, access point, node B, eNB, 5G node B (gNB) or access point, WLAN access point, or the like. According to certain embodiments, apparatus 10 may be controlled by memory 14 and processor 12 to perform the functions associated with embodiments described herein. For example, in certain embodiments, apparatus 10 may be configured to facilitate multiplexing of SFs from different network slices at PDCP sublayer into a RB.

[0060] In one embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to PDCP multiplex of different SFs from different NSIs on a configured radio bearer (RB) between PDCP peer entities of a RAN and a user equipment (UE), and to configure a NSI-SF ID and/or a RAN-NSI ID for the UE. The NSI-SF ID may be used to identify service flow corresponding to the network slice for the given UE, and the RAN-NSI-ID may be used to identify the corresponding network slice on RAN level in all relevant RAN level signalling for the given UE. In one embodiment, NSI-SF ID of a SF being multiplexed in a configured RB is set to RAN-NSI ID of the corresponding NSI. In one embodiment, the NSI-SF ID may be included in the header of one or more PDCP PDUs transmitted on the configured RB when, or only when, actual multiplexing of different SFs from different NSIs is taking place on the configured RB.

[0061] According to an embodiment, when adding or removing a NSI specific SF to or from the configured RB may cause PDCP peers of the RB to change PDU format, apparatus 10 may be controlled by memory 14 and processor 12 to issue or transmit a C-PDU to indicate a start of using the updated PDCP format.

[0062] In an embodiment, apparatus 10 may be controlled by memory 14 and processor 12 to either implicitly or explicitly configure the RAN-NSI-ID for the UE. In the implicit option, the RAN-NSI-ID may be uniquely mapped or derived from, for example, the unique identity of the corresponding NSI specific to the UE. For instance, the RAN-NSI-ID may be derived from the pre-configured or accepted NSSAI of the UE, and is unique to the UE and the configured RB. As one example, RAN-NSI-ID is realized with, say, 4 bits and the value of RAN-NSI-ID is set to the increasing decimal order of the given unique identities of the corresponding NSIs within the pre-configured or accepted NSSAI of the given UE, starting from, say, 1 to 10, provided that a maximum of 10 different NSI-SFs may be multiplexed into 1 RB for the given UE. The values of 0 and 1 1 to 15 may be reserved, for example, for specified common purpose slices including no-slicing option.

[0063] In another embodiment, for example in case that the apparatus 10 has explicit knowledge beforehand about which NSIs apparatus 10 is providing services for or serving, apparatus 10 may be controlled by memory 14 and processor 12 to explicitly configure RAN-NSI-IDs of those NSIs commonly applied to all relevant UEs and indicate that to all relevant UEs using either common broadcast signalling or dedicated signalling. In this case, NSI-SF ID, as set to NSI-RAN ID of the corresponding NSI when being used on the multiplexing RB, from the same NSI may be identical across different relevant UEs.

[0064] According to one embodiment, apparatus 10 may be further controlled by memory 14 and processor 12 to transmit a RRC RB reconfiguration message to the UE. For example, apparatus 10 may be further controlled by memory 14 and processor 12 to transmit a RRC RB reconfiguration to the UE for adding or removing a NSI specific SF to or from the configured RB which may cause PDCP peers of the RB to change PDU format, regarding if actual multiplexing is taking place or not. For supporting the synchronization between the PDCP of apparatus 10 and PDCP of the UE upon changing PDU format, apparatus 10 may be controlled by memory 14 and processor 12 to issue the C-PDU to indicate the start of using the updated PDCP format, as discussed above.

[0065] In an embodiment, apparatus 10 may be further controlled by memory 14 and processor 12 to set the NSI-SF ID to the RAN-NSI ID. According to certain embodiments, apparatus 10 may also be controlled by memory 14 and processor 12 to multiplex at least two SFs from different network slices into the RB. PDCP peer- to-peer entities of the multiplexing RB may maintain in-sequence delivery for each multiplexed SF without providing NSI-SF ID and/or NSI-SF SN in the header of each and every PDCP PDU but only selected PDCP PDUs,

[0066] In some embodiments, explicit NSI-SF ID but implicit or no NSI-SF SN are included in the header of individual PDCP PDUs. NSI-SF SN is maintained and synchronized between the sending and receiving PDCP peers in the UE and the apparatus 10 with effective once-off C-plane or U-plane signalling procedures. For example, in one embodiment, apparatus 10 may be further controlled by memory 14 and processor 12 to signal the initiation or update of the SN mapping between RB SN and NSI-SF SN from the PDCP peer of apparatus to the PDCP peer of the UE using either RRC signalling such as RRC RB Reconfiguration or PDCP C-PDU. As one example, this message may indicate, for instance, RB-SN=3 is mapped on NSI- SF#2 SN=0; RB-SN=9 is mapped on NSI-SF#1 SN=4, as shown in the example of Fig. 2. The RRC RB reconfiguration may be issued by apparatus 10 to reconfigure a RB for both UL and DL. Hence, for UL transmissions in which the sending peer is the UE, the indication of the initial or updated SN mapping may be sent by the UE in response to RRC RB Reconfiguration from apparatus 10.

[0067] According to an embodiment, the UE (i.e., receiving peer of SF in the downlink for example) may issue an inquiry of the SN mapping of a particular in- order but out-of-sequence received PDCP PDU. In one embodiment, the inquiry may include at least RB-SN of the PDCP PDU. Apparatus 10 may then be controlled by memory 14 and processor 12 to send a response that may include at least NSI-SF ID and NSI-SF SN of the inquired PDCP PDU. The inquiry and the response may be realized, for example, using PDCP in-band control procedure with corresponding PDCP C-PDUs introduced or RRC signalling. The RRC signalling option may include an indication of the corresponding RB ID or LC ID as well. This embodiment is to facilitate that the UE may be able to check and proceed with the in-sequence delivery for at least some determined NSI-SF without further delay.

[0068] In another embodiment, apparatus 10 may be further controlled by memory 14 and processor 12 to introduce a 1-bit flag to indicate whether the given PDCP PDU B-SN=n is of the same NSI-SF (Flag=0) or not (Flag=l) as that of the previous PDCP PDU RB-SN=n-l . In one embodiment, when Flag=l (i.e., the PDCP PDU RB-SN=n is not of the same NSI-SF), it may be followed by a SN-Delta pointing to the last PDU SN that belongs to the same NSI SF.

[0069] According to certain embodiments, the NSI-SF-ID and NSI-SF SN are not included in the header of each and every PDCP PDU but are (a) included only in selected PDCP PDU or (b) indicated by a C-PDU. In an embodiment, a PDCP PDU pattern is configured for multiplexed NSI-SF PDUs to allow the PDCP Tx (e.g., apparatus 10) and PDCP Rx (e.g., UE) to synchronize NSI specific SN from common PDCP SN. The NSI specific PDCP entity may then fill the common PDCP buffer with the PDUs according to the pattern.

[0070] Fig. 6b illustrates an example of an apparatus 20 according to another embodiment. In an embodiment, apparatus 20 may be a node or element in a communications network or associated with such a network, such as a UE, mobile equipment (ME), mobile station, mobile device, stationary device, IoT device, or other device. As described herein, UE may alternatively be referred to as, for example, a mobile station, mobile equipment, mobile unit, mobile device, user device, subscriber station, wireless terminal, tablet, smart phone, IoT device or NB- IoT device, or the like. As one example, Apparatus 20 may be implemented in, for instance, a wireless handheld device, a wireless plug-in accessory, or the like.

[0071] In some example embodiments, apparatus 20 may include one or more processors, one or more computer-readable storage medium (for example, memory, storage, and the like), one or more radio access components (for example, a modem, a transceiver, and the like), and/or a user interface. In some embodiments, apparatus 20 may be configured to operate using one or more radio access technologies, such as GSM, NB-IoT, LTE, LTE-A, 5G, WLAN, WiFi, Bluetooth, NFC, and any other radio access technologies. It should be noted that one of ordinary skill in the art would understand that apparatus 20 may include components or features not shown in Fig. 6b. [0072] As illustrated in Fig. 6b, apparatus 20 may include or be coupled to a processor 22 for processing information and executing instructions or operations. Processor 22 may be any type of general or specific purpose processor. While a single processor 22 is shown in Fig. 6b, multiple processors may be utilized according to other embodiments. In fact, processor 22 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application- specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[0073] Processor 22 may perform functions associated with the operation of apparatus 20 including, without limitation, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 20, including processes related to management of communication resources.

[0074] Apparatus 20 may further include or be coupled to a memory 24 (internal or external), which may be coupled to processor 22, for storing information and instructions that may be executed by processor 22. Memory 24 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 24 can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, or any other type of non-transitory machine or computer readable media. The instructions stored in memory 24 may include program instructions or computer program code that, when executed by processor 22, enable the apparatus 20 to perform tasks as described herein.

[0075] In some embodiments, apparatus 20 may also include or be coupled to one or more antennas 25 for receiving a downlink signal and for transmitting via an uplink from apparatus 20. Apparatus 20 may further include a transceiver 28 configured to transmit and receive information. The transceiver 28 may also include a radio interface (e.g., a modem) coupled to the antenna 25. The radio interface may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, LTE-A, 5G, WLAN, Bluetooth, BT-LE, NFC, FID, UWB, and the like. The radio interface may include other components, such as filters, converters (for example, digital-to-analog converters and the like), symbol de-mappers, signal shaping components, an Inverse Fast Fourier Transform (IFFT) module, and the like, to process symbols, such as OFDMA symbols, carried by a downlink or an uplink.

[0076] For instance, transceiver 28 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) 25 and demodulate information received via the antenna(s) 25 for further processing by other elements of apparatus 20. In other embodiments, transceiver 28 may be capable of transmitting and receiving signals or data directly. Apparatus 20 may further include a user interface, such as a graphical user interface or touchscreen.

[0077] In an embodiment, memory 24 stores software modules that provide functionality when executed by processor 22. The modules may include, for example, an operating system that provides operating system functionality for apparatus 20. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 20. The components of apparatus 20 may be implemented in hardware, or as any suitable combination of hardware and software.

[0078] According to one embodiment, apparatus 20 may be a UE, mobile device, mobile station, ME, IoT device and/or NB-IoT device, for example. According to certain embodiments, apparatus 20 may be controlled by memory 24 and processor 22 to perform the functions associated with embodiments described herein. In an embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to configure a NSI-SF ID and/or a RAN-NSI ID for apparatus 20. According to one embodiment, apparatus 20 may also be controlled by memory 24 and processor 22 to set the NSI-SF ID to the RAN-NSI ID. [0079] As outlined above, in one example embodiment, RAN-NSI-IDs may be mapped on a preconfigured or accepted NSSAI, and NSI-SF#1 may be carried on the configured RB. In an embodiment, RRC of RAN may reconfigure PDCP and apparatus 20 may be controlled by memory 24 and processor 22 to receive a RB reconfiguration from RAN to add or remove a NSI-SF to or from the configured RB. As one example, apparatus 20 may be controlled by memory 24 and processor 22 to receive a RB reconfiguration from RAN to add NSI-SF#2 to the configured RB. In response to receiving the RB reconfiguration, apparatus 20 may be controlled by memory 24 and processor 22 to reconfigure the PDCP. In addition, apparatus 20 may be controlled by memory 24 and processor 22 to receive a C-PDU from RAN to indicate a start of using the updated PDCP format. In an embodiment, apparatus 20 may then be controlled by memory 24 and processor 22 to initiate use of the updated PDCP format, for example, with RB-SN=3 mapped on NSI-SF#2 SN=0. Then, NSI-SF#1 and NSI-SF#2 may be multiplexed on the RB in DL.

[0080] In another example embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to receive PDCP PDU of RB-SN=n (e.g., RB-SN=9) but has not received PDCP PDUs of RB-SN=n-l, n-2, n-3 (e.g., RB-SN=6, 7, 8); and the RB is configured for delay sensitive services. It is noted that, for a high- reliable but delay tolerable RB, apparatus 20 may be controlled by memory 24 and processor 22 to proceed with the configured RB wise reordering window and not need to consider advancing for individual NSI-SFs. In this case, there may be no need for initiating on-the-fly inquiry of a certain received out-of-sequence PDU. In an example embodiment, RAN-NSI-IDs may be mapped on a preconfigured or accepted NSSAI, and NSI-SF#1 and NS-SF#2 are multiplexed on the configured RB. According to an embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to determine an inquiry of SN mapping of PDCP PDU RB-SN=9. Then, apparatus 20 may be controlled by memory 24 and processor 22 to may transmit a C-PDU with RB-SN=n to RAN. Then, apparatus 20 may be controlled by memory 24 and processor 22 to receive a C-PDU from RAN indicating NSI-SF#1 and SN=3. After receiving the C-PDU from RAN, apparatus 20 may be controlled by memory 24 and processor 22 to determine to advance NSI-SF#1 to NAS without further delay. Thus, in an embodiment, apparatus 20 may be controlled by memory 24 and processor 22 to issue an inquiry of the SN mapping of a particular in-order but out-of-sequence received PDCP PDU. The inquiry and the response may be realized using PDCP in-band control procedure with corresponding PDCP C-PDUs introduced or RRC signalling.

[0081] Fig. 7a illustrates an example of a flow diagram for a method for multiplexing of SFs from different network slices at PDCP sublayer into a RB, according to one embodiment. In an embodiment, the method of Fig. 7a may be performed by a network node, such as a base station, eNB, or gNB. In another embodiment, the method of Fig. 7a may be performed by a UE, mobile station, IoT device, or the like. According to an , the method may include, at 700, configuring a NSI-SF ID and/or a RAN-NSI ID for a UE. The NSI-SF ID may be used to identify service flow corresponding to the network slice for the giving UE, and the RAN- NSI-ID may be used to identify the corresponding network slice on RAN level in all relevant RAN level signalling for the given UE. In one embodiment, the NSI-SF ID may be included in the header of one or more PDCP PDUs transmitted on the configured RB when, or only when, actual multiplexing of different SFs from different NSIs is taking place on the configured RB.

[0082] In an embodiment, the method may include, at 710, setting the NSI-SF ID to the RAN-NSI ID. In an embodiment, the configuring may include either implicitly or explicitly configuring the RAN-NSI-ID for the UE. In the implicit option, the RAN-NSI-ID may be uniquely mapped or derived from, for example, the unique identity of the corresponding NSI specific to the UE. For instance, the RAN- NSI-ID may be derived from the pre-configured or accepted NSSAI of the UE, and is unique to the UE and the configured RB. As one example, RAN-NSI-ID is realized with, say, 4 bits and the value of RAN-NSI-ID is set to the increasing decimal order of the given unique identities of the corresponding NSIs within the pre-configured or accepted NSSAI of the given UE, starting from, say, 1 to 10, provided that a maximum of 10 different NSI-SFs may be multiplexed into 1 RB for the given UE. The values of 0 and 1 1 to 15 may be reserved, for example, for specified common purpose slices including no-slicing option.

[0083] In another embodiment, for example in case that the network node has explicit knowledge beforehand about which NSIs the network node is providing services for or serving, the configuring may include explicitly configuring RAN- NSI-IDs of those NSIs commonly applied to all relevant UEs and indicate that to all relevant UEs using either common broadcast signalling or dedicated signalling. In this case, NSI-SF ID from the same NSI may be identical across different relevant UEs.

[0084] According to one embodiment, the method may include, at 720, transmitting a RRC RB reconfiguration message to the UE. For example, the transmitting may include transmitting a RRC RB reconfiguration to the UE for adding or removing a NSI specific SF to or from the configured RB which may cause PDCP peers of the RB to change PDU format, regarding if actual multiplexing is taking place or not. For supporting the synchronization between the PDCP of the network node and PDCP of the UE upon changing PDU format, according to an embodiment, when adding or removing a NSI specific SF to or from the configured RB may cause PDCP peers of the RB to change PDU format, the method may include, at 730, issuing or transmitting a C-PDU to indicate a start of using the updated PDCP format.

[0085] According to certain embodiments, the method may also include, at 740, PDCP multiplexing of at least two different SFs from different NSIs on the configured RB between PDCP peer entities of a RAN and the UE. It is noted that in certain embodiments the multiplexing step 740 may be performed prior to the configuring step 700. The PDCP peers of the RB may maintain in-sequence delivery for each multiplexed SF without providing NSI-SF ID and/or NSI-SF SN in the header of each and every PDCP PDU but only selected PDCP PDUs, In some embodiments, explicit NSI-SF ID but implicit or no NSI-SF SN are included in the header of individual PDCP PDUs. NSI-SF SN is maintained and synchronized between the sending and receiving PDCP peers in the UE and the network node with effective once-off C-plane or U-plane signalling procedures. For example, in one embodiment, the method may further include signaling the initiation or update of the SN mapping between RB SN and NSI-SF SN from the PDCP peer to the PDCP peer of the UE using either RRC signalling such as RRC RB Reconfiguration or PDCP C-PDU. As one example, this message may indicate, for instance, RB- SN=3 is mapped on NSI-SF#2 SN=0; RB-SN=9 is mapped on NSI-SF#1 SN=4, as shown in the example of Fig. 2. The RRC RB reconfiguration may be issued by apparatus 10 to reconfigure a RB for both UL and DL. Hence, for UL transmissions in which the sending peer is the UE, the indication of the initial or updated SN mapping may be sent by the UE in response to RRC RB Reconfiguration from the network node.

[0086] According to an embodiment, the UE (i.e., receiving peer of SF in the downlink for example) may issue an inquiry of the SN mapping of a particular in- order but out-of-sequence received PDCP PDU. In one embodiment, the inquiry may include at least RB-SN of the PDCP PDU. The method may then include sending a response that may include at least NSI-SF ID and NSI-SF SN of the inquired PDCP PDU. The inquiry and the response may be realized, for example, using PDCP in-band control procedure with corresponding PDCP C-PDUs introduced or RRC signalling. The RRC signalling option may include an indication of the corresponding RB ID or LC ID as well. This embodiment is to facilitate that the UE may be able to check and proceed with the in-sequence delivery for at least some determined NSI-SF without further delay.

[0087] In another embodiment, the method may include providing a 1-bit flag to indicate whether the given PDCP PDU RB-SN=n is of the same NSI-SF (Flag=0) or not (Flag=l) as that of the previous PDCP PDU RB-SN=n-l . In one embodiment, when Flag=l (i.e., the PDCP PDU RB-SN=n is not of the same NSI-SF), it may be followed by providing a SN-Delta pointing to the last PDU SN that belongs to the same NSI SF.

[0088] According to certain embodiments, the NSI-SF-ID and NSI-SF SN are not included in the header of each and every PDCP PDU but are (a) included only in selected PDCP PDU or (b) indicated by a C-PDU. In an embodiment, a PDCP PDU pattern is configured for multiplexed NSI-SF PDUs to allow the PDCP Tx (e.g., network node) and PDCP Rx (e.g., UE) to synchronize NSI specific SN from common PDCP SN. The NSI specific PDCP entity may then fill the common PDCP buffer with the PDUs according to the pattern.

[0089] Fig. 7b illustrates an example of a flow diagram of a method, according to another embodiment. In an embodiment, the method of Fig. 7b may be performed by a device, such as a UE, mobile station, and/or IoT device for example. According to an embodiment, the method may include, 750, receiving a RB reconfiguration from RAN to add or remove a NSI-SF to or from the configured RB. As one example, the receiving may include receiving a RB reconfiguration from RAN to add NSI-SF#2 to the configured RB. In response to receiving the RB reconfiguration, the method may include, at 760, reconfiguring the PDCP. In addition, the method may also include, at 770, receiving a C-PDU from RAN to indicate a start of using the updated PDCP format. In an embodiment, the method may also include, at 780, initiating use of the updated PDCP format, for example, with RB-SN=3 mapped on NSI-SF#2 SN=0. Then, NSI-SF#1 and NSI-SF#2 may be multiplexed on the RB in DL.

[0090] In one embodiment, the method may also include configuring a NSI-SF ID and/or a RAN-NSI ID for the UE. In addition, the method may include setting the NSI-SF ID to the RAN-NSI ID.

[0091] In another example embodiment, the method may include receiving PDCP PDU of RB-SN=n (e.g., RB-SN=9) but has not received PDCP PDUs of RB-SN=n- 1, n-2, n-3 (e.g., RB-SN=6, 7, 8); and the RB is configured for delay sensitive services. It is noted that, for a high-reliable but delay tolerable RB, the method may include proceeding with the configured RB wise reordering window and not need to consider advancing for individual NSI-SFs. In this case, there may be no need for initiating on-the-fly inquiry of a certain received out-of-sequence PDU. In an example embodiment, RAN-NSI-IDs may be mapped on a preconfigured or accepted NSSAI, and NSI-SF#1 and NS-SF#2 are multiplexed on the configured RB. According to an embodiment, the method may include determining an inquiry of SN mapping of PDCP PDU RB-SN=9. Then, the method may include transmitting a C-PDU with RB-SN=n to RAN, and receiving a C-PDU from RAN indicating NSI-SF#1 and SN=3. After receiving the C-PDU from RAN, the method may include determining to advance NSI-SF#1 to NAS without further delay. Thus, in an embodiment, the method may include issuing an inquiry of the SN mapping of a particular in-order but out-of-sequence received PDCP PDU. The inquiry and the response may be realized using PDCP in-band control procedure with corresponding PDCP C-PDUs introduced or RRC signalling.

[0092] In view of the above, embodiments of the invention provide several technical improvements and/or advantages. For example, certain embodiments provide ways to multiplex service flows from different network slices at PDCP sublayer into a radio bearer, especially for NSI-SF ID configuration and mapping between RB SN and NSI-SF ID and NSI-SF SN. As such, embodiments of the invention can improve performance and throughput of network nodes including, for example, base stations, eNBs, gNBs and/or UEs. Accordingly, the use of embodiments of the invention result in improved functioning of communications networks and their nodes.

[0093] In some embodiments, the functionality of any of the methods, processes, signaling diagrams, or flow charts described herein may be implemented by software and/or computer program code or portions of code stored in memory or other computer readable or tangible media, and executed by a processor.

[0094] In certain embodiments, an apparatus may be included or be associated with at least one software application, module, unit or entity configured as arithmetic operation(s), or as a program or portions of it (including an added or updated software routine), executed by at least one operation processor. Programs, also called computer program products or computer programs, including software routines, applets and macros, may be stored in any apparatus-readable data storage medium and include program instructions to perform particular tasks. [0095] A computer program product may comprise one or more computer- executable components which, when the program is run, are configured to carry out embodiments described herein. The one or more computer-executable components may include at least one software code or portions of code. Modifications and configurations required for implementing the functionality of an embodiment may be performed as routine(s), which may be implemented as added or updated software routine(s). In some embodiments, software routine(s) may be downloaded into the apparatus.

[0096] Software or a computer program code or portions of code may be in a source code form, object code form, or in some intermediate form, and may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and/or software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital device or it may be distributed amongst a number of devices or computers. The computer readable medium or computer readable storage medium may be a non-transitory medium.

[0097] In other embodiments, the functionality may be performed by hardware, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another embodiment, the functionality may be implemented as a signal, a non-tangible means that can be carried by an electromagnetic signal downloaded from the Internet or other network.

[0098] According to an embodiment, an apparatus, such as a node, device, or a corresponding component, may be configured as a computer or a microprocessor, such as single-chip computer element, or as a chipset, including at least a memory for providing storage capacity used for arithmetic operation(s) and an operation processor for executing the arithmetic operation. [0099] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

[00100] The project leading to this application has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 671584.

Claims

WE CLAIM:

1. A method, comprising:

packet data convergence protocol (PDCP) multiplexing of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE);

configuring at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE,

wherein the NSI-SF ID is used to identify a SF corresponding to a NSI for the UE,

wherein the RAN-NSI ID is used to identify a corresponding NSI in RAN level signalling for the UE,

wherein the NSI-SF ID or network slice instance service flow specific packet sequence number (NSI-SF SN) of a SF being multiplexed in the configured RB is included in a header of one or more PDCP protocol data units (PDUs) sent on the configured RB.

2. The method according to claim 1, further comprising transmitting a radio resource control (RRC) radio bearer (RB) reconfiguration to the user equipment to add or remove the network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB).

3. The method according to claim 1, further comprising receiving a radio resource control (RRC) radio bearer (RB) reconfiguration at the user equipment to add or remove the network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB).

4. The method according to any one of claims 1-3, wherein the configuring further comprises deriving the radio access network (RAN) network slice instance identification (RAN-NSI ID) from a unique identity of the corresponding network slice instance (NSI) specific to the user equipment.

5. The method according to any one of claims 1-3, wherein the configuring further comprises explicitly configuring the radio access network (RAN) network slice instance identification (RAN-NSI ID) of those network slice instances (NSIs) commonly applied to relevant user equipment and indicating the configured radio access network (RAN) network slice instance identification (RAN-NSI ID) to the relevant user equipment using common broadcast signalling or dedicated signalling.

6. The method according to any one of claims 1-5, further comprising setting the network slice instance service flow identification (NSI-SF ID) of a service flolw (SF) being multiplexed in the configured radio bearer (RB) to the radio access network (RAN) network slice instance identification (RAN-NSI ID) of the corresponding network slice instance (NSI).

7. The method according to any one of claims 1-6, wherein the network slice instance service flow identification (NSI-SF ID) is included in a header of one or more packet data convergence protocol (PDCP) protocol data units (PDUs) transmitted on the configured radio bearer (RB) when actual multiplexing of different service flows (SFs) from different network slice instances (NSIs) is taking place on the configured radio bearer (RB).

8. The method according to any one of claims 1-2 or 4-7, further comprising, when adding or removing a network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB) causes packet data convergence protocol (PDCP) peers of the radio bearer (RB) to change protocol data unit (PDU) format, transmitting a control protocol data unit (C-PDU) to the user equipment to indicate a start of using the updated protocol data unit (PDU) format.

9. The method according to any one of claims 1, 3, or 4-7, further comprising, when adding or removing a network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB) causes packet data convergence protocol (PDCP) peers of the radio bearer (RB) to change protocol data unit (PDU) format, receiving a control protocol data unit (C-PDU) at the user equipment to indicate a start of using the updated protocol data unit (PDU) format.

10. The method according to claim 1, wherein the network slice instance service flow identification (NSI-SF ID) and implicit or no network slice instance service flow sequence number (NSI-SF SN) are included in a header of individual packet data convergence protocol (PDCP) protocol data units (PDUs).

1 1. The method according to claim 10, further comprising signaling an initiation or update of the sequence number (SN) mapping between radio bearer sequence number (RB SN) and the network slice instance service flow sequence number (NSI-SF SN) from the packet data convergence protocol (PDCP) peer to the packet data convergence protocol (PDCP) peer of the user equipment.

12. The method according to claim 1 1, wherein the signaling is via radio resource control (RRC) signaling, PDCP C-PDU, or selected PDCP D-PDU.

13. The method according to claim 10, further comprising:

receiving, from the user equipment, an inquiry of the sequence number (SN) mapping of a particular in-order but out-of-sequence received packet data convergence protocol (PDCP) protocol data unit (PDU); and

sending a response including at least network slice instance service flow identification (NSI-SF ID) and network slice instance service flow sequence number (NSI-SF SN) of the inquired packet data convergence protocol (PDCP) protocol data unit (PDU).

14. The method according to claim 10, further comprising:

transmitting, by the user equipment, an inquiry of the sequence number (SN) mapping of a particular in-order but out-of-sequence received packet data convergence protocol (PDCP) protocol data unit (PDU); and

receiving a response including at least network slice instance service flow identification (NSI-SF ID) and network slice instance service flow sequence number (NSI-SF SN) of the inquired packet data convergence protocol (PDCP) protocol data unit (PDU).

15. The method according to any one of claims 1-14, further comprising:

providing a 1-bit flag to indicate whether a given packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer (RB)-sequence number (SN) is of the same network slice instance service flow (NSI-SF) or not as that of a previous packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer (RB)- sequence number (SN); and

when the given packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer (RB)-sequence number (SN) is not of the same network slice instance service flow (NSI-SF), providing a sequence number (SN)-Delta pointing to the last protocol data unit (PDU) sequence number (SN) that belongs to the same network slice instance service flow (NSI-SF).

16. The method according to claim 15, wherein the 1-bit flag and the SN-Delta are included in a context of PDCP.

17. The method according to any one of claims 10-16, wherein the NSI-SF ID and the NSI-SF SN is not included in the header of each and every PDCP PDU but is included in selected PDCP PDUs or indicated by a C-PDU.

18. The method according to any one of claims 10-17, further comprising configuring a PDCP PDU pattern for multiplexed NSI-SFs to allow the transmitting and receiving PDCP peer entities to synchronize network slice instance service flow sequence number (NSI-SF SN) from radio bearer (RB)-sequence number (SN), and PDCP PDUs of NSI-SFs are transmitted between the PDCP peer entities on the configured RB according to the pattern.

19. The method according to claim 1, wherein the method is performed by one of a network node or the user equipment.

20. An apparatus, comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to

packet data convergence protocol (PDCP) multiplex of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE);

configure at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE,

21. The apparatus according to claim 20, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to transmit a radio resource control (RRC) radio bearer (RB) reconfiguration to the user equipment to add or remove the network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB).

22. The apparatus according to claim 20, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to receive a radio resource control (RRC) radio bearer (RB) reconfiguration at the user equipment to add or remove the network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB).

23. The apparatus according to any one of claims 20-22, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to derive the radio access network (RAN) network slice instance identification (RAN-NSI ID) from a unique identity of the corresponding network slice instance (NSI) specific to the user equipment.

24. The apparatus according to any one of claims 20-22, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to explicitly configure the radio access network (RAN) network slice instance identification (RAN-NSI ID) of those network slice instances (NSIs) commonly applied to relevant user equipment and indicating the configured radio access network (RAN) network slice instance identification (RAN-NSI ID) to the relevant user equipment using common broadcast signalling or dedicated signalling.

25. The apparatus according to any one of claims 20-24, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to set the network slice instance service flow identification (NSI-SF ID) of a service flolw (SF) being multiplexed in the configured radio bearer (RB) to the radio access network (RAN) network slice instance identification (RAN-NSI ID) of the corresponding network slice instance (NSI).

26. The apparatus according to any one of claims 20-25, wherein the network slice instance service flow identification (NSI-SF ID) is included in a header of one or more packet data convergence protocol (PDCP) protocol data units (PDUs) transmitted on the configured radio bearer (RB) when actual multiplexing of different service flows (SFs) from different network slice instances (NSIs) is taking place on the configured radio bearer (RB).

27. The apparatus according to any one of claims 20, 21, or 23-26, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to, when adding or removing a network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB) causes packet data convergence protocol (PDCP) peers of the radio bearer (RB) to change protocol data unit (PDU) format, transmit a control protocol data unit (C-PDU) to the user equipment to indicate a start of using the updated protocol data unit (PDU) format.

28. The apparatus according to any one of claims 20, 22, or 23-26, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to, when adding or removing a network slice instance (NSI) specific service flow (SF) to or from the configured radio bearer (RB) causes packet data convergence protocol (PDCP) peers of the radio bearer (RB) to change protocol data unit (PDU) format, receive a control protocol data unit (C-PDU) at the user equipment to indicate a start of using the updated protocol data unit (PDU) format.

29. The apparatus according to claim 20, wherein the network slice instance service flow identification (NSI-SF ID) and implicit or no network slice instance service flow sequence number (NSI-SF SN) are included in a header of individual packet data convergence protocol (PDCP) protocol data units (PDUs).

30. The apparatus according to claim 29, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to signal an initiation or update of the sequence number (SN) mapping between radio bearer sequence number (RB SN) and the network slice instance service flow sequence number (NSI-SF SN) from the packet data convergence protocol (PDCP) peer to the packet data convergence protocol (PDCP) peer of the user equipment.

31. The apparatus according to claim 30, wherein the initiation or update of the SN mapping is signaled is via radio resource control (RRC) signaling, PDCP C-PDU, or selected PDCP D-PDU.

32. The apparatus according to claim 29, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to:

receive, from the user equipment, an inquiry of the sequence number (SN) mapping of a particular in-order but out-of-sequence received packet data convergence protocol (PDCP) protocol data unit (PDU); and

send a response including at least network slice instance service flow identification (NSI-SF ID) and network slice instance service flow sequence number (NSI-SF SN) of the inquired packet data convergence protocol (PDCP) protocol data unit (PDU).

33. The apparatus according to claim 29, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to:

transmit, by the user equipment, an inquiry of the sequence number (SN) mapping of a particular in-order but out-of-sequence received packet data convergence protocol (PDCP) protocol data unit (PDU); and

receive a response including at least network slice instance service flow identification (NSI-SF ID) and network slice instance service flow sequence number (NSI-SF SN) of the inquired packet data convergence protocol (PDCP) protocol data unit (PDU).

34. The apparatus according to any one of claims 20-33, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to:

provide a 1-bit flag to indicate whether a given packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer ( B)-sequence number (SN) is of the same network slice instance service flow (NSI-SF) or not as that of a previous packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer (RB)- sequence number (SN); and

when the given packet data convergence protocol (PDCP) protocol data unit (PDU) radio bearer (RB)-sequence number (SN) is not of the same network slice instance service flow (NSI-SF), provide a sequence number (SN)-Delta pointing to the last protocol data unit (PDU) sequence number (SN) that belongs to the same network slice instance service flow (NSI-SF).

35. The apparatus according to claim 34, wherein the 1-bit flag and the SN-Delta are included in a context of PDCP.

36. The apparatus according to any one of claims 29-35, wherein the NSI-SF ID and the NSI-SF SN is not included in the header of each and every PDCP PDU but is included in selected PDCP PDUs or indicated by a C-PDU.

37. The apparatus according to any one of claims 29-36, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to configure a PDCP PDU pattern for multiplexed NSI-SFs to allow the transmitting and receiving PDCP peer entities to synchronize network slice instance service flow sequence number (NSI-SF SN) from radio bearer ( B)-sequence number (SN), and PDCP PDUs of NSI-SFs are transmitted between the PDCP peer entities on the configured RB according to the pattern.

38. The apparatus according to claim 20, wherein the apparatus comprises one of a network node or the user equipment.

39. An apparatus, comprising:

means for packet data convergence protocol (PDCP) multiplexing of different service flows (SFs) from different network slice instances (NSIs) on a configured radio bearer (RB) between PDCP peer entities of a radio access network (RAN) and a user equipment (UE);

means for configuring at least one of a network slice instance service flow identification (NSI-SF ID) and a radio access network (RAN) network slice instance identification (RAN-NSI ID) for the UE,

40. A computer program, embodied on a non- transitory computer readable medium, wherein the computer program is configured to control a processor to perform a method according to any one of claims 1-19.