WO2023004771A1 - Method and device for handling control pdu during sdt - Google Patents

Abstract

Methods and devices for handling a control PDU in SDT are disclosed. In one embodiment, a method performed by a terminal device comprises: receiving a downlink (DL) data Packet Data Unit (PDU) from a network device; in response to determining that the control PDU is to be transmitted to the network device while the terminal device is in a non-Radio Resource Control (RRC) _CONNECTED state with the network device, determining whether a Data Radio Bearer (DRB) that carries the control PDU is a Small Data Transmission (SDT) DRB or not; in response to determining that the DRB is not a SDT DRB, constructing the control PDU for a Quality of Service (QoS) flow, mapping the control PDU to the DRB, and transmitting the control PDU via the DRB as SDT.

Description

METHOD AND DEVICE FOR HANDLING CONTROL PDU DURING SDT FIELD

The subject matter disclosed herein generally relates to wireless communications, and more particularly relates to method and apparatus for handling the control PDU in small data transmission (SDT) .

BACKGROUND

The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project (3GPP) , Fourth Generation (4G) , Fifth Generation (5G) , 5G Core (5GC) , New Radio (NR) , Very Large Scale Integration (VLSI) , Random Access Memory (RAM) , Read-Only Memory (ROM) , Erasable Programmable Read-Only Memory (EPROM or Flash Memory) , Compact Disc Read-Only Memory (CD-ROM) , Local Area Network (LAN) , Wide Area Network (WAN) , User Equipment (UE) , Evolved Node B (eNB) , Long Term Evolution (LTE) , Next Generation Node B (gNB) , Uplink (UL) , Downlink (DL) , Central Processing Unit (CPU) , Graphics Processing Unit (GPU) , Field Programmable Gate Array (FPGA) , Orthogonal Frequency Division Multiplexing (OFDM) , Radio Resource Control (RRC) , User Entity/Equipment (Mobile Terminal) , buffer status report (BSR) , power headroom report (PHR) small data transmission (SDT) , Medium Access Control (MAC) , MAC control element (MAC CE) , service data adaptation protocol (SDAP) , packet data convergence protocol (PDCP) , radio link control (RLC) , core network (CN) , control plane (CP) , data radio bearer (DRB) , logical channel priority (LCP) , non access stratum (NAS) , radio bearer (RB) , positioning reference signal (PRS) , signaling radio bearer (SRB) , long term evolution (LTE) , machine type communications (MTC) , massive machine type communications (mMTC) , Internet of things (IoT) , information element (IE) , dedicated control channel (DCCH) , common control channel (CCCH) , radio access network (RAN) , next-generation radio access network (NG-RAN) , ultra-reliable low-latency communication (URLLC) , access stratum (AS) , E-UTRAN new radio dual connectivity (EN-DC) , random access channel (RACH) , timing advance (TA) , protocol data unit (PDU) , tracking area update (TAU) , beam failure recovery (BFR) , listen-before-talk (LBT) , configured grant (CG) , radio resource control (RRC) , Quality of Service (QoS) , Reflective QoS flow to DRB mapping Indication (RDI) , Integrated Access and Backhaul (IAB) , Guaranteed Bit Rate (GBR) , Session Management  Function (SMF) , QoS Flow ID (QFI) , Policy and charging control (PCC) , User Plane Function (UPF) , Policy Control Function (PCF) , Evolved Packet System (EPS) , random access channel (RACH) , configured grant (CG) , Mobile originate (MO) , Mobile terminated (MT) , Ethernet Header Compression (EHC) , Robust Header Compression (ROHC) , RAN-based Notification Area Update (RNAU) , semi-persistent scheduling (SPS) , Reference Signal Received Power (RSRP) , Early Data Transmission (EDT) , Preconfigured Uplink Resources (PUR) .

3GPP has developed technologies for SDT to support data transmission without transitioning to an RRC connected state. 3GPP introduced EDT and PUR transmission technologies for 4G LTE in Release 15 and Release16, and SDT technology for 5G new radio (NR) in Release 17.

The SDT for 5G NR considers an RRC inactive state whose operation is also based on the suspension of an RRC connection and the resumption of an RRC connection. As compared to an RRC idle state, the RRC inactive state has different features such as radio access network (RAN) based notification area (RNA) , RAN paging, etc.

Both data radio bearer (DRB) and signaling radio bearer (SRB) are considered as bearers for SDT. For example, 3GPP considers that positioning/location information can be transmitted via the SRB based on the SDT for 5G NR.

Service Data Adaptation Protocol (SDAP) is a new layer of protocol added to the user plane of the 5G new air interface, which is located above the PDCP layer. The SDAP sublayer is configured through RRC signaling, and the SDAP sublayer is responsible for mapping the QoS flow to the corresponding DRB. One or more QoS flows can be mapped to the same DRB, and one QoS flow can only be mapped to one DRB.

In some cases, how to handle control PDU, e.g., end-marker control PDU during SDT according to whether the DRB to which the control PDU is mapped is a SDT DRB or a non-SDT DRB has not been defined clearly.

This invention discloses methods and apparatuses for handling control PDU in SDT to solve the above and other technical problems.

BRIEF SUMMARY

Methods and apparatuses for disabling uplink transmission within disabling period are disclosed.

In one embodiment, a method by a terminal device comprises: receiving a downlink (DL) data Packet Data Unit (PDU) from a network device; in response to determining that a control PDU is to be transmitted to the network device while the terminal device is in a non-Radio Resource Control (RRC) _CONNECTED state with the network device, determining whether a Data Radio Bearer (DRB) that carries the control PDU is a Small Data Transmission (SDT) DRB or not; in response to determining that the DRB is not a SDT DRB, constructing the control PDU for a Quality of Service (QoS) flow, mapping the control PDU to the DRB, and transmitting the control PDU via the DRB as SDT.

