Patent Description:
Introduction of new radio communication technologies has led to increases in the number of user equipments (UEs) to which a base station (BS) provides services in a prescribed resource region, and has also led to increases in the amount of data and control information that the BS transmits to the UEs. Due to typically limited resources available to the BS for communication with the UE(s), new techniques are needed by which the BS utilizes the limited radio resources to efficiently receive/transmit uplink/downlink data and/or uplink/downlink control information. In particular, overcoming delay or latency has become an important challenge in applications whose performance critically depends on delay/latency.

Prior art is found in Email Discussion Rapporteur (ZTE Corporation), "Agreeable details of RRC-based solution for SDT (RACH and CG)", R2-<NUM>.

Accordingly, an object of the present disclosure is to provide a method of performing a random access (RA) procedure for a data transmission (SDT) in a wireless communication system and an apparatus therefor.

The invention are set out in the independent claims.

According to a first aspect, we describe a method for performing data transmissions in a Radio Resource Control, RRC, INACTIVE state by a user equipment, UE, in a wireless communication system, the method comprising: generating a first data that can be transmitted in the RRC_INACTIVE state; triggering a first random access, RA, procedure for transmitting the first data in the RRC_INACTIVE state; generating a second data that cannot be transmitted in the RRC_INACTIVE state while the first RA procedure is ongoing; and transmitting a RRC message for transitioning to a RRC CONNECTED state, wherein, based on the second data being generated after a contention resolution succeeds, the ciphering is applied to the RRC message, wherein, based on the second data being generated before the contention resolution succeeds, the ciphering is not applied to the RRC message, and wherein, based on the second data being generated before the contention resolution succeeds, the first RA procedure is stopped and a second RA procedure for transitioning to the RRC CONNECTED state is started.

According to a second aspect, we describe a user equipment, UE, in a wireless communication system, the UE comprising: at least one transceiver; at least one processor; and at least one computer memory operably connectable to the at least one processor and storing instructions that, when executed, cause the at least one processor to perform operations comprising: generating a first data that can be transmitted in a Radio Resource Control, RRC, INACTIVE state; triggering a first random access, RA, procedure for transmitting the first data in the RRC_INACTIVE state; generating a second data that cannot be transmitted in the RRC_INACTIVE state while the first RA procedure is ongoing; and transmitting a RRC message for transitioning to a RRC CONNECTED state, wherein, based on the second data being generated after a contention resolution succeeds, the ciphering is applied to the RRC message, wherein, based on the second data being generated before the contention resolution succeeds, the ciphering is not applied to the RRC message, and wherein, based on the second data being generated before the contention resolution succeeds, the first RA procedure is stopped and a second RA procedure for transitioning to the RRC CONNECTED state is started.

According to a third aspect, we describe an apparatus of a user equipment, UE, the apparatus comprising: at least one processor; and at least one computer memory operably connectable to the at least one processor and storing instructions that, when executed, cause the at least one processor to perform operations comprising: generating a first data that can be transmitted in a Radio Resource Control, RRC, INACTIVE state; triggering a first random access, RA, procedure for transmitting the first data in the RRC_INACTIVE state; generating a second data that cannot be transmitted in the RRC_INACTIVE state while the first RA procedure is ongoing; and transmitting a RRC message for transitioning to a RRC CONNECTED state, wherein, based on the second data being generated after a contention resolution succeeds, the ciphering is applied to the RRC message, wherein, based on the second data being generated before the contention resolution succeeds, the ciphering is not applied to the RRC message, and wherein, based on the second data being generated before the contention resolution succeeds, the first RA procedure is stopped and a second RA procedure for transitioning to the RRC CONNECTED state is started.

According to a fourth aspect, we describe a computer readable storage medium storing at least one computer program comprising instructions that, when executed by at least one processor, cause the at least one processor to perform operations for a user equipment, UE, the operations comprising: generating a first data that can be transmitted in a Radio Resource Control, RRC, INACTIVE state; triggering a first random access, RA, procedure for transmitting the first data in the RRC_INACTIVE state; generating a second data that cannot be transmitted in the RRC_INACTIVE state while the first RA procedure is ongoing; and transmitting a RRC message for transitioning to a RRC CONNECTED state, wherein, based on the second data being generated after a contention resolution succeeds, the ciphering is applied to the RRC message, wherein, based on the second data being generated before the contention resolution succeeds, the ciphering is not applied to the RRC message, and wherein, based on the second data being generated before the contention resolution succeeds, the first RA procedure is stopped and a second RA procedure for transitioning to the RRC CONNECTED state is started.

According to the aforementioned embodiments of the present disclosure, the UE can transmit a RRC Resume Request message in a more secured manner without causing any decoding problem in the network. This will increase the security when the UE moves from RRC_INACTIVE state to RRC_CONNECTED state.

Effects obtainable from the present disclosure may be non-limited by the above mentioned effect. And, other unmentioned effects can be clearly understood from the following description by those having ordinary skill in the technical field to which the present disclosure pertains.

The accompanying drawings, which are included to provide a further understanding of the invention, illustrate embodiments of the invention and together with the description serve to explain the principle of the invention:.

Reference will now be made in detail to the exemplary implementations of the present disclosure, examples of which are illustrated in the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary implementations of the present disclosure, rather than to show the only implementations that can be implemented according to the disclosure. The following detailed description includes specific details in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without such specific details.

For example, the following documents may be referenced.

In the present disclosure, a user equipment (UE) may be a fixed or mobile device. Examples of the UE include various devices that transmit and receive user data and/or various kinds of control information to and from a base station (BS). In the present disclosure, a BS generally refers to a fixed station that performs communication with a UE and/or another BS, and exchanges various kinds of data and control information with the UE and another BS. The BS may be referred to as an advanced base station (ABS), a node-B (NB), an evolved node-B (eNB), a base transceiver system (BTS), an access point (AP), a processing server (PS), etc. Especially, a BS of the UMTS is referred to as a NB, a BS of the enhanced packet core (EPC) / long term evolution (LTE) system is referred to as an eNB, and a BS of the new radio (NR) system is referred to as a gNB.

In the present disclosure, a node refers to a point capable of transmitting/receiving a radio signal through communication with a UE. Various types of BSs may be used as nodes irrespective of the terms thereof. For example, a BS, a node B (NB), an e-node B (eNB), a pico-cell eNB (PeNB), a home eNB (HeNB), a relay, a repeater, etc. may be a node. In addition, the node may not be a BS. For example, the node may be a radio remote head (RRH) or a radio remote unit (RRU). The RRH or RRU generally has a lower power level than a power level of a BS. Since the RRH or RRU (hereinafter, RRH/RRU) is generally connected to the BS through a dedicated line such as an optical cable, cooperative communication between RRH/RRU and the BS can be smoothly performed in comparison with cooperative communication between BSs connected by a radio line. At least one antenna is installed per node. The antenna may include a physical antenna or an antenna port or a virtual antenna.

In the present disclosure, the term "cell" may refer to a geographic area to which one or more nodes provide a communication system, or refer to radio resources. A "cell" of a geographic area may be understood as coverage within which a node can provide service using a carrier and a "cell" as radio resources (e.g. time-frequency resources) is associated with bandwidth (BW) which is a frequency range configured by the carrier. The "cell" associated with the radio resources is defined by a combination of downlink resources and uplink resources, for example, a combination of a downlink (DL) component carrier (CC) and an uplink (UL) CC. The cell may be configured by downlink resources only, or may be configured by downlink resources and uplink resources. Since DL coverage, which is a range within which the node is capable of transmitting a valid signal, and UL coverage, which is a range within which the node is capable of receiving the valid signal from the UE, depends upon a carrier carrying the signal, the coverage of the node may be associated with coverage of the "cell" of radio resources used by the node. Accordingly, the term "cell" may be used to represent service coverage of the node sometimes, radio resources at other times, or a range that signals using the radio resources can reach with valid strength at other times.

In the present disclosure, a physical downlink control channel (PDCCH), and a physical downlink shared channel (PDSCH) refer to a set of time-frequency resources or resource elements (REs) carrying downlink control information (DCI), and a set of time-frequency resources or REs carrying downlink data, respectively. In addition, a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH) and a physical random access channel (PRACH) refer to a set of time-frequency resources or REs carrying uplink control information (UCI), a set of time-frequency resources or REs carrying uplink data and a set of time-frequency resources or REs carrying random access signals, respectively.

In carrier aggregation (CA), two or more CCs are aggregated. A UE may simultaneously receive or transmit on one or multiple CCs depending on its capabilities. CA is supported for both contiguous and non-contiguous CCs. When CA is configured the UE only has one radio resource control (RRC) connection with the network. At RRC connection establishment/re-establishment/handover, one serving cell provides the non-access stratum (NAS) mobility information, and at RRC connection re-establishment/handover, one serving cell provides the security input. This cell is referred to as the Primary Cell (PCell). The PCell is a cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure. Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells. An SCell is a cell providing additional radio resources on top of Special Cell. The configured set of serving cells for a UE therefore always consists of one PCell and one or more SCells. In the present disclosure, for dual connectivity (DC) operation, the term "special Cell" refers to the PCell of the master cell group (MCG) or the PSCell of the secondary cell group (SCG), and otherwise the term Special Cell refers to the PCell. An SpCell supports physical uplink control channel (PUCCH) transmission and contention-based random access, and is always activated. The MCG is a group of serving cells associated with a master node, comprising of the SpCell (PCell) and optionally one or more SCells. The SCG is the subset of serving cells associated with a secondary node, comprising of the PSCell and zero or more SCells, for a UE configured with DC. For a UE in RRC_CONNECTED not configured with CA/DC there is only one serving cell comprising of the PCell. For a UE in RRC_CONNECTED configured with CA/DC the term "serving cells" is used to denote the set of cells comprising of the SpCell(s) and all SCells.