Preferably, the control PDU is generated from Access Stratum (AS) layer.

Preferably, the control PDU is considered as arrival of data for DRB for which SDT is enabled, if it is determined that the control PDU will be transmitted.

Preferably, the method further comprises: in response to determining that the DRB is a SDT DRB, mapping the control PDU to the DRB; and transmitting the control PDU via the DRB as SDT.

Preferably, determining whether the control PDU will be transmitted further comprises: determining that the control PDU will not be transmitted, if the terminal device determines that no out of order transmission will be occurred between DRBs.

Preferably, transmitting the control PDU via the DRB as SDT further comprises multiplexing the control PDU with other data on an ongoing SDT.

Preferably, transmitting the control PDU via the DRB as SDT further comprises: initiating a SDT if there is no ongoing SDT or if there is no other data corresponding to the arrival of SDT data, wherein the trigger condition for initiating the SDT is that the control PDU is constructed.

Preferably, in the case that the DRB is not a SDT DRB, transmitting the control PDU via the DRB as SDT comprises only transmitting the control PDU as SDT.

Preferably, the method further comprises resuming the DRB which carries the control PDU if the DRB is not a SDT DRB.

Preferably, the method further comprises suspending the DRB if the DRB is not a SDT DRB after the control PDU is transmitted.

In another embodiment, a terminal device comprises a transceiver; and a processor coupled to the transceiver and configured to perform the method disclosed above.

In still another embodiment, a method by a network device comprises: configuring an uplink (UL) Quality of Service (QoS) flow to Data Radio Bearer (DRB) mapping rule for a QoS flow or transmitting a downlink (DL) data Packet Data Unit (PDU) to a terminal device; receiving a control PDU for a QoS flow from the terminal device; delivering the control PDU to upper layer, wherein the control PDU is received as Small Data Transmission (SDT) , wherein the network device in a non-Radio Resource Control (RRC) _CONNECTED state with the terminal device, and wherein the method further comprising: restricting a QoS flow to DRB mapping rule for the QoS flow.

Preferably, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising: the QoS flow to DRB mapping rule is delivered before the terminal device is released to a non-Radio Resource Control (RRC) _CONNECTED state with the network device, or the QoS flow to DRB mapping rule is delivered before the RRC Release message is transmitted to the terminal device, or reflective QoS is not allowed to be applied to SDT DRBs, or the QoS flow to DRB mapping rule is not allowed to be changed during the SDT procedure of the terminal device.

Preferably, a RRC_CONNECTED state with the terminal device is resumed if the QoS flow to DRB mapping rule is to be changed.

In yet another embodiment, a network device comprises a transceiver; and a processor coupled to the transceiver and configured to perform the method disclosed above.

BRIEF DESCRIPTION OF THE DRAWINGS

A more particular description of the embodiments briefly described above will be rendered by refer 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:

Fig. 1 illustrates the RRC states in NR;

Fig. 2 illustrates the QoS architecture in 5G system;

Fig. 3 illustrates the SDAP structure in 5G system;

Fig. 4 illustrates the format of End-Marker Control PDU;

Fig. 5 illustrates a flowchart for a UE to handle the control PDU according to an embodiment; and

Fig. 6 is a schematic block diagram illustrating apparatuses according to an 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.

Reference will now be made in detail to some embodiments of the present application, examples of which are illustrated in the accompanying drawings. To facilitate  understanding, embodiments are provided under specific network architecture and new service scenarios, such as 3GPP 5G, 3GPP LTE, 3GPP NR-U, NR Radio Access operating with shared spectrum channel access and so on. It is contemplated that along with the developments of network architectures and new service scenarios, all embodiments in the present application are also applicable to similar technical problems. Moreover, the terminologies recited in the present application may change, which should not affect the principle of the present application. Embodiments of the present disclosure can also be applied to unlicensed spectrum scenario.

Fig. 1 illustrates the RRC states in NR.

The RRC protocol is used in the air interface. It exists only in the control plane, in the UE and in the gNB. The major functions of the RRC protocol include connection establishment and release functions, broadcast of system information, RB establishment, reconfiguration and release, RRC connection mobility procedures, paging notification and release and outer loop power control. By means of the signaling functions, the RRC configures the user and control planes according to the network status and allows for Radio Resource Management strategies to be implemented.

The behavior and functions of RRC are governed by the current state of RRC. In 5G NR, RRC has three distinct states: RRC_IDLE, RRC_CONNECTED and RRC_INACTIVE.

RRC_IDLE : Upon power on, UE enters into RRC_IDLE mode. UE may move to this mode from either RRC_CONNECTED mode or RRC_INACTIVE mode.

RRC_INACTIVE: UE moves to this mode from RRC_CONNECTED mode. It is connected but inactive mode of UE. In this mode, UE maintains RRC connection and at the same time minimizes signaling and power consumption.

RRC_CONNECTED: UE remains in connection with the 5G-RAN/5GC in this mode.

Since 5G caters to new cases such as mMTC and URLLC, RRC_INACTIVE has been introduced. While entering this state, both UE and NG-RAN save radio and security configurations. This saved UE Inactive AS context can be quickly restored with minimal signaling when moving to connected state.

RRC states transition process is shown in Fig. 1.

RRC_IDLE to RRC_CONNECTED happens via the RRC Connection Setup procedure. This transition consists of three messages: RRCSetupRequest (UE initiated) , RRCSetup, and RRCSetupComplete.

RRC_CONNECTED to RRC_IDLE is via RRC Connection Release procedure with network-initiated RRCRelease message. Upper layers in the UE may also request a release. RRC connection is also released due to radio link failure, handover failure or cell not meeting cell selection criteria.

RRC_CONNECTED to RRC_INACTIVE is network initiated. It is entered via RRCRelease message with suspendConfig IE.