The MCG is a group of serving cells associated with a master BS which terminates at least S1-MME, and the SCG is a group of serving cells associated with a secondary BS that is providing additional radio resources for the UE but is not the master BS. The SCG includes a primary SCell (PSCell) and optionally one or more SCells. In DC, two MAC entities are configured in the UE: one for the MCG and one for the SCG. Each MAC entity is configured by RRC with a serving cell supporting PUCCH transmission and contention based Random Access. In the present disclosure, the term SpCell refers to such cell, whereas the term SCell refers to other serving cells. The term SpCell either refers to the PCell of the MCG or the PSCell of the SCG depending on if the MAC entity is associated to the MCG or the SCG, respectively.

In the present disclosure, monitoring a channel refers to attempting to decode the channel. For example, monitoring a physical downlink control channel (PDCCH) refers to attempting to decode PDCCH(s) (or PDCCH candidates).

In the present disclosure, "C-RNTI" refers to a cell RNTI, "SI-RNTI" refers to a system information RNTI, "P-RNTI" refers to a paging RNTI, "RA-RNTI" refers to a random access RNTI, "SC-RNTI" refers to a single cell RNTI", "SL-RNTI" refers to a sidelink RNTI, "SPS C-RNTI" refers to a semi-persistent scheduling C-RNTI, and "CS-RNTI" refers to a configured scheduling RNTI.

<FIG> illustrates an example of a communication system <NUM> to which implementations of the present disclosure is applied.

In addition, one of the most expected <NUM> use cases relates a function capable of smoothly connecting embedded sensors in all fields, i.e., mMTC. It is expected that the number of potential IoT devices will reach <NUM> hundred million up to the year of <NUM>. An industrial IoT is one of categories of performing a main role enabling a smart city, asset tracking, smart utility, agriculture, and security infrastructure through <NUM>.

Mission critical application (e.g. e-health) is one of <NUM> use scenarios. A health part contains many application programs capable of enjoying benefit of mobile communication. A communication system may support remote treatment that provides clinical treatment in a faraway place. Remote treatment may aid in reducing a barrier against distance and improve access to medical services that cannot be continuously available in a faraway rural area. Remote treatment is also used to perform important treatment and save lives in an emergency situation. The wireless sensor network based on mobile communication may provide remote monitoring and sensors for parameters such as heart rate and blood pressure.

Referring to <FIG>, the communication system <NUM> includes wireless devices, base stations (BSs), and a network.

The BSs and the network may be implemented as wireless devices and a specific wireless device 200a may operate as a BS/network node with respect to other wireless devices.

The wireless devices represent devices performing communication using radio access technology (RAT) (e.g., <NUM> New RAT (NR)) or Long-Term Evolution (LTE)) and may be referred to as communication/radio/<NUM> devices. The wireless devices may include, without being limited to, a robot 100a, vehicles 100b-<NUM> and 100b-<NUM>, an eXtended Reality (XR) device 100c, a hand-held device 100d, a home appliance 100e, an Internet of Things (IoT) device 100f, and an Artificial Intelligence (AI) device/server <NUM>. The vehicles may include an Unmanned Aerial Vehicle (UAV) (e.g., a drone). The XR device may include an Augmented Reality (AR)/Virtual Reality (VR)/Mixed Reality (MR) device and may be implemented in the form of a Head-Mounted Device (HMD), a Head-Up Display (HUD) mounted in a vehicle, a television, a smartphone, a computer, a wearable device, a home appliance device, a digital signage, a vehicle, a robot, etc. The hand-held device may include a smartphone, a smartpad, a wearable device (e.g., a smartwatch or a smartglasses), and a computer (e.g., a notebook).

A user equipment (UE) may include, for example, a cellular phone, a smartphone, a laptop computer, a digital broadcast terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate personal computer (PC), a tablet PC, an ultrabook, a vehicle, a vehicle having an autonomous traveling function, a connected car, an unmanned aerial vehicle (UAV), an artificial intelligence (AI) module, a robot, an augmented reality (AR) device, a virtual reality (VR) device, a mixed reality (MR) device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a FinTech device (or a financial device), a security device, a weather/environment device, a device related to a <NUM> service, or a device related to a fourth industrial revolution field. The unmanned aerial vehicle (UAV) may be, for example, an aircraft aviated by a wireless control signal without a human being onboard. For example, the security device may be a camera, a CCTV, a recorder, or a black box.

Wireless communication/connections 150a and 150b may be established between the wireless devices 100a to 100f/BS <NUM>-BS <NUM>. Herein, the wireless communication/connections may be established through various RATs (e.g., <NUM> NR) such as uplink/downlink communication 150a and sidelink communication 150b (or D2D communication). The wireless devices and the BSs/the wireless devices may transmit/receive radio signals to/from each other through the wireless communication/connections 150a and 150b. For example, the wireless communication/connections 150a and 150b may transmit/receive signals through various physical channels. To this end, at least a part of various configuration information configuring processes, various signal processing processes (e.g., channel encoding/decoding, modulation/demodulation, and resource mapping/demapping), and resource allocating processes, for transmitting/receiving radio signals, may be performed based on the various proposals of the present disclosure.

<FIG> is a block diagram illustrating examples of communication devices which can perform a method according to the present disclosure.

Referring to <FIG>, a first wireless device <NUM> and a second wireless device <NUM> may transmit/receive radio signals to/from an external device through a variety of RATs (e.g., LTE and NR). In <FIG>, {the first wireless device <NUM> and the second wireless device <NUM>} may correspond to {the wireless device 100a to 100f and the BS <NUM>} and/or {the wireless device 100a to 100f and the wireless device 100a to 100f} of <FIG>.

The processor(s) <NUM> may control the memory(s) <NUM> and/or the transceiver(s) <NUM> and may be configured to implement the functions, procedures, and/or methods described in the present disclosure. For example, the memory(s) <NUM> may store software code including commands for performing a part or the entirety of processes controlled by the processor(s) <NUM> or for performing the procedures and/or methods described in the present disclosure. The transceiver(s) <NUM> may be interchangeably used with radio frequency (RF) unit(s).

The processor(s) <NUM> may control the memory(s) <NUM> and/or the transceiver(s) <NUM> and may be configured to implement the functions, procedures, and/or methods described in the present disclosure. For example, the memory(s) <NUM> may store software code including commands for performing a part or the entirety of processes controlled by the processor(s) <NUM> or for performing the procedures and/or methods described in the present disclosure.

The one or more processors <NUM> and <NUM> may generate one or more Protocol Data Units (PDUs) and/or one or more Service Data Unit (SDUs) according to the functions, procedures, proposals, and/or methods disclosed in the present disclosure. The one or more processors <NUM> and <NUM> may generate messages, control information, data, or information according to the functions, procedures, proposals, and/or methods disclosed in the present disclosure. The one or more processors <NUM> and <NUM> may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, procedures, proposals, and/or methods disclosed in the present disclosure and provide the generated signals to the one or more transceivers <NUM> and <NUM>. The one or more processors <NUM> and <NUM> may receive the signals (e.g., baseband signals) from the one or more transceivers <NUM> and <NUM> and acquire the PDUs, SDUs, messages, control information, data, or information according to the functions, procedures, proposals, and/or methods disclosed in the present disclosure.

The functions, procedures, proposals, and/or methods disclosed in the present disclosure may be implemented using firmware or software and the firmware or software may be configured to include the modules, procedures, or functions. Firmware or software configured to perform the functions, procedures, proposals, and/or methods disclosed in the present disclosure may be included in the one or more processors <NUM> and <NUM> or stored in the one or more memories <NUM> and <NUM> so as to be driven by the one or more processors <NUM> and <NUM>. The functions, procedures, proposals, and/or methods disclosed in the present disclosure may be implemented using firmware or software in the form of code, commands, and/or a set of commands.

The one or more transceivers <NUM> and <NUM> may transmit user data, control information, and/or radio signals/channels, mentioned in the methods and/or operational flowcharts of the present disclosure, to one or more other devices. The one or more transceivers <NUM> and <NUM> may receive user data, control information, and/or radio signals/channels, mentioned in the functions, procedures, proposals, methods, and/or operational flowcharts disclosed in the present disclosure, from one or more other devices. The one or more transceivers <NUM> and <NUM> may be connected to the one or more antennas <NUM> and <NUM> and the one or more transceivers <NUM> and <NUM> may be configured to transmit and receive user data, control information, and/or radio signals/channels, mentioned in the functions, procedures, proposals, methods, and/or operational flowcharts disclosed in the present disclosure, through the one or more antennas <NUM> and <NUM>. In the present disclosure, the one or more antennas may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports). For example, the transceivers <NUM> and <NUM> can up-convert OFDM baseband signals to a carrier frequency by their (analog) oscillators and/or filters under the control of the processors <NUM> and <NUM> and transmit the up-converted OFDM signals at the carrier frequency. The transceivers <NUM> and <NUM> may receive OFDM signals at a carrier frequency and down-convert the OFDM signals into OFDM baseband signals by their (analog) oscillators and/or filters under the control of the transceivers <NUM> and <NUM>.

In the implementations of the present disclosure, a UE may operate as a transmitting device in uplink (UL) and as a receiving device in downlink (DL). In the implementations of the present disclosure, a BS may operate as a receiving device in UL and as a transmitting device in DL. Hereinafter, for convenience of description, it is mainly assumed that the first wireless device <NUM> acts as the UE, and the second wireless device <NUM> acts as the BS, unless otherwise mentioned or described. For example, the processor(s) <NUM> connected to, mounted on or launched in the first wireless device <NUM> may be configured to perform the UE behavior according to an implementation of the present disclosure or control the transceiver(s) <NUM> to perform the UE behavior according to an implementation of the present disclosure. The processor(s) <NUM> connected to, mounted on or launched in the second wireless device <NUM> may be configured to perform the BS behavior according to an implementation of the present disclosure or control the transceiver(s) <NUM> to perform the BS behavior according to an implementation of the present disclosure.

In the present disclosure, at least one memory (e.g. <NUM> or <NUM>) may store instructions or programs that, when executed, cause at least one processor, which is operably connected thereto, to perform operations according to some embodiments or implementations of the present disclosure.

In the present disclosure, a computer readable storage medium stores at least one instructions or computer programs that, when executed by at least one processor, cause the at least one processor to perform operations according to some embodiments or implementations of the present disclosure.

In the present disclosure, a processing device or apparatus may comprise at least one processor, and at least one computer memory connectable to the at least one processor and storing instructions that, when executed, cause the at least one processor to perform operations according to some embodiments or implementations of the present disclosure.

<FIG> illustrates another example of a wireless device which can perform implementations of the present disclosure.

For example, the communication circuit <NUM> may include the one or more processors <NUM> and <NUM> of <FIG> and/or the one or more memories <NUM> and <NUM> of <FIG>. For example, the transceiver(s) <NUM> may include the one or more transceivers <NUM> and <NUM> of <FIG> and/or the one or more antennas <NUM> and <NUM> of <FIG>.

For example, the additional components <NUM> may include at least one of a power unit/battery, input/output (I/O) unit (e.g. audio I/O port, video I/O port), a driving unit, and a computing unit. The wireless device may be implemented in the form of, without being limited to, the robot (100a of <FIG>), the vehicles (100b-<NUM> and 100b-<NUM> of <FIG>), the XR device (100c of <FIG>), the hand-held device (100d of <FIG>), the home appliance (100e of <FIG>), the IoT device (100f of <FIG>), a digital broadcast terminal, a hologram device, a public safety device, an MTC device, a medicine device, a Fintech device (or a finance device), a security device, a climate/environment device, the AI server/device (<NUM> of <FIG>), the BSs (<NUM> of <FIG>), a network node, etc. The wireless device may be used in a mobile or fixed place according to a use-example/service.

As an example, the control unit <NUM> may be configured by a set of a communication control processor, an application processor, an electronic control unit (ECU), a graphical processing unit, and a memory control processor. As another example, the memory <NUM> may be configured by a random access memory (RAM), a dynamic RAM (DRAM), a read only memory (ROM)), a flash memory, a volatile memory, a non-volatile memory, and/or a combination thereof.

<FIG> illustrates an example of protocol stacks in a 3GPP based wireless communication system.

In particular, <FIG> illustrates an example of a radio interface user plane protocol stack between a UE and a base station (BS) and <FIG> illustrates an example of a radio interface control plane protocol stack between a UE and a BS. The control plane refers to a path through which control messages used to manage call by a UE and a network are transported. The user plane refers to a path through which data generated in an application layer, for example, voice data or Internet packet data are transported. Referring to <FIG>, the user plane protocol stack may be divided into a first layer (Layer <NUM>) (i.e., a physical (PHY) layer) and a second layer (Layer <NUM>). Referring to <FIG>, the control plane protocol stack may be divided into Layer <NUM> (i.e., a PHY layer), Layer <NUM>, Layer <NUM> (e.g., a radio resource control (RRC) layer), and a non-access stratum (NAS) layer. Layer <NUM>, Layer <NUM> and Layer <NUM> are referred to as an access stratum (AS).

The NAS control protocol is terminated in an access management function (AMF) on the network side, and performs functions such as authentication, mobility management, security control and etc..

In the 3GPP LTE system, the layer <NUM> is split into the following sublayers: medium access control (MAC), radio link control (RLC), and packet data convergence protocol (PDCP). In the 3GPP New Radio (NR) system, the layer <NUM> is split into the following sublayers: MAC, RLC, PDCP and SDAP. The PHY layer offers to the MAC sublayer transport channels, the MAC sublayer offers to the RLC sublayer logical channels, the RLC sublayer offers to the PDCP sublayer RLC channels, the PDCP sublayer offers to the SDAP sublayer radio bearers. The SDAP sublayer offers to <NUM> Core Network quality of service (QoS) flows.

In the 3GPP NR system, the main services and functions of the RRC sublayer include: broadcast of system information related to AS and NAS; paging initiated by <NUM> core (5GC) or NG-RAN; establishment, maintenance and release of an RRC connection between the UE and NG-RAN; security functions including key management; establishment, configuration, maintenance and release of signalling radio bearers (SRBs) and data radio bearers (DRBs); mobility functions (including: handover and context transfer; UE cell selection and reselection and control of cell selection and reselection; Inter-RAT mobility); QoS management functions; UE measurement reporting and control of the reporting; detection of and recovery from radio link failure; NAS message transfer to/from NAS from/to UE.

In the 3GPP NR system, the main services and functions of the PDCP sublayer for the user plane include: sequence numbering; header compression and decompression: ROHC only; transfer of user data; reordering and duplicate detection; in-order delivery; PDCP PDU routing (in case of split bearers); retransmission of PDCP SDUs; ciphering, deciphering and integrity protection; PDCP SDU discard; PDCP re-establishment and data recovery for RLC AM; PDCP status reporting for RLC AM; duplication of PDCP PDUs and duplicate discard indication to lower layers. The main services and functions of the PDCP sublayer for the control plane include: sequence numbering; ciphering, deciphering and integrity protection; transfer of control plane data; reordering and duplicate detection; in-order delivery; duplication of PDCP PDUs and duplicate discard indication to lower layers.

The RLC sublayer supports three transmission modes: Transparent Mode (TM); Unacknowledged Mode (UM); and Acknowledged Mode (AM). The RLC configuration is per logical channel with no dependency on numerologies and/or transmission durations. In the 3GPP NR system, the main services and functions of the RLC sublayer depend on the transmission mode and include: Transfer of upper layer PDUs; sequence numbering independent of the one in PDCP (UM and AM); error correction through ARQ (AM only); segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs; reassembly of SDU (AM and UM); duplicate detection (AM only); RLC SDU discard (AM and UM); RLC re-establishment; protocol error detection (AM only).

In the 3GPP NR system, the main services and functions of the MAC sublayer include: mapping between logical channels and transport channels; multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels; scheduling information reporting; error correction through HARQ (one HARQ entity per cell in case of carrier aggregation (CA)); priority handling between UEs by means of dynamic scheduling; priority handling between logical channels of one UE by means of logical channel prioritization; padding. A single MAC entity may support multiple numerologies, transmission timings and cells. Mapping restrictions in logical channel prioritization control which numerology(ies), cell(s), and transmission timing(s) a logical channel can use. Different kinds of data transfer services are offered by MAC. To accommodate different kinds of data transfer services, multiple types of logical channels are defined i.e. each supporting transfer of a particular type of information. Each logical channel type is defined by what type of information is transferred. Logical channels are classified into two groups: Control Channels and Traffic Channels. Control channels are used for the transfer of control plane information only, and traffic channels are used for the transfer of user plane information only. Broadcast Control Channel (BCCH) is a downlink logical channel for broadcasting system control information, paging Control Channel (PCCH) is a downlink logical channel that transfers paging information, system information change notifications and indications of ongoing PWS broadcasts, Common Control Channel (CCCH) is a logical channel for transmitting control information between UEs and network and used for UEs having no RRC connection with the network, and Dedicated Control Channel (DCCH) is a point-to-point bi-directional logical channel that transmits dedicated control information between a UE and the network and used by UEs having an RRC connection. Dedicated Traffic Channel (DTCH) is a point-to-point logical channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and downlink. In Downlink, the following connections between logical channels and transport channels exist: BCCH can be mapped to BCH; BCCH can be mapped to downlink shared channel (DL-SCH); PCCH can be mapped to PCH; CCCH can be mapped to DL-SCH; DCCH can be mapped to DL-SCH; and DTCH can be mapped to DL-SCH. In Uplink, the following connections between logical channels and transport channels exist: CCCH can be mapped to uplink shared channel (UL-SCH); DCCH can be mapped to UL-SCH; and DTCH can be mapped to UL-SCH.