RRC_INACTIVE to RRC_CONNECTED is triggered by the network via RAN paging. A paged UE will start with RRC Connection Resume procedure consisting of three messages: RRCResumeRequest, RRCResume (or RRCSetup) , RRCResumeComplete (or RRCSetupComplete) . This procedure can also be initiated by UE for uplink transmission, including RNA update.

RRC_INACTIVE to RRC_IDLE happens when network responds to RRCResumeRequest with RRCRelease.

RRC connection establishment involves the establishment of SRB1. The network completes RRC connection establishment prior to completing the establishment of the NG connection, i.e. prior to receiving the UE context information from the 5GC. Consequently, AS security is not activated during the initial phase of the RRC connection. During this initial phase of the RRC connection, the network may configure the UE to perform measurement reporting, but the UE only sends the corresponding measurement reports after successful AS security activation. However, the UE only accepts a re-configuration with sync message when AS security has been activated.

The release of the RRC connection normally is initiated by the network. The procedure may be used to re-direct the UE to an NR frequency or an E-UTRA carrier frequency. The purpose of this procedure is to release the RRC connection, which includes the release of the established radio bearers, BH RLC channels (an RLC channel between two nodes) as well as all radio resources; or to suspend the RRC connection only if SRB2 and at least one DRB or, for IAB, SRB2, are setup, which includes the suspension of the established radio bearers.

The suspension of the RRC connection is initiated by the network. When the RRC connection is suspended, the UE stores the UE Inactive AS context and any configuration received from the network, and transits to RRC_INACTIVE state. The RRC message to suspend the RRC connection is integrity protected and ciphered.

The resumption of a suspended RRC connection is initiated by upper layers when the UE needs to transit from RRC_INACTIVE state to RRC_CONNECTED state or by RRC layer to perform a RNA update or by RAN paging from NG-RAN. When the RRC connection is resumed, network configures the UE according to the RRC connection resume procedure based on the stored UE Inactive AS context and any RRC configuration received from the network. The RRC connection resume procedure re-activates AS security and re-establishes SRB (s) and DRB (s) . The purpose of this procedure is to resume a suspended RRC connection, including resuming SRB (s) and DRB (s) or perform an RNA update.

Fig. 2 illustrates the QoS architecture in 5G system.

The 5G QoS model is based on QoS Flows and supports both QoS Flows that require guaranteed flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (non-GBR QoS Flows) . At NAS level, the QoS flow is thus the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS Flow ID (QFI) carried in an encapsulation header over NG-U.

The QoS architecture in NG-RAN, both for NR connected to 5GC and for E-UTRA connected to 5GC is depicted in the Fig. 2.

For each UE, 5GC establishes one or more PDU Sessions. Except for NB-IoT and IAB-MT in SA mode, for each UE, the NG-RAN establishes at least one DRB together with the PDU Session and additional DRB (s) for QoS flow (s) of that PDU session can be subsequently configured.

If NB-IoT UE supports NG-U data transfer, the NG-RAN may establish DRB together with the PDU Session and one PDU session maps to only one DRB. The NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS level packet filters in the UE and in the 5GC associate UL and DL packets with QoS Flows. And AS-level mapping rules in the UE and in the NG-RAN associate UL and DL QoS Flows with DRBs.

NG-RAN and 5GC ensure quality of service (e.g. reliability and target delay) by mapping packets to appropriate QoS Flows and DRBs. Hence there is a 2-step mapping of IP-flows to QoS flows (NAS) and from QoS flows to DRBs.

At NAS level, a QoS flow is characterized by a QoS profile provided by 5GC to NG-RAN and QoS rule (s) provided by 5GC to the UE. The QoS profile is used by NG-RAN to determine the treatment on the radio interface while the QoS rules dictates the mapping between  uplink User Plane traffic and QoS flows to the UE. A QoS flow may either be GBR or Non-GBR depending on its profile.

At Access Stratum level, the data radio bearer (DRB) defines the packet treatment on the radio interface (Uu) . A DRB serves packets with the same packet forwarding treatment. The QoS flow to DRB mapping by NG-RAN is based on QFI and the associated QoS profiles (i.e. QoS parameters and QoS characteristics) . Separate DRBs may be established for QoS flows requiring different packet forwarding treatment, or several QoS Flows belonging to the same PDU session can be multiplexed in the same DRB.

The UE performs the classification and marking of UL User plane traffic, i.e. the association of UL traffic to QoS Flows, based on QoS rules. These QoS rules may be explicitly provided to the UE, pre-configured in the UE or implicitly derived by the UE by applying Reflective QoS. A QoS rule contains the QFI of the associated QoS Flow, a Packet Filter Set and a precedence value. An explicitly signaled QoS rule contains a QoS rule identifier which is unique within the PDU Session and is generated by SMF.

A default QoS rule is required to be sent to the UE for every PDU Session establishment and it is associated with a QoS Flow. For IP type PDU Session or Ethernet type PDU Session, the default QoS rule is the only QoS rule of a PDU Session which may contain a Packet Filter Set that allows all UL packets, and in this case, the highest precedence value shall be used for the QoS rule.

Fig. 3 illustrates the SDAP structure in 5G system

The main services and functions of SDAP include mapping between a QoS flow and a data radio bearer and marking QFI in both DL and UL packets. The SDAP sublayer is configured by RRC. A single protocol entity of SDAP is configured for each individual PDU session. One or more QoS flows may be mapped onto one DRB. One QoS flow is mapped onto only one DRB at a time in the UL.

The SDAP entities are located in the SDAP sublayer. Several SDAP entities may be defined for a UE. There is an SDAP entity configured for each individual PDU session for NR Uu. An SDAP entity receives/delivers SDAP SDUs from/to upper layers and submits/receives SDAP data PDUs to/from its peer SDAP entity via lower layers.