<FIG> illustrates an example of a frame structure in a 3GPP based wireless communication system.

The frame structure illustrated in <FIG> is purely exemplary and the number of subframes, the number of slots, and/or the number of symbols in a frame may be variously changed. In the 3GPP based wireless communication system, OFDM numerologies (e.g., subcarrier spacing (SCS), transmission time interval (TTI) duration) may be differently configured between a plurality of cells aggregated for one UE. For example, if a UE is configured with different SCSs for cells aggregated for the cell, an (absolute time) duration of a time resource (e.g. a subframe, a slot, or a TTI) including the same number of symbols may be different among the aggregated cells. Herein, symbols may include OFDM symbols (or CP-OFDM symbols), SC-FDMA symbols (or discrete Fourier transform-spread-OFDM (DFT-s-OFDM) symbols).

Referring to <FIG>, downlink and uplink transmissions are organized into frames. Each frame has Tf = <NUM> duration. Each frame is divided into two half-frames, where each of the half-frames has <NUM> duration. Each half-frame consists of <NUM> subframes, where the duration Tsf per subframe is <NUM>. Each subframe is divided into slots and the number of slots in a subframe depends on a subcarrier spacing. Each slot includes <NUM> or <NUM> OFDM symbols based on a cyclic prefix (CP). In a normal CP, each slot includes <NUM> OFDM symbols and, in an extended CP, each slot includes <NUM> OFDM symbols. The numerology is based on exponentially scalable subcarrier spacing Δf = <NUM>u* <NUM>. The following table shows the number of OFDM symbols per slot, the number of slots per frame, and the number of slots per for the normal CP, according to the subcarrier spacing △f = <NUM>"* <NUM>.

The following table shows the number of OFDM symbols per slot, the number of slots per frame, and the number of slots per for the extended CP, according to the subcarrier spacing △f = 2u*<NUM>.

A slot includes plural symbols (e.g., <NUM> or <NUM> symbols) in the time domain. For each numerology (e.g. subcarrier spacing) and carrier, a resource grid of Nsize,ugrid,x*NRBsc subcarriers and Nsubframe,usymb OFDM symbols is defined, starting at common resource block (CRB) Natart,ugrid indicated by higher-layer signaling (e.g. radio resource control (RRC) signaling), where Nsize,ugrid,x is the number of resource blocks in the resource grid and the subscript x is DL for downlink and UL for uplink. NRBsc is the number of subcarriers per resource blocks. In the 3GPP based wireless communication system, NRBsc is <NUM> generally. There is one resource grid for a given antenna port p, subcarrier spacing configuration u, and transmission direction (DL or UL). The carrier bandwidth Nsize,ugrid for subcarrier spacing configuration u is given by the higher-layer parameter (e.g. RRC parameter). Each element in the resource grid for the antenna port p and the subcarrier spacing configuration u is referred to as a resource element (RE) and one complex symbol may be mapped to each RE. Each RE in the resource grid is uniquely identified by an index k in the frequency domain and an index l representing a symbol location relative to a reference point in the time domain. In the 3GPP based wireless communication system, a resource block is defined by <NUM> consecutive subcarriers in the frequency domain.

In the 3GPP NR system, resource blocks are classified into CRBs and physical resource blocks (PRBs). CRBs are numbered from <NUM> and upwards in the frequency domain for subcarrier spacing configuration u. The center of subcarrier <NUM> of CRB <NUM> for subcarrier spacing configuration u coincides with 'point A' which serves as a common reference point for resource block grids. In the 3GPP NR system, PRBs are defined within a bandwidth part (BWP) and numbered from <NUM> to NsizeBWP,i-<NUM>, where i is the number of the bandwidth part. The relation between the physical resource block nPRB in the bandwidth part i and the common resource block nCRB is as follows: nPRB = nCRB + NsizeBWP,i, where NsizeBWP,i is the common resource block where bandwidth part starts relative to CRB <NUM>. The BWP includes a plurality of consecutive resource blocks. A carrier may include a maximum of N (e.g., <NUM>) BWPs. A UE may be configured with one or more BWPs on a given component carrier. Only one BWP among BWPs configured to the UE can active at a time. The active BWP defines the UE's operating bandwidth within the cell's operating bandwidth.

NR frequency bands are defined as <NUM> types of frequency range, FR1 and FR2. FR2 is may also called millimeter wave(mmW). The frequency ranges in which NR can operate are identified as described in Table <NUM>.

<FIG> illustrates a data flow example in the 3GPP NR system.

In <FIG>, "RB" denotes a radio bearer, and "H" denotes a header. Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers (SRB) for control plane data. The MAC PDU is transmitted/received using radio resources through the PHY layer to/from an external device. The MAC PDU arrives to the PHY layer in the form of a transport block.

In the PHY layer, the uplink transport channels UL-SCH and RACH are mapped to physical uplink shared channel (PUSCH) and physical random access channel (PRACH), respectively, and the downlink transport channels DL-SCH, BCH and PCH are mapped to physical downlink shared channel (PDSCH), physical broad cast channel (PBCH) and PDSCH, respectively. In the PHY layer, uplink control information (UCI) is mapped to PUCCH, and downlink control information (DCI) is mapped to PDCCH. A MAC PDU related to UL-SCH is transmitted by a UE via a PUSCH based on an UL grant, and a MAC PDU related to DL-SCH is transmitted by a BS via a PDSCH based on a DL assignment.

In order to transmit data unit(s) of the present disclosure on UL-SCH, a UE shall have uplink resources available to the UE. In order to receive data unit(s) of the present disclosure on DL-SCH, a UE shall have downlink resources available to the UE. The resource allocation includes time domain resource allocation and frequency domain resource allocation. In the present disclosure, uplink resource allocation is also referred to as uplink grant, and downlink resource allocation is also referred to as downlink assignment. An uplink grant is either received by the UE dynamically on PDCCH, in a Random Access Response, or configured to the UE semi-persistently by RRC. Downlink assignment is either received by the UE dynamically on the PDCCH, or configured to the UE semi-persistently by RRC signaling from the BS.

In UL, the BS can dynamically allocate resources to UEs via the Cell Radio Network Temporary Identifier (C-RNTI) on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible grants for uplink transmission when its downlink reception is enabled (activity governed by discontinuous reception (DRX) when configured). In addition, with Configured Grants, the BS can allocate uplink resources for the initial HARQ transmissions to UEs. Two types of configured uplink grants are defined: Type <NUM> and Type <NUM>. With Type <NUM>, RRC directly provides the configured uplink grant (including the periodicity). With Type <NUM>, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to Configured Scheduling RNTI (CS-RNTI) can either signal and activate the configured uplink grant, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC, until deactivated.

In DL, the BS can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible assignments when its downlink reception is enabled (activity governed by DRX when configured). In addition, with Semi-Persistent Scheduling (SPS), the BS can allocate downlink resources for the initial HARQ transmissions to UEs: RRC defines the periodicity of the configured downlink assignments while PDCCH addressed to CS-RNTI can either signal and activate the configured downlink assignment, or deactivate it. In other words, a PDCCH addressed to CS-RNTI indicates that the downlink assignment can be implicitly reused according to the periodicity defined by RRC, until deactivated.

<Resource allocation by PDCCH (i.e. resource allocation by DCI)>.

PDCCH can be used to schedule DL transmissions on PDSCH and UL transmissions on PUSCH, where the downlink control information (DCI) on PDCCH includes: downlink assignments containing at least modulation and coding format (e.g., modulation and coding scheme (MCS) index IMCS), resource allocation, and hybrid-ARQ information related to DL-SCH; or uplink scheduling grants containing at least modulation and coding format, resource allocation, and hybrid-ARQ information related to UL-SCH. The size and usage of the DCI carried by one PDCCH are varied depending on DCI formats. For example, in the 3GPP NR system, DCI format 0_0 or DCI format 0_1 is used for scheduling of PUSCH in one cell, and DCI format 1_0 or DCI format 1_1 is used for scheduling of PDSCH in one cell.

<FIG> illustrates an example of PDSCH time domain resource allocation by PDCCH, and an example of PUSCH time resource allocation by PDCCH.