QoS flow to DRB mapping rule is a mapping rule determining on which DRB packets of a QoS flow shall be carried. Reflective QoS flow to DRB mapping is a QoS flow to DRB mapping scheme where a UE monitors the QoS flow to DRB mapping rule in the DL, and  applies it to in the UL. Reflective QoS flow to DRB mapping is performed at UE, if DL SDAP header is configured.

At the reception of an SDAP SDU from upper layer for a QoS flow, the transmitting SDAP entity shall:

- if there is no stored QoS flow to DRB mapping rule for the QoS flow:

- map the SDAP SDU to the default DRB;

- else:

- map the SDAP SDU to the DRB according to the stored QoS flow to DRB mapping rule;

- if the DRB to which the SDAP SDU is mapped is configured by RRC with the presence of SDAP header,

- construct the UL SDAP data PDU with SDAP header;

- else:

- construct the UL SDAP data PDU without SDAP header;

- submit the constructed UL SDAP data PDU to the lower layers.

At the reception of an SDAP data PDU from lower layers for a QoS flow, the receiving SDAP entity shall:

- if the DRB from which this SDAP data PDU is received is configured by RRC with the presence of SDAP header:

- perform reflective QoS flow to DRB mapping;

- perform RQI handling;

- retrieve the SDAP SDU from the DL SDAP data PDU with SDAP header.

- else:

- retrieve the SDAP SDU from the DL SDAP data PDU without SDAP header;

- deliver the retrieved SDAP SDU to the upper layer.

When RRC configures an UL QoS flow to DRB mapping rule for a QoS flow, the SDAP entity shall:

- if the SDAP entity has already been established and there is no stored QoS flow to DRB mapping rule for the QoS flow and a default DRB is configured:

- construct an end-marker control PDU for the QoS flow;

- map the end-marker control PDU to the default DRB;

- submit the end-marker control PDU to the lower layers.

- if the stored UL QoS flow to DRB mapping rule is different from the configured QoS flow to DRB mapping rule for the QoS flow and the DRB according to the stored QoS flow to DRB mapping rule is configured by RRC with the presence of UL SDAP header:

- construct an end-marker control PDU for the QoS flow;

- map the end-marker control PDU to the DRB according to the stored QoS flow to DRB mapping rule;

- submit the end-marker control PDU to the lower layers.

- store the configured UL QoS flow to DRB mapping rule for the QoS flow.

When RRC releases an UL QoS flow to DRB mapping rule for a QoS flow, the SDAP entity shall:

- remove the UL QoS flow to DRB mapping rule for the QoS flow.

For each received DL SDAP data PDU with RDI set to 1, the SDAP entity shall:

- process the QFI field in the SDAP header and determine the QoS flow;

- if there is no stored QoS flow to DRB mapping rule for the QoS flow and a default DRB is configured:

- construct an end-marker control PDU for the QoS flow;

- map the end-marker control PDU to the default DRB;

- submit the end-marker control PDU to the lower layers;

- if the stored QoS flow to DRB mapping rule for the QoS flow is different from the QoS flow to DRB mapping of the DL SDAP data PDU and the DRB according to the stored QoS flow to DRB mapping rule is configured by RRC with the presence of UL SDAP header:

- construct an end-marker control PDU for the QoS flow;

- map the end-marker control PDU to the DRB according to the stored QoS flow to DRB mapping rule;

- submit the end-marker control PDU to the lower layers;

- store the QoS flow to DRB mapping of the DL SDAP data PDU as the QoS flow to DRB mapping rule for the UL.

Fig. 4 illustrates the format of End-Marker Control PDU.

The D/C bit (1 bit) indicates whether the SDAP PDU is an SDAP Data PDU or an SDAP Control PDU.

Reserved field R (1 bit) shall be set to 0 and be ignored by the receiver.

The QFI field (6 bits) indicates the ID of the QoS flow to which the SDAP PDU belongs.

The PQFI field (6 bits) indicates the ID of the PC5 QoS flow to which the SDAP PDU belongs.

According to the 3GPP specifications, when a wireless device in an RRC idle state has UL data, the wireless device should perform procedures for the transmission of the UL data where the procedures comprises: a random access procedure to synchronize uplink timing, a RRC connection establishment procedure to establish an RRC connection; and an initial AS security activation procedure for secured data transmission.

When the procedures is successfully completed, the wireless device in an RRC connected state transmits the UL data. After the transmission of the UL data, the wireless device stays in the RRC connected state until receiving an RRC release message from a base station. While staying in the RRC connected state, the wireless device should perform additional procedures. The wireless device transitions back to the RRC idle state when receiving an RRC release message from the base station.

The overheads of the overall procedure are inefficient to transmit small amount of data. The overheads become more critical especially for a device requiring low complexity and low power consumption. Thus, 3GPP has introduced technologies to reduce the overheads.

3GPP has developed technologies for SDT to support data transmission without transitioning to an RRC connected state.

NR SDT in an RRC inactive state is studying in 3GPP. Two SDT technologies are supported: RACH based SDT, and CG based SDT. The RACH based SDT allows SDT using an uplink grant received via a random access procedure for SDT. The CG based SDT allows SDT from an RRC inactive state using a configured grant without performing a random access procedure.

In the above, it has been described the SDAP entity should construct an end-marker control PDU according to the stored UL QoS flow to DRB mapping rule or the  configured UL QoS flow to DRB mapping rule. In this case, some specific scenarios need to be considered.

Scenario #1) , the UE stored a mapping rule between QoS flow (#a) and Data Radio Bearer DRB (#1) ; a DL SDAP data PDU with RDI set to 1 which means reflective QoS shall be applied is received by the UE during the MO SDT for DRB (#5) which is mapped with QoS flow (#b) and the QoS flow (#a) is relocated to a SDT DRB (#2) according to the indication from the received DL SDAP PDU; the SDAP entity shall construct an end-marker control PDU, map the end-marker control PDU to the DRB (#1) and submit the end-marker control PDU to the lower layers.

There is a similar scenario, Scenario #1’) , there is no stored QoS flow to DRB mapping rule for the QoS flow (#a) ; a DL SDAP data PDU with RDI set to 1 is received by the UE during the MO SDT and the QoS flow (#a) is mapped to a SDT DRB (#2) according to the indication from the received DL SDAP PDU; the SDAP entity shall construct an end-marker control PDU, map the end-marker control PDU to the default DRB and submit the end-marker control PDU to the lower layers.

For Scenario #1 or #1’, how to handle the end-marker control PDU during SDT if the DRB (#1) to which end-marker control PDU is mapped is a non-SDT DRB is undefined in current standard.

The end-marker control PDU is mapped to either the default DRB or the DRB (#1) according to the stored QoS flow to DRB (#1) mapping rule. While, the default DRB or the DRB (#1) according to the stored QoS flow to DRB mapping rule may be a non-SDT DRB. According to the agreement, non-SDT radio bearers are only resumed upon receiving RRC Resume. It means non-SDT data can only be transmitted when the UE is in RRC_CONNECTED state. Accordingly even if the NW schedules a grant for UL SDT, the UE cannot transmit the end-marker control PDU which is non-SDT data.

There could be two potential solutions by NW implementation in order to transit the UE to RRC_CONNECTED state. The first one is that the UE is transited to RRC_CONNECTED state by the NW during the SDT procedure. The second one is that the NW releases the UE to INACTIVE state after the SDT procedure, then transmits paging signal to the UE. Both of the solutions are only for scheduling a single END-Marker control PDU in RRC_CONNECTED state. Obviously, it is not optimal from the perspective of signaling overhead and power saving.

Scenario #2) , the UE stored a mapping rule between QoS flow (#a) and DRB (#3) ; a DL SDAP data PDU with RDI set to 1 is received by the UE during the MT SDT; the QoS flow is relocated to a SDT DRB (#2) by reflective mapping; an end-marker control PDU is constructed and mapped to the DRB (#3) .

Scenario #3) , a DL packet from DRB (#3) is received by the UE during the MT SDT; an EHC or ROHC feedback control PDU corresponding to the DL packet is generated by the PDCP entity for DRB (#3) and shall be transmitted to the NW.

For Scenarios #2 or #3, how to handle the EHC/ROHC feedback or end-marker control PDU during SDT if the DRB (#3) to which the EHC/ROHC feedback or end-marker control PDU is mapped is a SDT DRB is undefined clearly in current standard.

On the one hand, it is agreed that NAS generates one of the existing resume causes and AS decides SDT or non-SDT access. It can be understood as the SDT traffic being from the higher layer and the “MO data” being indicated by NAS layer. While the EHC/ROHC feedback or end-marker control PDU is carried by a control PDU and generated from the AS layer. Therefore, whether the control PDU can be transmitted as SDT needs to be clarified.

On the other hand, the legacy resume procedure which is used to initiated a SDT can only be initiated by NAS or RNAU. Therefore, it seems that the control PDU generated by the AS layer cannot initiate a RRC resume procedure to transmit the EHC/ROHC feedback as SDT if the UE reselects to a neighbor cell which supports SDT or if DL SPS resources is used for MT SDT (assuming there is not a MO SDT procedure before the DL SDT data transmitted) . Similarly, the end-marker control PDU generated by the AS layer cannot initiate a RRC resume procedure for a SDT if the RRC Release is received before the end-marker control PDU is successfully transmitted. For all the above cases, the UE has to wait for the paging signal again. It is not optimal from the perspective of signaling overhead and power saving.

In order to solve the above technical problem, the application proposes the following solutions. It should be noted that the following solutions are not limited to any specific one of the above scenarios, but may be applied individually or in combination to the above and other scenarios.

When a DL SDAP data PDU with RDI set to 1 which means reflective QoS shall be applied is received by the UE during a MO SDT and the QoS flow is mapped to a SDT DRB according to the indication from the received DL SDAP PDU, the SDAP entity may construct an end-marker control PDU, and map the end-marker control PDU to a default DRB or a DRB  according to the stored QoS flow to DRB mapping rule and submit the end-marker control PDU to the lower layers.

The application proposes that if the DRB to which end-marker control PDU is mapped is a non-SDT DRB, it may be configured/allowed/defined that the end-marker control PDU may be transmitted as SDT.

According to prior art non-SDT data can only be transmitted when the UE is in RRC_CONNECTED state, and therefore even if the NW schedules a grant for UL SDT, the UE cannot transmit the end-marker control PDU which is non-SDT data.

The application further proposes that it may be configured/allowed/defined that the end-marker control PDU may be transmitted by a UE which is not in RRC_CONNECTED state without transition to RRC_CONNECTED state. More specifically, it may be configured/allowed/defined that the end-marker control PDU may be transmitted by a UE in RRC_IDLE and/or RRC_INACTIVE state (i.e., non-CONNECTED state) .

Alternatively, when UE constructs/generates an end-marker control PDU in SDAP entity, if the DRB which carries the end-marker control PDU is not a SDT DRB according to QoS flow to DRB mapping rule, it may be configured/allowed/defined that the DRB which carries the end-marker control PDU may be a SDT DRB or it may be configured/allowed/defined that the DRB which carries the control PDU may be a SDT DRB upon the control PDU is constructed/generated.

Here, the configuration/allowance/definition may be made at RRC layer or agreed in the standard.

Currently, the issue on the order and missing pieces (e.g. failure, fallback) of the high level procedure is in discussion, for example, the procedure below.

Upon arrival of data only for DRB/SRB (s) for which SDT is enabled, the high level procedure for selection between SDT and non SDT procedure is as follows:

- if CG (configured grant) -SDT criteria is met: UE selects CG-SDT. UE initiate SDT procedure

- else if RA (random access) -SDT criteria is met: UE selects RA-SDT. UE initiate SDT procedure

- else: UE initiate non SDT procedure.

CG-SDT criteria is considered met, if all of the following conditions are met, 1) available data volume <= data volume threshold, 2) RSRP is greater than or equal to a  configured threshold, 3) (optional) CG-SDT resources are configured on the selected UL carrier and are valid.