Downlink control information (DCI) carried by a PDCCH for scheduling PDSCH or PUSCH includes a value m for a row index m+<NUM> to an allocation table for PDSCH or PUSCH. Either a predefined default PDSCH time domain allocation A, B or C is applied as the allocation table for PDSCH, or RRC configured pdsch-TimeDomainAllocationList is applied as the allocation table for PDSCH. Either a predefined default PUSCH time domain allocation A is applied as the allocation table for PUSCH, or the RRC configured pusch-TimeDomainAllocationList is applied as the allocation table for PUSCH. Which PDSCH time domain resource allocation configuration to apply and which PUSCH time domain resource allocation table to apply are determined according to a fixed/predefined rule (e.g. Table <NUM>. <NUM>-<NUM> in 3GPP TS <NUM> v15. <NUM>, Table <NUM>. <NUM>-<NUM> in 3GPP TS <NUM> v15.

Each indexed row in PDSCH time domain allocation configurations defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception. Each indexed row in PUSCH time domain allocation configurations defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be assumed in the PUSCH reception. K0 for PDSCH, or K2 for PUSCH is the timing difference between a slot with a PDCCH and a slot with PDSCH or PUSCH corresponding to the PDCCH. SLIV is a joint indication of starting symbol S relative to the start of the slot with PDSCH or PUSCH, and the number L of consecutive symbols counting from the symbol S. For PDSCH/PUSCH mapping type, there are two mapping types: one is Mapping Type A where demodulation reference signal (DMRS) is positioned in 3rd or 4th symbol of a slot depending on the RRC signaling, and other one is Mapping Type B where DMRS is positioned in the first allocated symbol.

The scheduling DCI includes the Frequency domain resource assignment field which provides assignment information on resource blocks used for PDSCH or PUSCH. For example, the Frequency domain resource assignment field may provide a UE with information on a cell for PDSCH or PUSCH transmission, information on a bandwidth part for PDSCH or PUSCH transmission, information on resource blocks for PDSCH or PUSCH transmission.

As mentioned above, in uplink, there are two types of transmission without dynamic grant: configured grant Type <NUM> where an uplink grant is provided by RRC, and stored as configured grant; and configured grant Type <NUM> where an uplink grant is provided by PDCCH, and stored or cleared as configured uplink grant based on L1 signaling indicating configured uplink grant activation or deactivation. Type <NUM> and Type <NUM> are configured by RRC per serving cell and per BWP. Multiple configurations can be active simultaneously only on different serving cells. For Type <NUM>, activation and deactivation are independent among the serving cells. For the same serving cell, the MAC entity is configured with either Type <NUM> or Type <NUM>.

A UE is provided with at least the following parameters via RRC signaling from a BS when the configured grant type <NUM> is configured:.

A UE is provided with at least the following parameters via RRC signaling from a BS when the configured gran Type <NUM> is configured:.

For configured uplink grants, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
<MAT>
where CURRENT_symbol = (SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS <NUM>. CURRENT_symbol refers to the symbol index of the first transmission occasion of a repetition bundle that takes place. A HARQ process is configured for a configured uplink grant if the configured uplink grant is activated and the associated HARQ process ID is less than nrofHARQ-Processes.

For downlink, a UE may be configured with semi-persistent scheduling (SPS) per serving cell and per BWP by RRC signaling from a BS. Multiple configurations can be active simultaneously only on different serving cells. Activation and deactivation of the DL SPS are independent among the serving cells. For DL SPS, a DL assignment is provided to the UE by PDCCH, and stored or cleared based on L1 signaling indicating SPS activation or deactivation. A UE is provided with the following parameters via RRC signaling from a BS when SPS is configured:.

When SPS is released by upper layers, all the corresponding configurations shall be released.

After a downlink assignment is configured for SPS, the UE considers sequentially that the Nth downlink assignment occurs in the slot for which: (numberOfSlotsPerFrame * SFN + slot number in the frame) = [(numberOfSlotsPerFrame * SFNstart time + slotstart time) + N * periodicity * numberOfSlotsPerFrame / <NUM>] modulo (<NUM> * numberOfSlotsPerFrame), where SFNstart time and slotstart time are the SFN and slot, respectively, of the first transmission of PDSCH where the configured downlink assignment was (re-)initialised.

For configured downlink assignments, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
<MAT>
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS <NUM>.

A UE validates, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or configured UL grant type <NUM> PDCCH if the cyclic redundancy check (CRC) of a corresponding DCI format is scrambled with CS-RNTI provided by the RRC parameter cs-RNTI and the new data indicator field for the enabled transport block is set to <NUM>. Validation of the DCI format is achieved if all fields for the DCI format are set according to Table <NUM> or Table <NUM>. Table <NUM> shows special fields for DL SPS and UL grant Type <NUM> scheduling activation PDCCH validation, and Table <NUM> shows special fields for DL SPS and UL grant Type <NUM> scheduling release PDCCH validation.

Actual DL assignment and actual UL grant, and the corresponding modulation and coding scheme are provided by the resource assignment fields (e.g. time domain resource assignment field which provides Time domain resource assignment value m, frequency domain resource assignment field which provides the frequency resource block allocation, modulation and coding scheme field) in the DCI format carried by the DL SPS and UL grant Type <NUM> scheduling activation PDCCH. If validation is achieved, the UE considers the information in the DCI format as valid activation or valid release of DL SPS or configured UL grant Type <NUM>.

For UL, the processor(s) <NUM> of the present disclosure may transmit (or control the transceiver(s) <NUM> to transmit) the data unit of the present disclosure based on the UL grant available to the UE. The processor(s) <NUM> of the present disclosure may receive (or control the transceiver(s) <NUM> to receive) the data unit of the present disclosure based on the UL grant available to the UE.

For DL, the processor(s) <NUM> of the present disclosure may receive (or control the transceiver(s) <NUM> to receive) DL data of the present disclosure based on the DL assignment available to the UE. The processor(s) <NUM> of the present disclosure may transmit (or control the transceiver(s) <NUM> to transmit) DL data of the present disclosure based on the DL assignment available to the UE.

The data unit(s) of the present disclosure is(are) subject to the physical layer processing at a transmitting side before transmission via radio interface, and the radio signals carrying the data unit(s) of the present disclosure are subject to the physical layer processing at a receiving side. For example, a MAC PDU including the PDCP PDU according to the present disclosure may be subject to the physical layer processing as follows.

<FIG> illustrates an example of physical layer processing at a transmitting side.

The following tables show the mapping of the transport channels (TrCHs) and control information to its corresponding physical channels. In particular, Table <NUM> specifies the mapping of the uplink transport channels to their corresponding physical channels, Table <NUM> specifies the mapping of the uplink control channel information to its corresponding physical channel, Table <NUM> specifies the mapping of the downlink transport channels to their corresponding physical channels, and Table <NUM> specifies the mapping of the downlink control channel information to its corresponding physical channel.

Data and control streams from/to MAC layer are encoded to offer transport and control services over the radio transmission link in the PHY layer. For example, a transport block from MAC layer is encoded into a codeword at a transmitting side. Channel coding scheme is a combination of error detection, error correcting, rate matching, interleaving and transport channel or control information mapping onto/splitting from physical channels.

In the 3GPP NR system, following channel coding schemes are used for the different types of TrCH and the different control information types.

For transmission of a DL transport block (i.e. a DL MAC PDU) or a UL transport block (i.e. a UL MAC PDU), a transport block CRC sequence is attached to provide error detection for a receiving side. In the 3GPP NR system, the communication device uses low density parity check (LDPC) codes in encoding/decoding UL-SCH and DL-SCH. The 3GPP NR system supports two LDPC base graphs (i.e. two LDPC base matrixes): LDPC base graph <NUM> optimized for small transport blocks and LDPC base graph <NUM> for larger transport blocks. Either LDPC base graph <NUM> or <NUM> is selected based on the size of the transport block and coding rate R. The coding rate R is indicated by the modulation coding scheme (MCS) index IMCS. The MCS index is dynamically provided to a UE by PDCCH scheduling PUSCH or PDSCH, provided to a UE by PDCCH activating or (re-)initializing the UL configured grant <NUM> or DL SPS, or provided to a UE by RRC signaling related to the UL configured grant Type <NUM>. If the CRC attached transport block is larger than the maximum code block size for the selected LDPC base graph, the CRC attached transport block may be segmented into code blocks, and an additional CRC sequence is attached to each code block. The maximum code block sizes for the LDPC base graph <NUM> and the LDPC base graph <NUM> are <NUM> bits and <NUM> bits, respectively. If the CRC attached transport block is not larger than the maximum code block size for the selected LDPC base graph, the CRC attached transport block is encoded with the selected LDPC base graph. Each code block of the transport block is encoded with the selected LDPC base graph. The LDPC coded blocks are then individually rat matched. Code block concatenation is performed to create a codeword for transmission on PDSCH or PUSCH. For PDSCH, up to <NUM> codewords (i.e. up to <NUM> transport blocks) can be transmitted simultaneously on the PDSCH. PUSCH can be used for transmission of UL-SCH data and layer <NUM>/<NUM> control information. Although not shown in <FIG>, the layer <NUM>/<NUM> control information may be multiplexed with the codeword for UL-SCH data.

The bits of the codeword are scrambled and modulated to generate a block of complex-valued modulation symbols.

The complex-valued modulation symbols of the codeword are mapped to one or more multiple input multiple output (MIMO) layers. A codeword can be mapped to up to <NUM> layers. A PDSCH can carry two codewords, and thus a PDSCH can support up to <NUM>-layer transmission. A PUSCH supports a single codeword, and thus a PUSCH can support up to <NUM>-layer transmission.

The DL transmission waveform is conventional OFDM using a cyclic prefix (CP). For DL, transform precoding (in other words, discrete Fourier transform (DFT)) is not applied.

The UL transmission waveform is conventional OFDM using a CP with a transform precoding function performing DFT spreading that can be disabled or enabled. In the 3GPP NR system, for UL, the transform precoding can be optionally applied if enabled. The transform precoding is to spread UL data in a special way to reduce peak-to-average power ratio (PAPR) of the waveform. The transform precoding is a form of DFT. In other words, the 3GPP NR system supports two options for UL waveform: one is CP-OFDM (same as DL waveform) and the other one is DFT-s-OFDM. Whether a UE has to use CP-OFDM or DFT-s-OFDM is configured by a BS via RRC parameters.

The layers are mapped to antenna ports. In DL, for the layers to antenna ports mapping, a transparent manner (non-codebook based) mapping is supported and how beamforming or MIMO precoding is performed is transparent to the UE. In UL, for the layers to antenna ports mapping, both the non-codebook based mapping and a codebook based mapping are supported.

For each antenna port (i.e. layer) used for transmission of the physical channel (e.g. PDSCH, PUSCH), the complex-valued modulation symbols are mapped to subcarriers in resource blocks allocated to the physical channel.

The communication device at the transmitting side generates a time-continuous OFDM baseband signal on antenna port p and subcarrier spacing configuration u for OFDM symbol <NUM> in a TTI for a physical channel by adding a cyclic prefix (CP) and performing IFFT. For example, for each OFDM symbol, the communication device at the transmitting side may perform inverse fast Fourier transform (IFFT) on the complex-valued modulation symbols mapped to resource blocks in the corresponding OFDM symbol and add a CP to the IFFT-ed signal to generate the OFDM baseband signal.

The communication device at the transmitting side up-convers the OFDM baseband signal for antenna port p, subcarrier spacing configuration u and OFDM symbol <NUM> to a carrier frequency f0 of a cell to which the physical channel is assigned.

The processors <NUM> and <NUM> in <FIG> may be configured to perform encoding, schrambling, modulation, layer mapping, transform precoding (for UL), subcarrier mapping, and OFDM modulation. The processors <NUM> and <NUM> may control the transceivers <NUM> and <NUM> connected to the processors <NUM> and <NUM> to up-convert the OFDM baseband signal onto the carrier frequency to generate radio frequency (RF) signals. The radio frequency signals are transmitted through antennas <NUM> and <NUM> to an external device.

<FIG> illustrates an example of physical layer processing at a receiving side.

The physical layer processing at the receiving side is basically the inverse processing of the physical layer processing at the transmitting side.

The communication device at a receiving side receives RF signals at a carrier frequency through antennas. The transceivers <NUM> and <NUM> receiving the RF signals at the carrier frequency down-converts the carrier frequency of the RF signals into the baseband in order to obtain OFDM baseband signals.

The communication device at the receiving side obtains complex-valued modulation symbols via CP detachment and FFT. For example, for each OFDM symbol, the communication device at the receiving side removes a CP from the OFDM baseband signals and performs FFT on the CP-removed OFDM baseband signals to obtain complex-valued modulation symbols for antenna port p, subcarrier spacing u and OFDM symbol <NUM>.

The subcarrier demapping is performed on the complex-valued modulation symbols to obtain complex-valued modulation symbols of a corresponding physical channel. For example, the processor(s) <NUM> may obtain complex-valued modulation symbols mapped to subcarriers belong to PDSCH from among complex-valued modulation symbols received in a bandwidth part. For another example, the processor(s) <NUM> may obtain complex-valued modulation symbols mapped to subcarriers belong to PUSCH from among complex-valued modulation symbols received in a bandwidth part.

Transform de-precoding (e.g. IDFT) is performed on the complex-valued modulation symbols of the uplink physical channel if the transform precoding has been enabled for the uplink physical channel. For the downlink physical channel and for the uplink physical channel for which the transform precoding has been disabled, the transform de-precoding is not performed.

The complex-valued modulation symbols are de-mapped into one or two codewords.

The complex-valued modulation symbols of a codeword are demodulated and descrambled into bits of the codeword.

The codeword is decoded into a transport block. For UL-SCH and DL-SCH, either LDPC base graph <NUM> or <NUM> is selected based on the size of the transport block and coding rate R. The codeword may include one or multiple coded blocks. Each coded block is decoded with the selected LDPC base graph into a CRC-attached code block or CRC-attached transport block. If code block segmentation was performed on a CRC-attached transport block at the transmitting side, a CRC sequence is removed from each of CRC-attached code blocks, whereby code blocks are obtained. The code blocks are concatenated into a CRC-attached transport block. The transport block CRC sequence is removed from the CRC-attached transport block, whereby the transport block is obtained. The transport block is delivered to the MAC layer.

In the above described physical layer processing at the transmitting and receiving sides, the time and frequency domain resources (e.g. OFDM symbol, subcarriers, carrier frequency) related to subcarrier mapping, OFDM modulation and frequency up/down conversion can be determined based on the resource allocation (e.g., UL grant, DL assignment).

For uplink data transmission, the processor(s) <NUM> of the present disclosure may apply (or control the transceiver(s) <NUM> to apply) the above described physical layer processing of the transmitting side to the data unit of the present disclosure to transmit the data unit wirelessly. For downlink data reception, the processor(s) <NUM> of the present disclosure may apply (or control the transceiver(s) <NUM> to apply) the above described physical layer processing of the receiving side to received radio signals to obtain the data unit of the present disclosure.

For downlink data transmission, the processor(s) <NUM> of the present disclosure may apply (or control the transceiver(s) <NUM> to apply) the above described physical layer processing of the transmitting side to the data unit of the present disclosure to transmit the data unit wirelessly. For uplink data reception, the processor(s) <NUM> of the present disclosure may apply (or control the transceiver(s) <NUM> to apply) the above described physical layer processing of the receiving side to received radio signals to obtain the data unit of the present disclosure.

<FIG> illustrates operations of the wireless devices based on the implementations of the present disclosure.

The first wireless device <NUM> of <FIG> may generate first information/signals according to the functions, procedures, and/or methods described in the present disclosure, and then transmit radio signals including the first information/signals wirelessly to the second wireless device <NUM> of <FIG> (S10). The first information/signals may include the data unit(s) (e.g. PDU, SDU, RRC message) of the present disclosure. The first wireless device <NUM> may receive radio signals including second information/signals from the second wireless device <NUM> (S30), and then perform operations based on or according to the second information/signals (S50). The second information/signals may be transmitted by the second wireless device <NUM> to the first wireless device <NUM> in response to the first information/signals. The second information/signals may include the data unit(s) (e.g. PDU, SDU, RRC message) of the present disclosure. The first information/signals may include contents request information, and the second information/signals may include contents specific to the usage of the first wireless device <NUM>. Some examples of operations specific to the usages of the wireless devices <NUM> and <NUM> will be described below.

In some scenarios, the first wireless device <NUM> may be a hand-held device 100d of <FIG>, which performs the functions, procedures, and/or methods described in the present disclosure. The hand-held device 100d may acquire information/signals (e.g., touch, text, voice, images, or video) input by a user, and convert the acquired information/signals into the first information/signals. The hand-held devices 100d may transmit the first information/signals to the second wireless device <NUM> (S10). The second wireless device <NUM> may be any one of the wireless devices 100a to 100f in <FIG> or a BS. The hand-held device 100d may receive the second information/signals from the second wireless device <NUM> (S30), and perform operations based on the second information/signals (S50). For example, the hand-held device 100d may output the contents of the second information/signals to the user (e.g. in the form of text, voice, images, video, or haptic) through the I/O unit of the hand-held device 100d.

In some scenarios, the first wireless device <NUM> may be a vehicle or an autonomous driving vehicle 100b, which performs the functions, procedures, and/or methods described in the present disclosure. The vehicle 100b may transmit (S10) and receive (S30) signals (e.g. data and control signals) to and from external devices such as other vehicles, BSs (e.g. gNBs and road side units), and servers, through its communication unit (e.g. communication unit <NUM> of FIG. The vehicle 100b may include a driving unit, and the driving unit may cause the vehicle 100b to drive on a road. The driving unit of the vehicle 100b may include an engine, a motor, a powertrain, a wheel, a brake, a steering device, etc. The vehicle 100b may include a sensor unit for acquiring a vehicle state, ambient environment information, user information, etc. The vehicle 100b may generate and transmit the first information/signals to the second wireless device <NUM> (S10). The first information/signals may include vehicle state information, ambient environment information, user information, and etc. The vehicle 100b may receive the second information/signals from the second wireless device <NUM> (S30). The second information/signals may include vehicle state information, ambient environment information, user information, and etc. The vehicle 100b may drive on a road, stop, or adjust speed, based on the second information/signals (S50). For example, the vehicle 100b may receive map the second information/signals including data, traffic information data, etc. from an external server (S30). The vehicle 100b may generate an autonomous driving path and a driving plan based on the second information/signals, and may move along the autonomous driving path according to the driving plan (e.g., speed/direction control) (S50). For another example, the control unit or processor(s) of the vehicle 100b may generate a virtual object based on the map information, traffic information, and vehicle position information obtained through a GPS sensor of the vehicle 100b and an I/O unit <NUM> of the vehicle 100b may display the generated virtual object in a window in the vehicle 100b (S50).

In some scenarios, the first wireless device <NUM> may be an XR device 100c of <FIG>, which performs the functions, procedures, and/or methods described in the present disclosure. The XR device 100c may transmit (S10) and receive (S30) signals (e.g., media data and control signals) to and from external devices such as other wireless devices, hand-held devices, or media servers, through its communication unit (e.g. communication unit <NUM> of FIG. For example, the XR device 100c transmits content request information to another device or media server (S10), and download/stream contents such as films or news from another device or the media server (S30), and generate, output or display an XR object (e.g. an AR/VR/MR object), based on the second information/signals received wirelessly, through an I/O unit of the XR device (S50).

In some scenarios, the first wireless device <NUM> may be a robot 100a of <FIG>, which performs the functions, procedures, and/or methods described in the present disclosure. The robot 100a may be categorized into an industrial robot, a medical robot, a household robot, a military robot, etc., according to a used purpose or field. The robot 100a may transmit (S10) and receive (S30) signals (e.g., driving information and control signals) to and from external devices such as other wireless devices, other robots, or control servers, through its communication unit (e.g. communication unit <NUM> of FIG. The second information/signals may include driving information and control signals for the robot 100a. The control unit or processor(s) of the robot 100a may control the movement of the robot 100a based on the second information/signals.

In some scenarios, the first wireless device <NUM> may be an AI device <NUM> of <FIG>. The AI device may be implemented by a fixed device or a mobile device, such as a TV, a projector, a smartphone, a PC, a notebook, a digital broadcast terminal, a tablet PC, a wearable device, a Set Top Box (STB), a radio, a washing machine, a refrigerator, a digital signage, a robot, a vehicle, etc. The AI device <NUM> may transmit (S10) and receive (S30) wired/radio signals (e.g., sensor information, user input, learning models, or control signals) to and from external devices such as other AI devices (e.g., 100a,. , 100f, <NUM>, or <NUM> of <FIG>) or an AI server (e.g., <NUM> of <FIG>) using wired/wireless communication technology. The control unit or processor(s) of the AI device <NUM> may determine at least one feasible operation of the AI device <NUM>, based on information which is determined or generated using a data analysis algorithm or a machine learning algorithm. The AI device <NUM> may request that external devices such as other AI devices or AI server provide the AI device <NUM> with sensor information, user input, learning models, control signals and etc. (S10). The AI device <NUM> may receive second information/signals (e.g., sensor information, user input, learning models, or control signals) (S30), and the AI device <NUM> may perform a predicted operation or an operation determined to be preferred among at least one feasible operation based on the second information/signals (S50).

Hereinafter, a random access (RA) procedure of the NR system is described.

In the NR system, two types of random access procedure are supported: <NUM>-step RA type with Msg1 and <NUM>-step RA type with MsgA.

<FIG> show examples of a random access procedure supported by the NR system. Both types of RA procedure support contention-based random access (CBRA) and contention-free random access (CFRA) as shown on <FIG>.

The UE selects the type of random access at initiation of the random access procedure based on network configuration. More specifically, when CFRA resources are not configured, an RSRP threshold is used by the UE to select between <NUM>-step RA type and <NUM>-step RA type. When CFRA resources for <NUM>-step RA type are configured, the UE selects <NUM>-step RA type. Further, when CFRA resources for <NUM>-step RA type are configured, the UE selects <NUM>-step RA type.

The network does not configure CFRA resources for <NUM>-step and <NUM>-step RA types at the same time for a Bandwidth Part (BWP), and CFRA with <NUM>-step RA type is only supported for handover.

The MsgA of the <NUM>-step RA type includes a preamble on PRACH and a payload on PUSCH. After MsgA transmission, the UE monitors for a response from the network within a configured window.

For CFRA, upon receiving the network response, the UE ends the random access procedure as shown in <FIG>. For CBRA, if contention resolution is successful upon receiving the network response, the UE ends the random access procedure as shown in <FIG>.

While, if a fallback indication is received in MsgB, the UE performs MsgB transmission and monitors contention resolution as shown in <FIG>. If contention resolution is not successful after Msg3 (re)transmission(s), the UE goes back to MsgA transmission.

If the <NUM>-step random access procedure is not completed after a number of MsgA transmissions, the UE can be configured to switch to <NUM>-step CBRA procedure.

Further, the <NUM>-step RA is used for the UE to transmit small and infrequent data while in RRC_INACTIVE state.

In <NUM>-step RA, after a UE transmits data with an RA preamble (which is called MsgA), the UE starts an RAR window (by using a timer called msgB-ResponseWindow), and monitors a response from a network (which is called MsgB where the MsgB includes either a successRAR or a fallbackRAR or both), within the RAR window.

If the successRAR is received within the RAR window, the UE considers that the transmission of the data in MsgA was successful.

Else, if the fallbackRAR is received within the RAR window, the UE considers that the transmission of the RA preamble in MsgA was successful but the transmission of the data in MsgA was not successful, and retransmits the data using the UL grant included in the fallbackRAR.

Else, if neither the successRAR nor the fallbackRAR is received within the RAR window, the UE reselects an RA preamble and retransmits the data together with the reselected RA preamble in MsgA.

Meanwhile, when a Random Access (RA) procedure is triggered, the UE selects a cell and a Bandwidth Part (BWP) of the cell, and performs the RA procedure on the selected BWP.

If the UE receives a BWP switch indication (by PDCCH or RRC signaling) while a RA procedure is ongoing, the UE may either ignore the BWP switch indication or switch to a new BWP indicated by the BWP switch indication.

When the UE decides to ignore the BWP switch indication, the UE keeps performing the RA procedure on the selected BWP. However, when the UE decides to switch to a new BWP, the UE stops the ongoing RA procedure on the selected BWP, and initiates a new RA procedure on the new BWP.

Meanwhile, in recent 3GPP standard, it is considered that a UE in RRC_INACTIVE state can transmit data without transitioning to RRC_CONNECTED state. The data transmitted in RRC_INACTIVE state is typically small and infrequent, and fits to one MAC PDU size. The UE in the RRC_INACTIVE state transmits data using a <NUM>-step or a <NUM>-step RA procedure (RA-SDT), or using a configured grant (SDT-CG).

Not all data can be transmitted in RRC_INACTIVE state. Which data is allowed to be transmitted in RRC_INACTIVE state is configured by the network depending on the data characteristics.

The network configures for each radio bearer or logical channel of the UE whether the data transmission of each radio bearer or logical channel is allowed in RRC_INACTIVE state. The data that can be transmitted in RRC_INACTIVE state is called as SDT data, and the data that cannot be transmitted in RRC_INACTIVE state is called as non-SDT data.

When a non-SDT data is generated in RRC_INACTIVE state, the UE triggers a RRC Resume procedure to re-connect to the gNB. The RRC Resume procedure is performed by a RA procedure, where the RRC Resume Request message is transmitted in MsgA (for <NUM>-step RA procedure) or Msg3 (for <NUM>-step RA procedure).

The RRC Resume Request message includes I-RNTI and MAC-I. The I-RNTI is used to identify the UE and the last serving gNB. The MAC-I is used to authenticate the transmitted RRC message.

After the RA procedure is successfully completed, the UE resumes the RRC connection to the gNB (i.e., transits to RRC_CONNECTED state), and transmits the non-SDT data in RRC_CONNECTED state.

On the other hand, when a SDT data is generated in RRC_INACTIVE state, the UE triggers a SDT procedure to transmit the SDT data in RRC_INACTIVE state. The UE selects one between RA-SDT procedure and SDT-CG procedure. During the SDT procedure, the UE transmits the SDT data together with RRC Resume Request message.

The RRC Resume Request message is transmitted via SRBO, where security (i.e., ciphering and integrity protection) is not applied. The SRBO does not use PDCP entity, and thus security is not applied. The SRBO uses common control channel (CCCH) as a logical channel.

While the UE performs a SDT procedure to transmit SDT data, it is possible that non-SDT data is generated. In this case, the UE should resume the RRC connection to transmit the non-SDT data. For this, the UE should trigger a new RA procedure and transmits a new RRC Resume Request message.

However, there is a security concern on RRC Resume Request message because security is not applied to the RRC Resume Request message. Thus, it is also considered to transmit RRC Resume Request message with security applied. In this case, the RRC Resume Request message is transmitted through dedicated control channel (DCCH).

The problem in transmitting RRC Resume Request message using DCCH is that the message itself is security protected. It means that if the network cannot identify the UE who transmits the RRC Resume Request message, then the network cannot decode the RRC Resume Request message because the network does not know the security key used for ciphering of the RRC Resume Request message.

Therefore, a mechanism should be introduced to maximize secured RRC Resume Request message transmission without causing decoding problem due to security.

To maximize secured RRC Resume Request message transmission without causing decoding problem in the network, it is suggested that the UE should transmit a RRC Resume Request message with ciphering applied (i.e., ciphered RRC Resume Request message) if a UL grant dedicated to the UE is available. If the UL grant dedicated to the UE is not available, the UE transmits the RRC Resume Request message with ciphering not applied (i.e., unciphered RRC Resume Request message) using a RA procedure.

The RRC Resume Request message includes I-RNTI and MAC-I. The I-RNTI is used to identify the UE and the last serving gNB. The MAC-I is used to authenticate the transmitted RRC Resume Request message.

The ciphered RRC Resume Request message is transmitted through dedicated control channel (DCCH). A new signaling radio bearer (e.g., SRB0a) may be used. Or, SRBO may be modified to transmit via DCCH. To apply ciphering to the RRC Resume Request message, PDCP entity is used.

The unciphered RRC Resume Request message is transmitted through common control channel (CCCH). The SRBO used in the prior art is used as it is. The SRBO does not use PDCP entity.

Hereinafter, it is described detailed operations of performing a random access (RA) procedure for a data transmission, based on the present disclosure.

When a UE moves to RRC_INACTIVE state from RRC_CONNECTED state, the UE receives an information about which radio bearer can transmit data in RRC_INACTIVE state, and an information of RA resource that can be used for SDT data transmission.

If a SDT data is generated while the UE is in RRC_INACTIVE state, the UE triggers a RA-SDT procedure to transmit the SDT data in RRC_INACTIVE state, if the SDT data belongs to the radio bearer that is allowed for UL transmission in RRC_INACTIVE state.

The UE RRC generates a RRC Resume Request message including I-RNTI and MAC-I. The UE RRC delivers the RRC Resume Request message to UE MAC through CCCH without applying security.

The UE MAC generates a MAC PDU including the CCCH SDU (i.e., unciphered RRC Resume Request message) and the SDT data, and transmits it to the network in MsgA (for <NUM>-step RA procedure) or Msg3 (for <NUM>-step RA procedure).

While the RA-SDT procedure is ongoing, a non-SDT data is generated.

The UE RRC generates a new RRC Resume Request message including I-RNTI and MAC-I. Whether to apply security to the new RRC Resume Request message depends on whether dedicated UL grant is available or not.

Case <NUM> - The UE has not received a UL grant in MsgB (for <NUM>-step RA procedure) or Msg4 (for <NUM>-step RA procedure).

Case <NUM> - The UE receives a UL grant in MsgB (for <NUM>-step RA procedure) or Msg4 (for <NUM>-step RA procedure) in RA-SDT procedure but contention resolution of the MsgB or Msg4 is not successful.

Case <NUM> - The UE receives a UL grant in MsgB (for <NUM>-step RA procedure) or Msg4 (for <NUM>-step RA procedure) in RA-SDT procedure and contention resolution of the MsgB or Msg4 is successful.

Case <NUM> - The UE receives a UL grant in PDCCH (i.e., dynamic UL grant) for subsequent SDT data transmission after the successful completion of RA-SDT procedure.

Case <NUM> - The UE is configured with configured grant (i.e., SDT-CG) dedicated to the UE.

In Cases <NUM> and <NUM>, the UE considers that dedicated UL grant is not available. In those cases, the UE triggers a new RA procedure that is used to transit the UE to RRC_CONNECTED STATE (i.e., normal RA procedure). The UE may stop the ongoing RA-SDT procedure. The UE RRC delivers the new RRC Resume Request message to the UE MAC through CCCH without applying security. The UE MAC generates a MAC PDU including the CCCH SDU (i.e. unciphered RRC Resume Request message), and transmits it to the network in MsgA or Msg3 of the new RA procedure.

In Cases <NUM> and <NUM>, the UE considers that dedicated UL grant is available. In those cases, the UE does not triggered a new RA procedure but transmits the new RRC Resume Request message using the dedicated UL grant. The UE RRC delivers the new RRC Resume Request message to the UE PDCP to apply security, and then delivers the ciphered RRC Resume Request message to the UE MAC through DCCH. The UE MAC generates a MAC PDU including the DCCH SDU (i.e., ciphered RRC Resume Request message), and transmits it to the network using the dedicated UL grant.

The Case <NUM> is similar to Cases <NUM> and <NUM> in that the dedicated UL grant is available. The UE transmits the new RRC Resume Request message through DCCH with security applied. The difference is that the Case <NUM> can be used regardless of Cases <NUM>-<NUM>. In other words, if the UE is configured with SDT-CG resource, the UE considers that dedicated UL grant is available even in case of Cases <NUM> and <NUM>.

After transmitting the new RRC Resume Request message, the UE transits to RRC_CONNECTED state if a response message of the RRC Resume Request message (i.e. RRC Resume message) is successfully received. After transitioning to RRC_CONNECTED state, the UE transmits the non-SDT data using a new UL grant dedicated to the UE.

<FIG> shows an example of performing a random access (RA) procedure for a data transmission based on the implementations of the present disclosure.

Referring to <FIG>, in S1301, the UE receives RB configuration information and RA-SDT configuration information from the network via RRC signaling. The RB configuration information includes which RB is allowed to transmit data in RRC_INACTIVE, and the RA-SDT configuration information includes RA resource, RA opportunity, RSRP threshold for SDT data transmission.

When the UE generates a SDT data in S1302, the UE triggers a <NUM>-step RA-SDT procedure to transmit the SDT data in RRC_INACTIVE state in S1303.

In S1304, The UE generates a RRC Resume Request message without applying security. The UE generates a CCCH SDU including unciphered RRC Resume Request message.

Then, the UE performs RA procedures for a data transmission (i.e., RA-SDT procedure) in S1305-S1307. Especially, the UE transmits it together with the SDT data in Msg3 of the RA-SDT procedure in S1307.

Further, in S1308, the UE receives Msg4 including contention resolution ID (i.e., echo-backed CCCH SDU) and UL grant. The Msg4 does not include RRC Resume message because the RA-SDT procedure is not used for transitioning the UE to RRC_CONNECTED state.

Then, in S1309, the UE performs contention resolution. The UE considers the UL grant received in Msg4 is dedicated to the UE after contention resolution is successful.

Meanwhile, the UE generates a non-SDT data in S1310. As the dedicated UL grant is available, according to the present invention, the UE generates a new RRC Resume Request message with security applied. The UE generates a DCCH SDU including ciphered RRC Resume Request message in S1311, and transmits it to the network in S1312 using the UL grant received in Msg4.

Then, the UE transits to RRC_CONNECTED state when the UE receives a RRC Resume message in S1313. As a response of the RRC Resume message, the UE transmits a RRC Resume complete message in S1314.

After transitioning to RRC_CONNECTED state, the UE receives a new UL grant dedicated to the UE in S1315, and transmits the non-SDT data using a new UL grant in S1316.

<FIG> shows another example of performing a random access (RA) procedure for a data transmission based on the implementations of the present disclosure.

Referring to <FIG>, in S1401, the UE receives RB configuration information and RA-SDT configuration information from the network via RRC signaling. The RB configuration information includes which RB is allowed to transmit data in RRC_INACTIVE state, state and the RA-SDT configuration information includes RA resource, RA opportunity, RSRP threshold for SDT data transmission.

When the UE generates a SDT data in S1402, the UE triggers a <NUM>-step RA-SDT procedure to transmit the SDT data in RRC_INACTIVE state in S1403.

In S1404, The UE generates a RRC Resume Request message without applying security. The UE generates a CCCH SDU including unciphered RRC Resume Request message.

Then, the UE performs RA procedures for a data transmission (i.e., RA-SDT procedure) in S1405-S1407. Especially, the UE transmits it together with the SDT data in Msg3 of the RA-SDT procedure in S1407.

However, according to <FIG>, the UE generates a non-SDT data before receiving Msg4 such as S1408. As dedicated UL grant is not available, the UE generates a new RRC Resume Request message without security applied in S1409. That is, the UE generates a new CCCH SDU including unciphered RRC Resume Request message.

Especially, according to the present invention, the UE stops ongoing RA-SDT procedure and triggers a new normal RA procedure in S1410. The UE transmits the new CCCH SDU in Msg3 of the normal RA procedure in S1411-S1414.

After the UE receives Msg4 and contention resolution is successful such as S1415, the UE transits to RRC_CONNECTED state. In S1414, it is shown that the Msg4 includes RRC Resume message because the normal RA procedure is used for transitioning the UE to RRC_CONNECTED state. As a response of the RRC Resume message, the UE transmits a RRC Resume complete message in S1416.

After transitioning to RRC_CONNECTED state, the UE receives a new UL grant dedicated to the UE in S1417, and transmits the non-SDT data using a new UL grant in S1418.

Claim 1:
A method for performing data transmissions in a Radio Resource Control, RRC, INACTIVE state by a user equipment, UE, in a wireless communication system, the method comprising:
generating a first data that can be transmitted in the RRC_INACTIVE state;
triggering a first random access, RA, procedure for transmitting the first data in the RRC_INACTIVE state;
generating a second data that cannot be transmitted in the RRC_INACTIVE state while the first RA procedure is ongoing; and
transmitting a RRC message for transitioning to a RRC CONNECTED state,
wherein, based on the second data being generated after a contention resolution succeeds, the ciphering is applied to the RRC message,
wherein, based on the second data being generated before the contention resolution succeeds, the ciphering is not applied to the RRC message, and
wherein, based on the second data being generated before the contention resolution succeeds, the first RA procedure is stopped and a second RA procedure for transitioning to the RRC CONNECTED state is started.