RA-SDT criteria is considered met, if all of the following conditions are met, 1) available data volume <= data volume threshold, 2) RSRP is greater than or equal to a configured threshold, 3) 4 step RA-SDT resources are configured on the selected UL carrier and criteria to select 4 step RA SDT is met; or 2 step RA-SDT resources are configured on the selected UL carrier and criteria to select 2 step RA SDT is met.

The procedure above is started with the arrival of data only for DRB/SRB (s) for which SDT is enabled, but not applicable for the arrival of end-marker control PDU carried on a DRB which is a non-SDT DRB .

In the application, it is proposed that the arrival of end-marker control PDU may be considered as the arrival SDT data. And therefore, the procedure above may be performed.

Furthermore, upon the end-marker control PDU is constructed/generated, if the DRB which carries the end-marker control PDU is not a SDT DRB, the DRB which carries the end-marker control PDU may be resumed.

Alternatively, upon the end-marker control PDU is constructed/generated, if there is not any other data corresponding to the DRB arrival, the DRB which carries the end-marker control PDU may be resumed.

After mapping to the DRB, the end-marked control PDU should be transmitted to the NW. Here, the transmission procedure may comprise transmitting only the end-marker control PDU as SDT.

Specifically, the transmission may be implemented by the SDAP layer only submitting the end-marker control PDU to the lower layers.

Alternatively, the transmission may include multiplexing the end-marker control PDU with other data, and initiating a SDT by the end-marker control PDU.

It may allow the end-marker control PDU to initialize the RRC resume procedure.

It has been described above if the DRB to which end-marker control PDU is mapped is a non-SDT DRB, it may be configured/allowed/defined that the end-marker control PDU may be transmitted as SDT. Optional, the existing criteria, e.g., CG-SDT criteria or RA-SDRT criteria, should be met when deciding whether a SDT may be initiated upon the end-marker control PDU is constructed/generated.

According to the embodiment, when transmitting the end-marked control PDU to the NW as SDT, other data on the DRB which carries the end-marker control PDU may not be transmitted as SDT.

According to another embodiment, when transmitting the end-marker control PDU, the end-marker control PDU may be multiplexed with other data on an ongoing SDT or a SDT may be initiated by the end-marker control PDU. And other data on the DRB which carries the end-marker control PDU may also be transmitted as SDT.

After the end-marker control PDU is transmitted, the DRB which carries the end-marker control PDU may be suspended if it is not configured as SDT DRB.

Corresponding to the procedure at UE side, the control at network side needs to be defined.

As described above, NW may configure an UL QoS flow to DRB mapping rule for a QoS flow, or UE may monitor the QoS flow to DRB mapping rule in the DL and apply Reflective QoS flow to DRB mapping in the UL.

According to an embodiment, the QoS flow to DRB mapping rule may be restricted, it can be for the reflective mapping case and/or for the configuration case.

The QoS flow to DRB mapping rule should be stored or configured before the UE is released to RRC_INACTIVE or RRC_IDLE state. In other words, no default DRB will be available.

As mentioned above, for a UE supporting reflective QoS functionality, the UE shall create a UE derived QoS rule for the uplink traffic based on the received DL traffic if reflective QoS function is used by the 5GC for some traffic flows. The UE shall use the UE derived QoS rules to determine mapping of UL traffic to QoS Flows.

In order to apply the solution proposed in the application, the NW may not allow reflective QoS to be applied to SDT DRBs. Or the QoS flow to DRB mapping rule may not allowed to be changed.

On the other hand, if the QoS flow to DRB mapping rule need to be changed, it is required to resumed to RRC_CONNECTED state.

In one of the above embodiments, when a DL SDAP data PDU with RDI set to 1 is received, the SDAP entity may construct an end-marker control PDU, and map the end-marker control PDU to a DRB, where if the DRB to which end-marker control PDU is mapped is a non- SDT DRB, it may be configured/allowed/defined that the end-marker control PDU may be transmitted as SDT.

In another embodiment, when the DL SDAP data PDU with RDI set to 1 is received, the UE may not construct an end-marker control PDU if the DRB which would carry the end-marker control PDU is not a SDT DRB.

Alternatively, when the DL SDAP data PDU with RDI set to 1 is received, an end-marker control PDU may be constructed. Next, the UE may discard or withdraw or cancel the end-maker control PDU, if there is no other data for the DRB which carries the end-marker control PDU buffered or if the DRB which carries the end-marker control PDU is a non-SDT or the UE can make sure no out of order transmission between two DRBs. Here, out of order transmission means the transmission is not in the order it should be which is caused by the disorder of the sequence of data pieces or missing data pieces (e.g. failure, fallback) .

In both cases, no end-marker control PDU is transmitted to the NW.

It can be applied in the case the transmitter can make sure that there is not out of delivery of the data between the two mapping DRBs if the transmitter determines not to transmit the end-marker control PDU.

It should be noted that the end-marker control PDU is only an example of the control PDU, and other control PDUs are also possible.

Refer back to the Scenarios #2 and #3, the EHC/ROHC feedback or end-marker control PDU is a control PDU and generated from the AS layer, while the legacy resume procedure which is used to initiated a SDT can only be initiated by NAS or RNAU.

In order to avoid signaling overhead, the application propose to consider the control PDU from AS layer as the arrival SDT data. Specifically, the control PDU may be the end-marker control PDU, the interspersed ROHC feedback, the EHC feedback, the PDCP status report, the RLC status report, and the like.

Similar to the embodiments, it may be configured/allowed/defined to transmit the control PDU as SDT. Here, the transmission may include multiplexing the end-marker control PDU with other data and initiating a SDT upon the control PDU is constructed/generated.

Optional, the existing criteria, e.g., CG-SDT criteria or RA-SDRT criteria, should be met when deciding whether a SDT can be initiated upon the control PDU is constructed/generated.

Further, it may be indicated to RRC layer that the resuming procedure is for the AS control PDU transmission in non RRC_CONNECTED state. And accordingly, a new resume cause may be introduced and applied when delivering the RRC message.

The proposed methods at the UE side and the NW side have been described with reference several embodiments. It should be appreciate that the following embodiments are merely examples of the concept of the present invention, rather than the only way in which the present invention can be implemented.

Fig. 5 illustrates a flowchart for a UE to handle the control PDU according to an embodiment.

The method (500) starts with receiving a DL data PDU from the NW (S501) .

Next, the UE determines whether a control PDU should be transmitted to the NW (S502) .

If a control PDU should be transmitted to the NW (YES at S502) , the UE determines whether the DRB which would carry a control PDU is a SDT DRB or not (S503) .

Based on the determining result at S503, the UE will perform different procedures.

If the DRB is not a SDR DRB (NO at S503) , the UE constructs the control PDU for a QoS flow (S504) , maps the control PDU to the DRB (S505) and transmits the control PDU via the DRB as SDT to the NW (S506) .

If the DRB is a SDR DRB (YES at S503) , the UE map the control PDU to the DRB (S507) and transmit the control PDU via the DRB as SDT to the NW (S508) .

Back to S502, if a control PDU needs not to be transmitted to the NW (NO at S502) , the UE may not transmit control PDU.

For example, the UE may not construct a control PDU (S509) .

Or, the UE may construct a control PDU (S510) , but discard the transmission of the control PDU (S511) . The alternative procedures are illustrated with dashed blocks.

Fig. 6 is a schematic block diagram illustrating apparatuses according to one embodiment. Referring to Fig. 6, the UE (i.e., the terminal device) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are described above. The details of the operation of the UE have been described above.

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 a radio  signal. Needless to say, the transceiver may be implemented as a transmitter to transmit the radio signal and a receiver to receive the radio signal.

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

Referring to Fig. 6, the gNB (i.e., the network device) includes a processor, a memory, and a transceiver. The processor implements a function, a process, and/or a method which are described above.

The operations performed on the gNB side correspond to the operations performed on the UE side. For details, please refer to the description above.

With the solutions in the present invention, in order to optimize the handling of the control PDU triggered from AS layer, the following solutions are provided allowing the control PDU which is carried by a non-SDT DRB to be transmitted as SDT temporarily, allowing the control PDU which is constructed by the AS layer and carried by a SDT DRB to initiate a SDT, restricting the NW behavior to reduce signaling overhead and power consumption and proposing the preconditions for cancellation of the control PDU.

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 in 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 (38)

1. A method performed by a terminal device, comprising:

   receiving a downlink (DL) Packet Data Unit (PDU) from a network device;

   in response to determining that a control PDU is to be transmitted to the network device while the terminal device is in a non-Radio Resource Control (RRC) _CONNECTED state with the network device, determining whether a Data Radio Bearer (DRB) that carries the control PDU is a Small Data Transmission (SDT) DRB or not;

   in response to determining that the DRB is not a SDT DRB,

   constructing the control PDU for a Quality of Service (QoS) flow,

   mapping the control PDU to the DRB, and

   transmitting the control PDU via the DRB as SDT.
2. The method of claim, wherein, the control PDU is generated from Access Stratum (AS) layer.
3. The method of claim 1, wherein,

   the control PDU is considered as arrival of data for DRB for which SDT is enabled, if it is determined that the control PDU will be transmitted.
4. The method of claim 3, further comprising:

   in response to determining that the DRB is a SDT DRB,

   mapping the control PDU to the DRB; and

   transmitting the control PDU via the DRB as SDT.
5. The method of claim 1, wherein, determining whether the control PDU is to be transmitted further comprises:

   determining that the control PDU is not to be transmitted, if the terminal device determines that no out of order transmission will be occurred between DRBs.
6. The method of claim 5, wherein, in response to determining that the control PDU is not to be transmitted, the method further comprises:

   not constructing the control PDU for the QoS flow; or

   constructing the control PDU for the QoS flow and discarding the control PDU.
7. The method of claim 1, wherein transmitting the control PDU via the DRB as SDT further comprises:

   multiplexing the control PDU with other data during an ongoing SDT.
8. The method of claim 1, wherein transmitting the control PDU via the DRB as SDT further comprises:

   initiating a SDT if there is no ongoing SDT or if there is no other data corresponding to the arrival of SDT data,

   wherein the trigger condition for initiating the SDT is that the control PDU is constructed.
9. The method of claim 8, further comprising:

   indicating to an RRC layer that a resuming procedure is to initiate a SDT from Access Stratum (AS) layer.
10. The method of claim 9, wherein,

    related resume cause is defined to indicate that the resuming procedure is to initiate a SDT from the AS layer.
11. The method of claim 1, wherein, in the case that the DRB is not a SDT DRB, transmitting the control PDU via the DRB as SDT comprises:

    only transmitting the control PDU as SDT.
12. The method of claim 1, further comprises:

    resuming the DRB which carries the control PDU if the DRB is not a SDT DRB.
13. The method of claim 1, further comprising:

    suspending the DRB if the DRB is not a SDT DRB after the control PDU is transmitted.
14. A method by a network device, comprises:

    configuring an uplink (UL) Quality of Service (QoS) flow to Data Radio Bearer (DRB) mapping rule for a QoS flow or transmitting a downlink (DL) data Packet Data Unit (PDU) to a terminal device;

    receiving a control PDU for a QoS flow from the terminal device;

    delivering the control PDU to upper layer,

    wherein the control PDU is received as Small Data Transmission (SDT) ,

    wherein the network device in a non-Radio Resource Control (RRC) _CONNECTED state with the terminal device, and

    wherein the method further comprising:

    restricting a QoS flow to DRB mapping rule for the QoS flow.
15. The method of claim 14, wherein, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising:

    the QoS flow to DRB mapping rule is delivered before the terminal device is released to a non-RRC_CONNECTED state with the network device.
16. The method of claim 14, wherein, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising:

    the QoS flow to DRB mapping rule is delivered before the RRC Release message is transmitted to the terminal device.
17. The method of claim 14, wherein, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising:

    reflective QoS is not allowed to be applied to SDT DRBs.
18. The method of claim 14, wherein, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising:

    the QoS flow to DRB mapping rule is not allowed to be changed during the SDT procedure of the terminal device.
19. The method of claim 14, wherein, restricting the QoS flow to DRB mapping rule for the QoS flow further comprising:

    resuming to a RRC_CONNECTED state with the terminal device if the QoS flow to DRB mapping rule is to be changed.
20. A terminal device, comprising:

    a transceiver; and

    a processor coupled to the transceiver and the processor being configured to:

    receive a downlink (DL) Packet Data Unit (PDU) from a network device;

    in response to determining that a control PDU is to be transmitted to the network device while the terminal device is in a non-Radio Resource Control (RRC) _CONNECTED state with the network device, determine whether a Data Radio Bearer (DRB) which carries the control PDU is a Small Data Transmission (SDT) DRB or not;

    in response to determining that the DRB is not a SDT DRB,

    construct the control PDU for a Quality of Service (QoS) flow,

    map the control PDU to the DRB, and

    transmit the control PDU via the DRB as SDT.
21. The terminal device of claim 20, wherein,

    the control PDU is generated from Access Stratum (AS) layer.
22. The terminal device of claim 20, wherein,

    the control PDU is considered as arrival of data for DRB for which SDT is enabled, if it is determined that the control PDU will be transmitted.
23. The terminal device of claim 22, wherein, the processor is further configured to:

    in response to determining that the DRB is a SDT DRB,

    map the control PDU to the DRB; and

    transmit the control PDU via the DRB as SDT.
24. The terminal device of claim 20, wherein, the processor is further configured to:

    determine that the control PDU will not be transmitted, if the terminal device determines that no out of order transmission will be occurred between DRBs.
25. The terminal device of claim 24, wherein, when determining that the control PDU will not be transmitted, the processor is further configured to:

    not construct the control PDU for the QoS flow; or

    construct the control PDU for the QoS flow and discard the control PDU.
26. The terminal device of claim 20, wherein, the processor is further configured to: multiplexing the control PDU with other data on an ongoing SDT.
27. The terminal device of claim 20, wherein, the processor is further configured to:

    initiate a SDT if there is no ongoing SDT or if there is no other data corresponding to the arrival of SDT data,

    wherein the trigger condition for initiating the SDT is that the control PDU is constructed.
28. The terminal device of claim 27, wherein, the processor is further configured to:

    indicate RRC layer that a resuming procedure is to initiate a SDT from Access Stratum (AS) layer.
29. The terminal device of claim 28, wherein,

    related resume cause is defined to indicate that the resuming procedure is to initiate a SDT from the AS layer.
30. The terminal device of claim 20, wherein, the processor is further configured to:

    in the case that the DRB is not a SDT DRB, only transmit the control PDU as SDT when transmitting the control PDU via the DRB as SDT.
31. The terminal device of claim 20, wherein, the processor is further configured to:

    resume the DRB which carries the control PDU if the DRB is not a SDT DRB.
32. The terminal device of claim 20, wherein, the processor is further configured to:

    suspend the DRB if the DRB is not a SDT DRB after the control PDU is transmitted.
33. A network device, comprising:

    a transceiver; and

    a processor coupled to the transceiver and the processor being configured to:

    configure an uplink (UL) Quality of Service (QoS) flow to Data Radio Bearer (DRB) mapping rule for a QoS flow or transmit a downlink (DL) data Packet Data Unit (PDU) to a terminal device;

    receive a control PDU for a QoS flow from the terminal device;

    deliver the control PDU to upper layer,

    wherein the control PDU is received as Small Data Transmission (SDT) ,

    wherein the network device in a non-Radio Resource Control (RRC) _CONNECTED state with the terminal device, and

    wherein the processor is further configured to:

    restrict a QoS flow to DRB mapping rule for the QoS flow.
34. The network device of claim 33, wherein, the processor is further configured to:

    deliver the QoS flow to DRB mapping rule before the terminal device is released to a non-RRC_CONNECTED state with the network device.
35. The network device of claim 33, wherein, the processor is further configured to:

    deliver the QoS flow to DRB mapping rule before the RRC Release message is transmitted to the terminal device.
36. The network device of claim 33, wherein, the processor is further configured to:

    not allow reflective QoS to be applied to SDT DRBs.
37. The network device of claim 33, wherein, the processor is further configured to:

    not allow the QoS flow to DRB mapping rule to be changed during the SDT procedure of the terminal device.
38. The network device of claim 33, wherein, the processor is further configured to:

    resume to a RRC_CONNECTED state with the termina device if the QoS flow to DRB mapping rule is to be changed.

Images