CN114205920B - Method and apparatus for small data transfer procedure in wireless communication system - Google Patents
Method and apparatus for small data transfer procedure in wireless communication system Download PDFInfo
- Publication number
- CN114205920B CN114205920B CN202110989915.XA CN202110989915A CN114205920B CN 114205920 B CN114205920 B CN 114205920B CN 202110989915 A CN202110989915 A CN 202110989915A CN 114205920 B CN114205920 B CN 114205920B
- Authority
- CN
- China
- Prior art keywords
- configuration
- procedure
- related configuration
- sdt
- rrc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 494
- 238000012546 transfer Methods 0.000 title claims abstract description 65
- 238000004891 communication Methods 0.000 title abstract description 34
- 230000005540 biological transmission Effects 0.000 claims abstract description 344
- 230000000977 initiatory effect Effects 0.000 claims abstract description 14
- 238000011084 recovery Methods 0.000 claims description 16
- 101150096310 SIB1 gene Proteins 0.000 claims description 6
- 238000005259 measurement Methods 0.000 description 84
- 230000004044 response Effects 0.000 description 36
- 230000007704 transition Effects 0.000 description 25
- 230000001960 triggered effect Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 14
- 230000011664 signaling Effects 0.000 description 14
- 101150014328 RAN2 gene Proteins 0.000 description 9
- 238000013508 migration Methods 0.000 description 9
- 230000005012 migration Effects 0.000 description 9
- 230000009471 action Effects 0.000 description 8
- 230000000737 periodic effect Effects 0.000 description 8
- 230000008569 process Effects 0.000 description 7
- 101001055444 Homo sapiens Mediator of RNA polymerase II transcription subunit 20 Proteins 0.000 description 6
- 102100026165 Mediator of RNA polymerase II transcription subunit 20 Human genes 0.000 description 6
- 108091005487 SCARB1 Proteins 0.000 description 5
- 102100037118 Scavenger receptor class B member 1 Human genes 0.000 description 5
- 239000000725 suspension Substances 0.000 description 5
- 230000007774 longterm Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000001143 conditioned effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 239000011159 matrix material Substances 0.000 description 3
- 101100533725 Mus musculus Smr3a gene Proteins 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000002245 particle Substances 0.000 description 2
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 2
- 101100150273 Caenorhabditis elegans srb-1 gene Proteins 0.000 description 1
- 101100240462 Homo sapiens RASAL2 gene Proteins 0.000 description 1
- 101100274486 Mus musculus Cited2 gene Proteins 0.000 description 1
- 101150074586 RAN3 gene Proteins 0.000 description 1
- 102100035410 Ras GTPase-activating protein nGAP Human genes 0.000 description 1
- 101150096622 Smr2 gene Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000005022 packaging material Substances 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access, e.g. scheduled or random access
- H04W74/002—Transmission of channel access control information
- H04W74/006—Transmission of channel access control information in the downlink, i.e. towards the terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/02—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas
- H04B7/04—Diversity systems; Multi-antenna system, i.e. transmission or reception using multiple antennas using two or more spaced independent antennas
- H04B7/0413—MIMO systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0044—Arrangements for allocating sub-channels of the transmission path allocation of payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/0091—Signaling for the administration of the divided path
- H04L5/0094—Indication of how sub-channels of the path are allocated
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/08—Testing, supervising or monitoring using real traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/12—Wireless traffic scheduling
- H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
- H04W72/1268—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows of uplink data flows
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access, e.g. scheduled or random access
- H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
- H04W74/0833—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a random access procedure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0048—Allocation of pilot signals, i.e. of signals known to the receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
Abstract
A method and apparatus for small data transfer procedures in a wireless communication system are disclosed from the perspective of a user equipment. In one embodiment, the method includes a user equipment receiving a first physical downlink control channel related configuration in system information. The method further includes the user equipment initiating a small data transfer procedure in an rrc_inactive state, wherein the small data transfer procedure includes a random access procedure and at least one subsequent transfer after the random access procedure. The method also includes the user equipment listening to the physical downlink control channel based on the first physical downlink control channel related configuration during the random access procedure in the rrc_inactive state. In addition, the method includes the user equipment listening to the physical downlink control channel in the rrc_inactive state for at least one subsequent transmission based on the second physical downlink control channel related configuration, if the second physical downlink control channel related configuration is received by the user equipment.
Description
Cross Reference to Related Applications
The present application claims the benefits of U.S. provisional patent applications No. 63/079,890, 63/079,897, 63/079,911, and 63/079,934, filed on even 17 a 9/2020, the entire disclosures of which are incorporated herein by reference in their entirety.
Technical Field
The present disclosure relates generally to wireless communication networks and, more particularly, to methods and apparatus for small data transfer (Small Data Transmission, SDT) procedures in wireless communication systems.
Background
With the rapid increase in demand for large amounts of data to and from mobile communication devices, conventional mobile voice communication networks evolve into networks that communicate with internet protocol (Internet Protocol, IP) data packets. Such IP packet communications may provide voice over IP, multimedia, multicast, and on-demand communication services for users of mobile communication devices.
An exemplary network structure is the evolved universal terrestrial radio access network (E-UTRAN). The E-UTRAN system may provide high data throughput for implementing the above-described IP-bearing voice and multimedia services. Currently, the 3GPP standards organization is discussing new next generation (e.g., 5G) radio technologies. Thus, changes to the current body of the 3GPP standard are currently being submitted and considered to evolve and complete the 3GPP standard.
Disclosure of Invention
A method and apparatus are disclosed from the perspective of a User Equipment (UE). In one embodiment, the method includes a UE receiving a first Physical Downlink Control Channel (PDCCH) -related configuration in system information. The method further includes the UE initiating a Small Data Transfer (SDT) procedure in an rrc_inactive state, wherein the SDT procedure includes a Random Access (RA) procedure and at least one subsequent transfer following the RA procedure. The method also includes the UE listening to the PDCCH during the RA procedure in the rrc_inactive state based on the first PDCCH-related configuration. In addition, the method includes, in the event that the UE receives the second PDCCH-related configuration, the UE listening to the PDCCH in the rrc_inactive state for the at least one subsequent transmission based on the second PDCCH-related configuration.
Drawings
Fig. 1 illustrates a diagram of a wireless communication system according to an example embodiment;
fig. 2 is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an example embodiment;
FIG. 3 is a functional block diagram of a communication system according to an exemplary embodiment;
FIG. 4 is a functional block diagram of the program code of FIG. 3 according to one exemplary embodiment;
FIG. 5 is a reproduction of FIG. 9.2.2.4.1-1 of 3GPP TS 38.300 V16.2.0;
FIG. 6 is a reproduction of FIG. 9.2.2.4.1-2 of 3GPP TS 38.300 V16.2.0;
FIG. 7 is a reproduction of FIG. 9.2.2.4.1-3 of 3GPP TS 38.300 V16.2.0;
FIG. 8 is a reproduction of FIG. 9.2.2.4.2-1 of 3GPP TS 38.300 V16.2.0;
fig. 9 is a reproduction of fig. 4.2.1-1 of 3GPP TS 38.331 V16.1.0;
FIG. 10 is a reproduction of FIG. 5.3.8.1-1 of 3GPP TS 38.331 V16.1.0;
FIG. 11 is a reproduction of FIG. 5.3.13.1-1 of 3GPP TS 38.331 V16.1.0;
FIG. 12 is a reproduction of FIG. 5.3.13.1-2 of 3GPP TS 38.331 V16.1.0;
FIG. 13 is a reproduction of FIG. 5.3.13.1-3 of 3GPP TS 38.331 V16.1.0;
FIG. 14 is a reproduction of FIG. 5.3.13.1-4 of 3GPP TS 38.331 V16.1.0;
FIG. 15 is a reproduction of FIG. 5.3.13.1-5 of 3GPP TS 38.331 V16.1.0;
fig. 16 illustrates a first example of an SDT in an rrc_inactive state in which a UE remains in the rrc_inactive state after performing the SDT, according to one example embodiment;
fig. 17 illustrates a second example of SDT in rrc_inactive state in which the SDT procedure rolls back to rrcreseume, according to an example embodiment;
fig. 18 shows a third example of SDT in rrc_inactive state where the SDT procedure rolls back to RRCSetup, according to one example embodiment;
Fig. 19 illustrates a first example in which there is one subsequent UL transmission in the SDT in the rrc_inactive state, according to an example embodiment;
fig. 20 illustrates a second example in which there is one subsequent UL transmission in the SDT in the rrc_inactive state, according to one example embodiment;
fig. 21 illustrates a first example in which there is one subsequent DL transfer in the SDT in the rrc_inactive state, according to an example embodiment;
fig. 22 illustrates a second example of the presence of one subsequent DL transfer in the SDT in the rrc_inactive state according to an example embodiment;
FIG. 23 is a diagram according to an exemplary embodiment;
FIG. 24 is a diagram according to an exemplary embodiment;
FIG. 25 is a flowchart in accordance with an exemplary embodiment;
FIG. 26 is a flowchart in accordance with an exemplary embodiment;
FIG. 27 is a flowchart in accordance with an exemplary embodiment.
Detailed Description
The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (code division multiple access, CDMA), time division multiple access (time division multiple access, TDMA), orthogonal frequency division multiple access (orthogonal frequency division multiple access, OFDMA), 3GPP long term evolution (Long Term Evolution, LTE) Radio access, 3GPP long term evolution-advanced (Long Term Evolution Advanced, LTE-a or LTE-advanced), 3GPP2 ultra mobile broadband (Ultra Mobile Broadband, UMB), wiMax, 3GPP New Radio (NR), or some other modulation technique.
In particular, the exemplary wireless communication system apparatus described below may be designed to support one or more standards, such as those provided by an association named "third generation partnership project" (referred to herein as 3 GPP), including: TS 38.300V16.2.0, "NR, NR and NG-RAN overview, phase 2"; TS 38.321 V16.1.0, "NR, media Access Control (MAC) protocol Specification"; TS 38.331 V16.1.0, "NR, radio Resource Control (RRC) protocol Specification"; RP-193252, "work items on NR small data transfers in INACTIVE state", an emerging company; 3GPP RAN2#111 conference record; and TS 38.213 V16.2.0, "NR," physical layer procedure for control. The standards and documents listed above are expressly incorporated herein by reference in their entirety.
Fig. 1 illustrates a multiple access wireless communication system according to one embodiment of the present invention. The access network 100 (AN) includes multiple antenna groups, one including 104 and 106, another including 108 and 110, and yet another including 112 and 114. In fig. 1, only two antennas are shown for each antenna group, but more or fewer antennas may be utilized for each antenna group. Access terminal 116 (AT) is in communication with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 over forward link 120 and receive information from access terminal 116 over reverse link 118. An Access Terminal (AT) 122 is in communication with antennas 106 and 108, where antennas 106 and 108 transmit information to Access Terminal (AT) 122 over forward link 126 and receive information from Access Terminal (AT) 122 over reverse link 124. In an FDD system, communication links 118, 120, 124 and 126 may use different frequencies for communication. For example, forward link 120 may use a different frequency than that used by reverse link 118.
Each group of antennas and/or the area in which they are designed to communicate is often referred to as a sector of an access network. In an embodiment, antenna groups each are designed to communicate to access terminals in a sector of the areas covered by access network 100.
In communication via forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve signal-to-noise ratio of forward links for the different access terminals 116 and 122. And an access network using beamforming to transmit to access terminals scattered randomly through its coverage causes less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to all its access terminals.
AN Access Network (AN) may be a fixed station or base station used for communicating with the terminals and may also be referred to as AN access point, a Node B, a base station, AN enhanced base station, AN evolved Node B (eNB), a network Node, a network, or some other terminology. An Access Terminal (AT) may also be referred to as a User Equipment (UE), a wireless communication device, a terminal, an access terminal, or some other terminology.
Fig. 2 is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an Access Terminal (AT) or User Equipment (UE)) in a MIMO system 200. At the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a Transmit (TX) data processor 214.
In one embodiment, each data stream is transmitted via a respective transmit antenna. TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.
Coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor 230.
The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which TX MIMO processor 220 may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 220 then provides NT modulation symbol streams to NT transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.
Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. NT modulated signals from transmitters 222a through 222t are then transmitted from NT antennas 224a through 224t, respectively.
At receiver system 250, the transmitted modulated signals are received by NR antennas 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.
An RX data processor 260 then receives and processes the NR received symbol streams from NR receivers 254 based on a particular receiver processing technique to provide NT "detected" symbol streams. RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX processor 260 is complementary to that performed by TX MIMO processor 220 and TX data processor 214 at transmitter system 210.
The processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.
The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 238 (which TX data processor 238 also receives traffic data for a number of data streams from a data source 236), modulated by a modulator 280, conditioned by transmitters 254a through 254r, and transmitted back to transmitter system 210.
At transmitter system 210, the modulated signals from receiver system 250 are received by antennas 224, conditioned by receivers 222, demodulated by a demodulator 240, and processed by a RX data processor 242 to extract the reverse link message transmitted by receiver system 250. Processor 230 then determines which pre-coding matrix to use to determine the beamforming weights and then processes the extracted message.
Turning to fig. 3, this figure illustrates an alternative simplified functional block diagram of a communication device in accordance with one embodiment of the present invention. As shown in fig. 3, UEs (or ATs) 116 and 122 in fig. 1 or base station (AN) 100 in fig. 1 may be implemented with a communication device 300 in a wireless communication system, and the wireless communication system is preferably AN NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (central processing unit, CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 may receive signals input by a user through an input device 302 (e.g., a keyboard or keypad) and may output images and sounds through an output device 304 (e.g., a display or speaker). The transceiver 314 is used to receive and transmit wireless signals to pass the received signals to the control circuit 306 and to wirelessly output signals generated by the control circuit 306. The AN 100 of fig. 1 may also be implemented with a communication device 300 in a wireless communication system.
Fig. 4 is a simplified block diagram of the program code 312 shown in fig. 3 according to one embodiment of the invention. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 generally performs radio resource control. Layer 2 portion 404 generally performs link control. Layer 1 portion 406 typically performs physical connections.
3GPP TS 38.300 and TS 38.331 provide the following description regarding RRC_INACTIVE state in the New RAT/radio (NR):
[ from 3GPP TS 38.300]
9.2 Within NR
9.2.2 Mobility in rrc_inactive
9.2.2.1 Summary of the invention
Rrc_inactive is a state in which the UE remains in CM-CONNECTED and can move within an area configured by NG-RAN (RNA) without informing the NG-RAN. In rrc_inactive, the last serving gNB node maintains UE context and NG connection associated with UE with serving AMF and UPF.
[…]
Upon migrating to rrc_inactive, the NG-RAN node may use the periodic RNA update timer value to configure the UE. Upon expiration of the periodic RNA update timer and no notification from the UE, the behavior of the gNB is as specified in TS 23.501[3 ].
If the UE accesses a gcb other than the last serving gcb, the receiving gcb triggers the XnAP to retrieve the UE context procedure to acquire the UE context from the last serving gcb, and may also trigger an Xn-U address indication procedure containing tunnel information, in order to potentially recover data from the last serving gcb. After the UE context search is successful, the receiving gNB performs the slice aware admission control when receiving the slice information, and becomes a serving gNB, and further triggers an NGAP path switching request and an applicable RRC procedure. After the path switching procedure, the serving gcb triggers a UE context release at the last serving gcb by an XnAPUE context release procedure.
In case the UE cannot reach the last serving gNB, the gNB will fail any AMF initiated UE associated class 1 procedure, which allows signaling unsuccessful operation in the corresponding response message. It may trigger a NAS undelivered indication procedure to report undelivered of any NAS PDUs received from the AMF.
If the gNB accessed by the UE is not the last serving gNB and the receiving gNB does not find a valid UE context, the receiving gNB may perform the establishment of the new RRC connection instead of restoring the previous RRC connection. UE context retrieval will also fail and therefore a new RRC connection needs to be established if the serving AMF changes.
A UE in rrc_inactive state needs to initiate an RNA update procedure when the configured RNA is removed. When an RNA update request is received from the UE, the receiving gNB triggers the XnAP to retrieve the UE context procedure to obtain the UE context from the last serving gNB, and may decide to send the UE back to rrc_inactive state, move the UE to rrc_connected state, or send the UE to rrc_idle. In the case of periodic RNA updates, if the last serving gNB decides not to relocate the UE context, it will fail the UE context retrieval procedure and send the UE back to rrc_inactive or directly to rrc_idle via an encapsulated RRCRelease message.
9.2.2.2 Cell reselection
The UE in rrc_inactive performs cell reselection. The principle of this procedure is in terms of the rrc_idle state (see section 9.2.1.2).
9.2.2.4 State migration
9.2.2.4.1UE triggered migration from rrc_inactive to rrc_connected
The following diagram describes the UE-triggered migration from rrc_inactive to rrc_connected in case the UE context retrieval is successful:
fig. 9.2.2.4.1-1 entitled "UE-triggered migration from rrc_inactive to rrc_connected (UE context search success)" in [3GPP TS 38.300 V16.2.0 is reproduced as fig. 5]
The ue recovers from rrc_inactive to provide the I-RNTI allocated by the last serving gNB.
2. If the gNB identity contained in the I-RNTI can be resolved, the gNB requests the last serving gNB to provide the UE context data.
3. The last serving gNB provides the UE context data.
The recovery of the RRC connection is completed by the nb and UE.
Note that: user data may also be sent in step 5 if granted permission.
6. The gNB provides a forwarding address if the loss of DL user data buffered in the last serving gNB is to be prevented.
The path switch is performed by the gNB 7/8.
The gNB triggers release of UE resources at the last serving gNB.
A following step 1 above, SRB0 is used (no security) when the gNB decides to reject the resume request immediately using a single RRC message and keep the UE in rrc_inactive without any reconfiguration (e.g., as described in the two examples below) or when the gNB decides to establish a new RRC connection. Conversely, SRB1 (with integrity protection and ciphering as previously configured for the SRB) will be used when the gNB decides to reconfigure the UE (e.g., using a new DRX cycle or RNA) or the gNB decides to push the UE to rrc_idle.
Note that: SRB1 can only be used after the UE context is retrieved, i.e. after step 3.
The following diagram describes the UE-triggered migration from rrc_inactive to rrc_connected in case of a UE context retrieval failure:
fig. 9.2.2.4.1-2 entitled "UE-triggered migration from rrc_inactive to rrc_connected (UE context retrieval failure)" in [3GPP TS 38.300 V16.2.0 is reproduced as fig. 6]
The ue recovers from rrc_inactive to provide the I-RNTI allocated by the last serving gNB.
2. If the gNB identity contained in the I-RNTI can be resolved, the gNB requests the last serving gNB to provide the UE context data.
3. The last serving gNB cannot retrieve or verify the UE context data.
4. The last serving gNB indicates a failure to the gNB.
The gNB performs backoff to establish a new RRC connection by transmitting RRCSetup.
6. A new connection is established as described in section 9.2.1.3.1.
The following diagram describes a rejection from the network when the UE attempts to resume connection from rrc_inactive:
[3GPP TS 38.300 V16.2.0 entitled "rejection from network": the diagram 9.2.2.4.1-3 of the UE attempting to resume connection "is reproduced as FIG. 7]
Ue attempts to resume connection from rrc_inactive.
The gNB is not able to handle the procedure, e.g. due to congestion.
The gNB sends RRCRject (with latency) to keep the UE in RRC_INACTIVE.
9.2.2.4.2 network triggered migration from rrc_inactive to rrc_connected
The following diagram describes network-triggered migration from rrc_inactive to rrc_connected:
[3GPP TS 38.300 V16.2.0 entitled "network triggered migration from RRC_INACTIVE to RRC_CONNECTED" FIG. 9.2.2.4.2-1 is reproduced as FIG. 8]
Ran paging trigger event occurs (incoming DL user plane, DL signaling from 5GC, etc.).
2. Triggering RAN paging; only in the cell controlled by the last serving gNB or also in the cell controlled by other gnbs configured to UEs in the RAN-based notification area (RNA) by means of Xn RAN paging.
The ue pages with the I-RNTI.
4. If the UE has arrived successfully, an attempt is made to recover from RRC_INACTIVE as described in section 9.2.2.4.1.
[…]
[ from 3GPP TS 38.331]
4.2 Architecture for a computer system
4.2.1 Including inter-RAT UE state and state transitions
When the RRC connection has been established, the UE is in an rrc_connected state or an rrc_inactive state. If not, i.e. no RRC connection is established, the UE is in rrc_idle state. The RRC state may be further characterized as follows:
-RRC_IDLE：
-UE-specific DRX may be configured by upper layers;
-the UE controlling mobility based on the network configuration;
-UE：
listening for short messages transmitted using P-RNTI through DCI (see section 6.5);
-listening to a paging channel for CN paging using 5G-S-TMSI;
-performing neighbor cell measurements and cell selection (reselection);
acquire system information and may send SI requests (if configured).
-performing a recording of available measurements, the location and time of the UE configured via the recorded measurements.
-RRC_INACTIVE：
-UE-specific DRX may be configured by an upper layer or RRC layer;
-the UE controlling mobility based on the network configuration;
-the UE storing a UE inactivity AS context;
-the RAN-based notification area is configured by the RRC layer;
UE：
listening for short messages transmitted using P-RNTI through DCI (see section 6.5);
-listening to a paging channel for CN paging using 5G-S-TMSI and RAN paging using fullI-RNTI;
-performing neighbor cell measurements and cell selection (reselection);
-performing a RAN-based notification area update periodically and upon moving out of the configured RAN-based notification area;
acquire system information and may send SI requests (if configured).
-performing a recording of available measurements, the location and time of the UE configured via the recorded measurements.
-RRC_CONNECTED：
-the UE storing the AS context;
-delivering unicast data to/from the UE;
-at the lower layer, the UE may be configured to use UE-specific DRX;
-for CA-enabled UEs, using one or more scells aggregated with SpCell to increase bandwidth;
-for DC-enabled UEs, using one SCG aggregated with MCG to increase bandwidth;
network controlled mobility within the NR and to/from E-UTRA;
-UE：
-if configured, listening for short messages transmitted using P-RNTI through DCI (see section 6.5);
-listening to a control channel associated with the shared data channel to determine whether data is scheduled therefor;
-providing channel quality and feedback information;
-performing neighbor cell measurements and measurement reports;
-acquiring system information;
-performing immediate MDT measurements and available location reporting.
Fig. 4.2.1-1 shows an overview of the UE RRC state machine and state transitions in NR. The UE has only one RRC state at a time in the NR.
[3GPP TS 38.331 V16.1.0, FIG. 4.2.1-1 entitled "UE State machine and State transition in NR" is reproduced as FIG. 9]
5.3.8 RRC connection release
5.3.8.1 Summary of the invention
[3GPP TS 38.331 V16.1.0, FIG. 5.3.8.1-1 entitled "RRC connection Release successful" is reproduced as FIG. 10]
The purpose of this procedure is:
-releasing the RRC connection, which includes the release of all radio resources and the established radio bearers; or (b)
-suspending the RRC connection only when SRB2 and at least one DRB or SRB2 set up for the IAB, including suspension of the established radio bearer.
5.3.8.2 Initiating
The network initiates an RRC connection release procedure to migrate the UE from the rrc_connected state to the rrc_idle state; or migrating the UE from the rrc_connected state to the rrc_inactive state only if SRB2 and at least one DRB or SRB2 for the IAB are set under rrc_connected; or migrating the UE from the rrc_inactive state back to the rrc_inactive state when the UE attempts to resume; or to migrate the UE from the rrc_inactive state to the rrc_idle state when the UE attempts to resume. This procedure may also be used to release and redirect the UE to another frequency.
5.3.8.3 Reception of RRCRelease by UE
The UE will:
[…]
1> if RRCRelease contains suphendconfig:
2> applying the received suptendconfig;
2> remove all entries (if any) within varconditional config;
2> for each measId, if the associated reportConfig has a reportType set to condtricggerconfig:
3> for associated reportConfigId:
4> remove entries with matching reportConfigId from reportConfigList within VarMeasConfig;
3> if the associated measObjectId is associated with only reportConfig with reportConfig set to reportcype set to condtricggerconfig:
4> remove the entry with matching measObjectId from measObjectList within VarMeasConfig;
3> remove entries with matching measId from measIdList within VarMeasConfig
2> resetting the MAC and releasing the preset MAC cell group configuration (if any);
2> reestablishing RLC entity for SRB 1;
2> if an RRCRelease message with suphendconfig is received in response to rrcresemerequest or rrcresemerequest 1:
3> stop timer T319 (if running);
3> in the stored UE inactivity AS context:
4> replacing the KgNB and KRRcint keys with the current KgNB and KRRcint keys;
4> replacing the C-RNTI with a temporary C-RNTI in a cell in which the UE has received the RRCRelease message;
4> replacing the cellIdentity with the cellIdentity of the cell in which the UE has received the RRCRelease message;
4> replacing the physical cell identity with the physical cell identity of the cell from which the UE has received the RRCRelease message;
2> otherwise:
3> storing the current KgNB and KRRCint keys, ROHC state, stored QoS flow to DRB mapping rules, C-RNTI for the source PCell, cellIdentity and physical cell identity of the source PCell, and all other configured parameters in the UE inactive AS context except in the reconfigurationwisync and servingCellConfigCommonSIB;
note 2: when the UE enters rrc_inactive, the NR side link communication related configuration is not stored AS a UE INACTIVE AS context.
2> suspend all SRBs and DRBs except SRB 0;
2> indicating PDCP suspension to the lower layers of all DRBs;
2> if t380 is included:
3> starts a timer T380, wherein the timer value is set to T380:
2> if the RRCRelease message is containing waitTime:
3> starts timer T302, with the value set to waitTime;
the 3> informs the upper layer that access barring is applicable for all access categories except for categories "0" and "2".
2> if T390 is in operation:
3> stop timer T390 for all access categories;
3> perform the action specified in 5.3.14.4;
2> indicate suspension of RRC connection to upper layer;
2> enter rrc_inactive and perform cell selection as specified in TS 38.304[20 ];
1> otherwise
2> performs an action after going to rrc_idle as specified in 5.3.11, release is due to "other".
5.3.13 RRC connection recovery
5.3.13.1 Summary of the invention
[3GPP TS 38.331 V16.1.0, FIG. 5.3.13.1-1 entitled "RRC connection recovery successful" is reproduced as FIG. 11]
Fig. 5.3.13.1-2 entitled "success of rollback of RRC connection recovery to RRC connection establishment" in 3GPP TS 38.331 V16.1.0 is reproduced as fig. 12]
Fig. 5.3.13.1-3 entitled "RRC connection recovery success following network release" in 3GPP TS 38.331 V16.1.0 is reproduced as fig. 13]
Fig. 5.3.13.1-4 entitled "RRC connection resumption success following network suspension" in 3GPP TS 38.331 V16.1.0 is reproduced as fig. 14]
[3GPP TS 38.331 V16.1.0, FIG. 5.3.13.1-5 entitled "RRC connection recovery, network rejection" is reproduced as FIG. 15]
The purpose of this procedure is to resume a suspended RRC connection, including resuming SRBs and DRBs or performing RNA updates.
5.3.13.2 Initiating
The UE initiates this procedure when an upper layer or AS (upon responding to a RAN page, triggering an RNA update while the UE is in rrc_inactive, or requesting resumption of suspended RRC connection for side link communication AS specified in section 5.3.13.1a).
Before initiating the procedure, the UE should be ensured to have valid and up-to-date important system information specified in chapter 5.2.2.2.
After initiating the procedure, the UE should:
1> if the recovery of RRC connection is triggered by responding to NG-RAN paging:
2> selecting '0' as the access category;
2> performing the unified access control procedure specified in 5.3.14 using the selected access category and one or more access identities provided by the upper layer;
3> if the access attempt is barred, the procedure ends;
1> otherwise, if the recovery of RRC connection is triggered by upper layers:
2> if the upper layer provides an access category and one or more access identities:
3> performing the unified access control procedure specified in 5.3.14 using the access class and access identity provided by the upper layer;
4> if the access attempt is barred, the procedure ends;
2> setting resumecase according to the information received from the upper layer;
[…]
1> applying a preset L1 parameter value, as specified in the corresponding physical layer specification, except for the parameters provided in SIB 1;
1> as specified in 9.2.1, applying a preset SRB1 configuration;
1> applying a preset MAC cell group configuration as specified in 9.2.2;
[…]
1> as specified in 9.1.1.2, apply CCCH configuration;
1> applying the timeAlignmentTimerCommon contained in SIB 1;
1> start timer T319;
1> setting the variable pendingRNA-Update to false;
1> initiates transmission of rrcresemerequest message or rrcresemerequest 1 according to 5.3.13.3.
5.3.13.3 Actions related to the delivery of RRCResumeRequest or RRCResumeRequest1 messages
The UE will set the contents of the rrcresemerequest or rrcresemerequest 1 message as follows:
1> if field usefill resumeid is transmitted in SIB 1:
2> selecting RRCResumeRequest1 as the message to be used;
2> setting the resume identity to the stored fulll i-RNTI value;
1> otherwise:
2> selecting RRCResumeRequest as the message to be used;
2> setting the resume identity to the stored shortI-RNTI value;
1> recovering RRC configuration, roHC state, stored QoS flow to DRB mapping and KgNB and KRRCint keys from stored UE inactivity AS context, except AS follows;
-masterCellGroup；
mrdc-second cell group (if stored); and
-pdcp-Config；
1> reset MAC-I is set to the 16 least significant bits of the calculated MAC-I:
2> asn.1 encoded as varrenummac-Input according to section 8 (i.e., multiples of 8 bits);
2> utilizing KRRCint key and previously configured integrity protection algorithm in UE inactive AS context; and
2> wherein all input bits of COUNT, BEARER and DIRECTION are set to binary ones;
1> deriving a KgNB key based on the current KgNB key or NH using the stored nextHopchainingcount value, as specified in TS 33.501[11 ];
1> deriving a KRRCenc key, a KRRCint key, a kuplint key and a kuplinc key;
1> immediately configuring the lower layer using the configured algorithm derived in this section with KRRCint key and kuplint key to apply integrity protection to all radio bearers except SRB0, i.e. the integrity protection will be applied to all subsequent messages received and sent by the UE;
note 1: only DRBs that have previously been configured with UP integrity protection will resume integrity protection.
1> the configuration lower layer applies ciphering to all radio bearers other than SRB0 and applies the configured ciphering algorithm, KRRCenc key and kutenc key derived in this section, i.e. the ciphering configuration will apply to all subsequent messages received and sent by the UE;
1> reestablishing the PDCP entity for SRB1;
1> restore SRB1;
1> submit selected message rrcresemerequest or rrcresemerequest 1 for delivery to the lower layer.
Note 2: only DRBs that have previously been configured UP for encryption will resume encryption.
If the lower layer indicates that the integrity check fails while T319 is in operation, then the action specified in 5.3.13.5 is performed.
The UE will continue with the cell reselection related measurements and the cell reselection evaluation. If the cell reselection condition is met, the UE will perform the cell reselection specified in 5.3.13.6.
5.3.13.4 Reception of RRCResume by UE
The UE will:
1> stop timer T319;
1> stop timer T380 (if running);
1> if T331 is running:
2> stop timer T331;
2> perform the action specified in 5.7.8.3;
1> if rrcreseume contains fullConfig:
2> execute a full configuration procedure as specified in 5.3.5.11;
1> otherwise:
2> if rrcreseume does not contain resetormcg-SCells:
3> if stored, releasing MCG SCell from UE inactive AS context;
2> if rrcreseume does not contain restecg:
3> if stored, releasing the MR-DC related configuration from the UE inactive AS context (i.e., AS specified in 5.3.5.10);
2> recovering masterCellGroup, mrdc-second cell group (if stored) and pdcp-Config from the UE inactive AS context;
2> configuring the lower layer to consider the recovered MCG and SCG SCell (if present) as being in a deactivated state;
1> discard UE inactive AS context;
1> release suptendConfig, except for ran-Notification AnareInfo;
1> if rrcreseume contains masterCellGroup:
2> according to 5.3.5.5, cell group configuration is performed for the received masterCellGroup;
1> if RRCResume contains mrdc-second cell group:
2> if the received mrdc-second cell group is set to nr-SCG:
3> according to 5.3.5.3, RRC reconfiguration is performed for the rrcrecon configuration message contained in nr-SCG;
2> if the received mrdc-second cell group is set to eutra-SCG:
3> as specified in section 5.3.5.3 of TS 36.331[10], performing RRC connection reconfiguration for the RRCConnection reconfiguration message contained in the eutra-SCG;
1> if RRCResume contains radioBearerConfig:
2> performing radio bearer configuration according to 5.3.5.6;
1> if the rrcreseume message contains sk-Counter:
2> executing a security key update procedure as specified in 5.3.5.7;
1> if the rrcreseume message contains radiobearconfig 2:
2> performing radio bearer configuration according to 5.3.5.6;
1> if the rrcreseume message contains needledforgapcon fignr:
2> if needledforgapcon fignr is set to setup:
3> treat itself as being configured to provide measurement gap requirement information for the NR target zone;
2> otherwise:
3> treat itself as not configured to provide measurement gap requirement information for the NR target zone;
1> recover SRB2, SRB2 (if configured) and all DRBs;
1> if stored, discard cell reselection priority information provided by cellreselection priority or inherited from another RAT;
1> stop timer T320 (if running);
1> if rrcreseume message contains measConfig:
2> performing a measurement configuration procedure as specified in 5.5.2;
1> resume measurement (if suspended);
1> if T390 is in operation:
2> stop timer T390 for all access categories;
2> perform the action as specified in 5.3.14.4;
1> if T302 is in operation:
2> stop timer T302;
2> perform the action as specified in 5.3.14.4;
1> enter rrc_connected;
1> indicating to the upper layer that the suspended RRC connection has resumed;
1> stopping the cell reselection procedure;
1> regarding the current cell as a PCell;
1> the content of the RRCResumeComplete message is set as follows:
[…]
1> submitting a RRCResumeComplete message to a lower layer for transmission;
1> the procedure ends.
5.3.13.9 Reception of RRCRelease by UE
The UE will:
1> performs the action specified in 5.3.8.
The 3gpp TS 38.331 provides the following description regarding Radio Resource Control (RRC) parameters and configuration in NR:
-MIB
the MIB contains system information transmitted on the BCH.
Signaling radio bearers: N/A
RLC-SAP：TM
Logical channel: BCCH (broadcast control channel)
The direction is: network to UE
MIB
/>
-PDCCH-ConfigSIB1
The IE PDCCH-ConfigSIB1 is used to configure CORESET#0 and search space#0.
PDCCH-ConfigSIB1 information element
-SIB1
SIB1 contains relevant information to evaluate if the UE is allowed to access the cell and defines the scheduling of other system information. It also contains radio resource configuration information common to all UEs and barring information applied to unified access control.
Signaling radio bearers: N/A
RLC-SAP：TM
Logical channel: BCCH (broadcast control channel)
The direction is: network to UE
SIB1 message
-ServingCellConfigCommonSIB
IE ServingCellConfigCommonSIB is used to configure the cell specific parameters of the serving cell of the UE in SIB 1.
servingCellConfigCommonSIB information element
-DownlinkConfigCommonSIB
IE DownlinkConfigCommonSIB provide common downlink parameters of the cells.
DownlinkConfigCommonSIB information element
-BWP-DownlinkCommon
The IE BWP-downlink common is used to configure common parameters of downlink BWP. They are "cell specific" and the network ensures the required alignment of the corresponding parameters with other UEs. Common parameters of the initial bandwidth part of the PCell are also provided via system information. For all other serving cells, the network provides common parameters via dedicated signaling.
BWP-downlink common information element
-PDCCH-ConfigCommon
The IE PDCCH-ConfigCommon is used to configure cell specific PDCCH parameters provided in the SIB as well as the dedicated signaling.
PDCCH-ConfigCommon information element
-PDSCH-ConfigCommon
The IE PDSCH-ConfigCommon is used to configure cell-specific PDSCH parameters.
-UplinkConfigCommonSIB
IE UplinkConfigCommonSIB provide common uplink parameters of the cells.
UpplinkConfigCommonSIB information element
-BWP-UplinkCommon
The IE BWP-uplink common is used to configure common parameters of the uplink BWP. They are "cell specific" and the network ensures the required alignment of the corresponding parameters with other UEs. Common parameters of the initial bandwidth part of the PCell are also provided via system information. For all other serving cells, the network provides common parameters via dedicated signaling.
BWP-uplink common information element
-PUSCH-ConfigCommon
The IE PUSCH-ConfigCommon is used to configure cell specific PUSCH parameters.
-BWP-DownlinkDedicated
The IE BWP-downlink dedicated is used to configure dedicated (UE-specific) parameters of the downlink BWP.
BWP-downlink linked information element
-PDCCH-Config
The IE PDCCH-Config is used to configure UE-specific PDCCH parameters such as control resource set (CORESET), search space, and additional parameters for acquiring PDCCH. If this IE is for a scheduled cell in the case of cross-carrier scheduling, then no fields other than searchspacestoadmodlist and searchspacestoreaselist exist. If the IE is for dormant BWP, then no fields other than the control ResourceSereToAddModList and the control ResourceSereToReleaseList exist.
PDCCH-Config information element
-PDSCH-Config
The PDSCH-Config IE is used to configure UE-specific PDSCH parameters.
-BWP-UplinkDedicated
The IE BWP-uplink data is used to configure dedicated (UE-specific) parameters of the uplink BWP.
BWP-upslinkdifferential information element
-PUSCH-Config
The IE PUSCH-Config is used to configure UE-specific PUSCH parameters applicable to a specific BWP.
-ControlResourceSet
IE ControlResourceSet is used to configure the set of time/frequency control resources (CORESET) in which to search for downlink control information (see TS 38.213[13] section 10.1).
ControlResourceSet information element
-ServingCellConfig
IE ServingCellConfig is used to configure (add or modify) a UE with a serving cell, which may be a SCell of a SpCell or MCG or SCG. The parameters herein are mostly UE-specific, but also partly cell-specific (e.g. in a further configured bandwidth part). Reconfiguration between PUCCH and PUCCH-less scells uses SCell release and addition support only.
servingCellConfig information element
/>
-CSI-MeasConfig
The IE CSI-MeasConfig is used to configure CSI-RS (reference signals) belonging to a serving cell in which CSI-MeasConfig is contained, channel state information reports to be transmitted on PUCCH on the serving cell in which CSI-MeasConfig is contained, and channel state information reports on PUSCH triggered by DCI received by the serving cell in which CSI-MeasConfig is contained. See also section 5.2 of TS 38.214[19 ].
-CSI-ReportConfig
The IE CSI-ReportConfig is used to configure periodic or semi-static reports sent on PUCCH on the cell in which CSI-ReportConfig is contained, or semi-static or non-periodic reports sent on PUSCH triggered by DCI received on the cell in which CSI-ReportConfig is contained (in which case the cell on which the report is sent is determined by the received DCI). See section 5.2.1 of TS 38.214[19 ].
-PUCCH-Config
The IE PUCCH-Config is used to configure UE-specific PUCCH parameters (per BWP).
-SRS-Config
The IE SRS-Config is used to configure sounding reference signal transmission or to configure sounding reference signal measurements of CLI. The configuration defines an SRS-Resources list and an SRS-Resources list. Each resource set defines a set of SRS-Resources. The network triggers the transmission of the set of SRS-Resources (L1 DCI) using the configured aperiodic SRS-resource trigger.
The 3GPP RP-193252 and 3GPP RAN2#111 conference recordings provide the following description regarding NR small data transfer in RRC_INACTIVE state:
[ from 3GPP RP-193252]
3. For reasons of legitimacy
The NR supports an rrc_inactive state and UEs with infrequent (periodic and/or aperiodic) data transmissions are typically held in the rrc_inactive state by the network. The rrc_inactive state does not support data transfer until Rel-16. Thus, the UE must restore the connection (i.e., move to rrc_connected state) for any DL (MT) and UL (MO) data. Regardless of the size and frequency of the data packets, each data transfer may occur with a connection setup and then release to the INACTIVE state. This can result in unnecessary power consumption and signaling overhead.
[…]
Signaling overhead for small packets by INACTIVE state UEs is a common problem, which will become a critical issue not only for network performance and efficiency but also for UE battery performance as more UEs in NR. In general, any device with intermittent small data packets in the INACTIVE state will benefit from enabling small data transfers in the INACTIVE state.
The key enablers in NR for small data transfers, namely INACTIVE state, 2-step, 4-step RACH and configured grant type 1 have been designated as part of Rel-15 and Rel-16. Thus, the work herein builds on these building blocks to make the NR conduct small data transfers in the INACTIVE state.
4. Target object
4.1 Targets of SI or core part WI or test part WI
This work item enables small data transfer in rrc_inactive state as follows:
-for rrc_inactive state:
UL small data transfer based on RACH scheme (i.e., 2-step and 4-step RACH):
■ General procedure for enabling UP data transfer of small data packets from INACTIVE state (e.g. using MSGA or MSG 3) [ RAN2]
■ Enabling a flexible payload size for MSGA and MSG3 that is larger than the Rel-16 CCCH message size currently possible for INACTIVE state to support UP data transfer in UL (actual payload size can reach network configuration) [ RAN2]
■ Context acquisition and data forwarding (with or without anchor relocation) in INACTIVE state for RACH based solutions [ RAN2, RAN3]
Note 1: the security aspect of the above solution should be checked using SA3
Transmission of UL data on preconfigured PUSCH resources (i.e., reuse of configured grant type 1) -when TA is valid
■ Generic procedure through small data transfer configured grant type 1 from INACTIVE state RAN2
■ Configuration of configured grant type 1 resources for small data transfer in UL in INACTIVE state RAN2
No new RRC state should be introduced in this WID. The small data transfer in UL, the subsequent small data transfer in UL and DL, and the state transition decisions should all be under network control.
[…]
[ conference recording from 3GPP RAN2#111 ]
8.6.2 UL small data transmission for RACH based schemes
Agreement(s)
1. Supporting small data transfers with RRC messages as a baseline for RA-based and CG-based schemes
[…]
4. From the perspective of RAN2, the stored "configuration" in the UE context is for RLC bearer configuration for any SDT mechanism (RACH and CG).
5 2 step RACH or 4 step RACH should be applied to RACH-based uplink small data transfer under rrc_inactive
6. The uplink small data may be transmitted in MSGA of 2-step RACH or msg3 of 4-step RACH.
7. Small data transfer configured by the network on a per DRB basis
[…]
9. Supporting UL/DL delivery after UL SDT without transitioning to rrc_connected
10. When the UE is in rrc_inactive, it should be possible to send multiple UL and DL packets as part of the same SDT mechanism and without transitioning to rrc_connected on dedicated grants. Details and any indication of whether a network is required to be studied further.
The 3gpp TS 38.213 provides the following description regarding Channel State Information (CSI) reporting:
9. UE procedure for reporting control information
9.2 UCI reporting in physical uplink control channel
The UCI type reported in PUCCH contains HARQ-ACK information, SR, LRR, and CSI. The UCI bits include HARQ-ACK information bits (if present), SR information bits (if present), LRR information bits (if present), and CSI bits (if present). The HARQ-ACK information bits correspond to the HARQ-ACK codebook, as described in section 9.1. For the remainder of this section, any reference to SR applies to SR and/or LRR.
9.2.1 PUCCH resource set
If the UE does not have a dedicated PUCCH resource configuration provided by PUCCH-ResourceNet in PUCCH-Config, then PUCCH resourcesThe source set is provided by pucch-ResourceCommon through the row index of Table 9.2.1-1 for HARQ-ACK information transmission on PUCCH of initial UL BWP of each PRB.
The PUCCH resource set contains sixteen resources, each corresponding to PUCCH format, first symbol, duration, PRB offset for PUCCH transmissionAnd cyclically shifting the index set.
If useiterlaceucch-PUSCH is not provided in BWP-uplink common, the UE transmits PUCCH using frequency hopping; otherwise, the UE does not transmit PUCCH using frequency hopping.
In table 9.2.1-1, an orthogonal cover code with index 0 is used for PUCCH resources with PUCCH format 1.
The UE transmits PUCCH using the same spatial domain transmission filter as the PUSCH transmission scheduled by the RAR UL grant, as described in section 8.3.
In general, the rrc_inactive state is introduced for UEs with infrequent data transmissions. When there is no data transfer, the UE may be in rrc_inactive state (i.e., RRC connection suspension) in order to reduce power consumption. When the UE is in rrc_inactive state, the current serving gNB will store (or maintain) the UE context (e.g., configuration and identity of the UE) of the UE. Upon data arrival, the UE may resume the RRC connection from the rrc_inactive state faster than a new RRC connection is established from the rrc_idle state. After restoring the RRC connection (e.g., after successfully completing the RA procedure), the UE can transmit data (e.g., data from the application layer) in the rrc_connected state as usual.
In addition, the UE can resume a Radio Resource Control (RRC) connection on a different gNB (i.e., a new gNB) than the original one in which the RRC connection was suspended (i.e., the old one). In this case, the new gNB attempts to retrieve the UE context from the old gNB. If the new gNB fails to retrieve the UE context, a fallback to RRC connection setup procedure (i.e., a new RRC connection is established) may be performed. When the RRC connection of the UE is suspended, the UE will store (part of) its current RRC configuration in the "UE inactive AS context". After the UE initiates the RRC recovery procedure on the cell (which will be considered AS SpCell after the RRC connection is successfully recovered in this cell) and before the UE transmits the rrcresemerequest message, the UE will recover the part of the stored RRC configuration from the UE inactive AS context AS specified in section 5.3.13.3 of 3gpp TS 38.331. Further details of the rrc_inactive state have been provided above and can be found in 3gpp TS 38.300 and TS 38.331.
While the rrc_inactive state has the benefits as described above, the UE is currently unable to transmit (user plane) data in the rrc_inactive state. That is, the UE needs to enter the rrc_connected state before transmitting data. After transmitting the data, the UE is again in the rrc_inactive state. The above steps occur for each data transfer regardless of the amount of data and the frequency of arrival of the data, which can result in power consumption and signaling overhead.
To alleviate this problem, small data transfers in the rrc_inactive state will be introduced, as discussed in 3GPP RP-193252. In general, the main goal of small data transfer is to enable a UE to transfer data in the rrc_inactive state without (or before) entering the rrc_connected state. Potential solutions may be based on 2-step RACH, 4-step RACH, and/or pre-configured PUSCH resources (e.g., similar to type 1 configured grants in NR). The small data transfer in the rrc_inactive state may be referred to as "SDT and/or" SDT procedure "and/or" SDT "in the rrc_inactive state.
For example, when the UE performs a SDT procedure based on a 2-step RACH in a cell, the UE contains Uplink (UL) data and an rrcresemerequest message in MsgA. For example, when the UE performs a 4-step Random Access Channel (RACH) -based SDT procedure in a cell, the UE contains UL data and an rrcresemerequest message in Msg 3. For example, when the UE performs an SDT procedure based on a preconfigured Physical Uplink Shared Channel (PUSCH) resource in a cell, the UE includes UL data and an rrcresmerequest message in a Protocol Data Unit (PDU) in order to transmit using the preconfigured PUSCH resource. The SDT procedure makes it possible to introduce a new RRC message (instead of the RRCResumeRequest message as mentioned above). It is possible that UL data is not transmitted using RRC messages.
Fig. 16 illustrates a first example of Small Data Transfer (SDT) in an rrc_inactive state according to one embodiment. In this example, the UE remains in the rrc_inactive state after performing the SDT (e.g., in the event that no more data is expected to be transferred). Fig. 17 shows a second example of Small Data Transfer (SDT) in the rrc_inactive state. In this example, the SDT program rolls back to rrcreseume (e.g., where more data is expected to be transferred). Fig. 18 shows a third example of Small Data Transfer (SDT) in the rrc_inactive state. In this example, the SDT procedure rolls back to RRCSetup (e.g., where the gNB fails to retrieve the UE context for the UE to perform SDT).
Typically, the data transfer of the SDT procedure includes a first UL transfer (e.g., msg3 of 4-step RACH or MsgA of 2-step RACH) followed by a first Downlink (DL) transfer (e.g., msg4 of 4-step RACH or Msg b of 2-step RACH). If there is more data within the first UL/DL transmission that may not be transmitted/received, the network may migrate the UE into the rrc_connected state to transmit/receive the more data. While the UE is still in rrc_inactive state, a subsequent transmission may be performed.
For example, the second UL transmission may follow the first DL transmission, and the UE may remain in rrc_inactive after performing the second UL transmission (and receiving an "ACK" response from the network). For example, the second DL transmission may be after the second UL transmission, and the UE may remain in rrc_inactive after performing the second DL transmission (and transmitting an "ACK" to the network). The "completion of the SDT procedure" may refer to the last of the subsequent transmissions (e.g., the second UL transmission or the second DL transmission described above). In the case where the second DL transmission is the last DL transmission in the SDT procedure, the RRCRelease message may be included in the first DL transmission instead of the second DL transmission.
Alternatively, in the case where the second DL transmission is the last DL transmission in the SDT procedure, the RRCRelease message may be included in the second DL transmission instead of the first DL transmission. Subsequent delivery may be considered part of the SDT procedure. The network may indicate in the first DL transfer whether there is a subsequent transfer in the SDT procedure. The network may indicate in the first DL transmission whether the UE is allowed to perform subsequent transmissions in the SDT procedure. Subsequent transmissions in the SDT procedure may include at least one UL transmission. Subsequent transmissions in the SDT procedure may include at least one DL transmission. In the case where there is a subsequent transmission, the second UL transmission in the SDT procedure may also be referred to as a first subsequent UL transmission (and so on). In the case where there is a subsequent transfer, the second DL transfer in the SDT procedure may also be referred to as a first subsequent DL transfer (and so on).
The SDT program mentioned in the following paragraphs may include an RA program for SDT and subsequent delivery (after the RA program). Subsequent transmissions may be scheduled by the network using dynamic uplink grants or downlink assignments (via PDCCH). Subsequent transmissions may not be scheduled by the network with dynamic uplink grants (e.g., via subsequent transmissions of configured grants).
Fig. 19 illustrates a first example of the presence of one subsequent UL transmission in the SDT procedure, according to one embodiment. The subsequent UL transmissions are used to transmit remaining UL data (e.g., the remaining portion of UL data in fig. 19) that may not be transmitted within the first UL transmission (e.g., the portion of UL data in fig. 19). Fig. 20 illustrates a second example of the presence of one subsequent UL transmission in the SDT procedure, according to one embodiment. The subsequent UL transmission is used to transmit UL data (e.g., second UL data in fig. 20) that arrives after the UE receives DL data from the network. Fig. 21 illustrates a first example of the presence of one subsequent DL transfer in an SDT procedure, according to an embodiment. The subsequent DL transmission is used to transmit remaining DL data (e.g., the remaining portion of DL data in fig. 21) that may not be transmitted within the first DL transmission (e.g., the portion of DL data in fig. 21). Fig. 22 illustrates a second example of the presence of one subsequent DL transfer in the SDT procedure, according to one embodiment. The subsequent DL transmission is used to transmit DL data (e.g., second DL data in fig. 22) that arrives after the network receives the second UL data from the UE.
During an RRC recovery procedure (e.g., random Access (RA) procedure) on a cell, the UE listens to a Physical Downlink Control Channel (PDCCH) based on PDCCH-related configuration provided in system information (e.g., MIB, SIB 1) of the cell. In response to successful receipt of the rrcrenule message, the UE may recover the PDCCH-related configuration from the stored UE inactive Access Stratum (AS) context, and the network may also provide the PDCCH-related configuration in the rrcrenule message. In other words, the UE uses the PDCCH-related configuration provided in the system information until the rrcrenude message is successfully received. The PDCCH-related configuration may include a control resource set (CORESET) configuration (e.g., controlResourceSetToAddModList, controlResourceSet). The PDCCH-related configuration may include a search space configuration (e.g., searchSpacesToAddModList, searchSpace). The PDCCH-related configuration may include a TCI state configuration of the PDCCH (e.g., TCI-statepdcch-ToAddList).
For RACH based SDT procedure, it is assumed that during RA procedure for SDT on a cell, the UE listens to PDCCH (for receiving e.g. Msg2, msg4 or MsgB) based on PDCCH related configuration provided in system information (e.g. MIB or SIB 1) of the cell. The PDCCH-related configuration used during RA procedure for SDT may be the same as the PDCCH-related configuration used during RA procedure not for SDT. The PDCCH-related configuration used during RA procedures for SDT may be different from the PDCCH-related configuration used during RA procedures not for SDT. For example, the CORESET configuration used during RA programs for SDT may be the same as the CORESET configuration used during RA programs not for SDT (e.g., control resource set zero), while the search space configuration used during RA programs for SDT (e.g., non-RA-SearchSpace) may be different from the search space configuration used during RA programs not for SDT (e.g., RA-SearchSpace).
For example, the CORESET configuration (e.g., non-control resource setzero) used during RA procedures for SDT may be different from the CORESET configuration (e.g., control resource setzero) used during RA procedures not for SDT, while the search space configuration used during RA procedures for SDT may be the same as the search space configuration used during RA procedures not for SDT (e.g., RA-SearchSpace). For example, the CORESET configuration and search space configuration used during RA programs for SDT may both be the same as CORESET configuration and search space configuration used during RA programs not for SDT. For example, the CORESET configuration and search space configuration used during RA programs for SDT may be different from the CORESET configuration and search space configuration used during RA programs not for SDT.
The network may indicate which PDCCH-related configuration among the PDCCH-related configurations provided in the system information during the RA procedure for SDT is to be used by the UE. For example, the network provides a search space configuration list in the system information and indicates which search space among the list is to be used during the RA procedure for SDT. The indication may be provided in system information (e.g., SIB 1). The indication may be provided in dedicated signaling (e.g., an RRCRelease message) to the UE. Alternatively, the network directly provides a second search space configuration in the system information, where this second search space configuration is for RA programs for SDT but not for RA programs not for SDT.
In case there is a subsequent transmission in the RACH based SDT procedure, it is not clear which PDCCH-related configuration is used by the UE for listening to the PDCCH during (a stage of) the subsequent transmission, e.g. listening to the PDCCH in order to receive a schedule (e.g. dynamic uplink grant or downlink assignment) of the subsequent transmission, because the RA procedure is considered to be completed in response to a successful reception of the first DL transmission (e.g. Msg4 or MsgB) of the SDT procedure. An example is shown in fig. 23.
For subsequent transmissions in the RACH-based SDT procedure, the UE may listen to the PDCCH based on at least one of the following alternatives:
1. PDCCH-related configuration for subsequent transmission is the same as used during RA procedure for SDT
For example, the network provides a first CORESET configuration in the system information. The UE uses the first CORESET configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE also uses the first CORESET configuration during subsequent transmissions in the SDT procedure. For example, the network provides the first and second CORESET configurations in system information. The UE uses the first CORESET configuration during RA procedures not used for SDT, the UE uses the second CORESET configuration during RA procedures used for SDT, and the UE also uses the second CORESET configuration during subsequent transmissions in SDT procedures.
For example, the network provides a first search space configuration in the system information. The UE uses the first search space configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE also uses the first search space configuration during subsequent transmissions in SDT procedures. For example, the network provides first and second search space configurations in the system information. The UE uses the first search space configuration during RA procedures not used for SDT, the UE uses the second search space configuration during RA procedures used for SDT, and the UE also uses the second search space configuration during subsequent transmissions in SDT procedures.
Because the PDCCH-related configuration used during the RA procedure for SDT is provided in the system information, the network may have some limitations on scheduling UEs during subsequent transmissions. For example, since the search space #0 (i.e., searchSpaceZero) provided in the MIB is a common search space, in case the UE listens to the PDCCH using this search space configuration, the network cannot schedule the UE using Downlink Control Information (DCI) format 0_1 or DCI format 1_1.
PDCCH-related configuration of the SDT procedure may be provided in SIB 1. PDCCH-related configurations of SDT procedures may be provided in a system information block (other than SIB 1), e.g., a SIB providing configuration related to SDT.
The network may provide an indication of which PDCCH-related configuration among the PDCCH-related configurations provided in the system information is to be used by the UE during the RA procedure for the SDT. The indication may be ra-searchspace. The indication may not be ra-searchspace.
2. PDCCH-related configurations for subsequent transmissions are also provided in system information (e.g., MIB or SIB 1) but may be different from PDCCH-related configurations used during RA procedure for SDT
For example, the network provides the first and second CORESET configurations in system information. The UE uses the first CORESET configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE uses the second CORESET configuration during subsequent transmissions in SDT procedures. For example, the network provides first, second, and third CORESET configurations in the system information. The UE uses the first CORESET configuration during RA procedures not used for SDT, the UE uses the second CORESET configuration during RA procedures used for SDT, and the UE also uses the third CORESET configuration during subsequent transmissions in SDT procedures.
For example, the network provides first and second search space configurations in the system information. The UE uses the first search space configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE uses the second search space configuration during subsequent transmissions in SDT procedures. For example, the network provides first, second, and third search space configurations in the system information. The UE uses the first search space configuration during RA procedures not used for SDT, the UE uses the second search space configuration during RA procedures used for SDT, and the UE also uses the third search space configuration during subsequent transmissions in SDT procedures.
Because PDCCH-related configurations for subsequent transmissions are provided in the system information, the network may have some limitations on scheduling UEs during subsequent transmissions. The search space for subsequent transmissions may be a common search space. For example, since the search space list (i.e., common searchspacelist) provided in SIB1 is a common search space, in the case that the UE listens to the PDCCH using the search space in this list, the network cannot schedule the UE using DCI format 0_1 or DCI format 1_1.
PDCCH-related configurations for SDT procedures (e.g., for subsequent transmissions) may be provided in SIB 1. PDCCH-related configurations for SDT procedures may be provided in a system information block (other than SIB 1), e.g., a SIB providing configuration related to SDT.
The network may provide a first indication indicating which PDCCH-related configuration among the PDCCH-related configurations provided in the system information is to be used by the UE during an RA procedure for the SDT. The first indication may be ra-searchspace. The first indication may not be ra-searchspace. The network may provide a second indication indicating which of the PDCCH-related configurations provided in the system information will be used by the UE for subsequent transmissions. The second indication may be different from the first indication.
3. PDCCH-related configuration for subsequent transmissions is provided in a first DL transmission (e.g., msg4 or MsgB) of an SDT procedure
The network may provide PDCCH-related configuration directly to the UE in the first DL transmission of the SDT procedure. In response to receiving the PDCCH-related configuration in the first DL transmission of the SDT procedure, the UE may listen to the PDCCH during a subsequent transmission in the SDT procedure based on the received PDCCH-related configuration.
For example, the network provides a first CORESET configuration in the system information and the network provides a second CORESET configuration in the first DL delivery of the SDT program. The UE uses a first CORESET configuration during an RA procedure for SDT and the UE uses a second CORESET configuration during a subsequent transmission in the SDT procedure. For example, the network provides a first search space configuration in the system information and the network provides a second search space configuration in the first DL delivery of the SDT program. The UE uses the first search space configuration during an RA procedure for SDT and the UE uses the second search space configuration during a subsequent transmission in the SDT procedure.
For example, the network provides a Transmission Configuration Indicator (TCI) status configuration of the PDCCH in the first DL transmission of the SDT procedure. The UE uses TCI state configuration of the PDCCH during subsequent transmissions in the SDT procedure.
The PDCCH-related configuration provided in the first SDT procedure may be used for a second SDT procedure initiated after the first SDT procedure is completed. For example, when the UE is in rrc_inactive state, the network may transmit an RRCRelease message with a supensconfig to complete the first SDT procedure initiated by the UE. The network may provide the PDCCH-related configuration in an RRCRelease message such that, later when the UE initiates the second SDT procedure, the UE may listen to the PDCCH during a subsequent transmission in the second SDT procedure using the previously provided PDCCH-related configuration.
The PDCCH-related configuration in the first DL transmission may be included in an RRC message (e.g., an RRCRelease message).
Because the PDCCH-related configuration is provided to the UE in dedicated signaling (e.g., RRCRelease messages), the network may provide a configuration for the UE that is suitable for scheduling subsequent transmissions. For example, the network may provide a search space configuration that is a UE-specific search space, and thus the network is able to schedule UEs having DCI format 0_1 or DCI format 1_1. For example, the network may provide a TCI state configuration of the PDCCH and the network may indicate the TCI state for listening to the PCCCH with a TCI state indication of the PDCCH MAC control element.
4. The PDCCH-related configuration for subsequent transmission is the PDCCH-related configuration for use by the UE in the previous rrc_connected state
Upon entering the rrc_inactive state from the rrc_connected state, the UE will store (part of) its current RRC configuration in the UE INACTIVE AS context. The UE inactive AS context also contains PDCCH-related configuration. The UE may recover the PDCCH-related configuration from the UE-inactive AS context to listen to the PDCCH during subsequent transmissions.
For example, in response to receiving an indication from the network that there is a subsequent transfer in the SDT procedure, the UE restores the CORESET configuration from the UE inactive AS context and listens to the PDCCH during the subsequent transfer using the restored CORESET configuration. For example, in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE restores the search space configuration from the UE inactive AS context and listens for the PDCCH during the subsequent transmission using the restored search space configuration.
For example, in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE restores the TCI state configuration of the PDCCH from the UE inactive AS context and listens for the PDCCH during the subsequent transmission using the restored TCI state configuration of the PDCCH.
Since the stored PDCCH-related configuration is a dedicated configuration for the UE, it may be more appropriate for the UE to schedule subsequent transmissions for this purpose. For example, the stored PDCCH-related configuration contains a search space that is UE-specific search space, and thus the network is able to schedule UEs with DCI format 0_1 or DCI format 1_1. For example, the stored PDCCH-related configuration contains a TCI state configuration of the PDCCH, and the network may indicate a TCI state for listening to the PDCCH with a TCI state indication of the PDCCH MAC control element.
The UE may resume its PDCCH-related configuration of SpCell (e.g., PCell in previous RRC connection). In case there are multiple DL BWP (under SpCell) in the UE inactive AS context, the UE may restore the PDCCH-related configuration under the initial DL BWP. Additionally or alternatively, the network may indicate (e.g., in Msg4 or MsgB) under which DL BWP of the plurality of DL BWPs the UE resumes PDCCH-related configuration. For example, if the network does not indicate which DL BWP among the plurality of BWP the UE restores the PDCCH-related configuration, the UE restores the PDCCH-related configuration under the initial DL BWP. For example, if the network indicates (e.g., in Msg4 or MsgB) under which DL BWP among the plurality of DL BWPs the UE resumes the PDCCH-related configuration, the UE resumes the PDCCH-related configuration under the DL BWP indicated by the network.
5. PDCCH-related configuration for subsequent transmissions is provided in an RRCRelease message that transitions the UE from rrc_connected state to rrc_inactive state
Before the UE enters the rrc_inactive state, the network may provide PDCCH-related configurations to be used for subsequent transmissions in SDT procedures that are later initiated by the UE. In response to receiving the PDCCH-related configuration in the RRCRelease message received in the rrc_connected state triggering the state transition, the UE may store the received PDCCH-related configuration in the UE-inactive AS context. The received PDCCH-related configuration may be different from the PDCCH-related configuration used by the UE in the rrc_connected state. In other words, the UE may store (at least) two PDCCH-related configurations in a UE INACTIVE AS context, one of which is used when the UE is in rrc_connected state, and the other of which is received in an RRCRelease message triggering a state transition to rrc_inactive. In response to initiation of the SDT procedure or in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE may restore the PDCCH-related configuration from the UE-inactive AS context (to be used for the subsequent transmission).
For example, when the UE is in the rrc_connected state, the network transmits an RRCRelease message with a suspend field to migrate the UE into the rrc_inactive state. The network may provide the PDCCH-related configuration in the RRCRelease message (to be used for subsequent transmissions) so that later when the UE initiates the SDT procedure, the UE may listen for the PDCCH during subsequent transmissions in the SDT procedure using the previously provided PDCCH-related configuration received in the RRCRelease message.
Since the stored PDCCH-related configuration is a dedicated configuration for the UE, it may be more appropriate for the UE to schedule subsequent transmissions for this purpose. For example, the stored PDCCH-related configuration contains a search space that is UE-specific search space, and thus the network is able to schedule UEs with DCI format 0_1 or DCI format 1_1. For example, the stored PDCCH-related configuration contains a TCI state configuration of the PDCCH, and the network may indicate a TCI state for listening to the PDCCH with a TCI state indication of the PDCCH MAC control element.
Combinations of the above alternatives are possible.
For the first example, if the network provides a PDCCH-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE listens for the PDCCH during a subsequent transmission in the SDT procedure using the provided PDCCH-related configuration (e.g., alternative 3). If the network does not provide a PDCCH-related configuration in the first DL transmission of the SDT procedure (e.g., msg4 or MsgB), the UE listens to the PDCCH (e.g., alternative 1 or alternative 2) during a subsequent transmission in the SDT procedure using the PDCCH-related configuration provided in the system information. An example is shown in fig. 24.
For the second example, if the network provides a PDCCH-related configuration in the first DL transmission of the SDT procedure (e.g., msg4 or MsgB), then the UE listens for the PDCCH during a subsequent transmission in the SDT procedure using the provided PDCCH-related configuration (e.g., alternative 3). If the network does not provide the PDCCH-related configuration in the first DL transmission of the SDT procedure (e.g., msg4 or MsgB), the UE resumes the PDCCH-related configuration from the UE inactive AS context to listen to the PDCCH during subsequent transmissions in the SDT procedure (e.g., alternative 4).
For a third example, if the network provides (or indicates) a second PDCCH-related configuration in the system information to be used for subsequent transmissions, the UE listens for the PDCCH during subsequent transmissions in the SDT procedure using the second PDCCH-related configuration (e.g., alternative 2). If the network does not provide (or indicate) a second PDCCH-related configuration in the system information to be used for subsequent transmissions, the UE continues to use the same PDCCH-related configuration used during the RA procedure for SDT to listen for PDCCHs during subsequent transmissions in the SDT procedure (e.g., alternative 1). An example is shown in fig. 24.
For the fourth example, if the network provides the first PDCCH-related configuration in an RRCRelease message transmitted in the first SDT procedure and the network does not provide the second PDCCH-related configuration in the first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after the completion of the first SDT procedure, then the UE listens for the PDCCH during a subsequent transmission in the second SDT procedure using the provided first PDCCH-related configuration (e.g., alternative 3). If the network provides the first PDCCH-related configuration in an RRCRelease message transmitted in the first SDT procedure, and the network also provides the second PDCCH-related configuration in a first DL transmission (e.g., msg4 or MsgB) of a second SDT procedure initiated by the UE after the first SDT procedure is completed, the UE listens for the PDCCH during a subsequent transmission in the second SDT procedure using the provided second PDCCH-related configuration (e.g., alternative 3).
For a fifth example, if the network provides a first PDCCH-related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network does not provide a second PDCCH-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE listens for the PDCCH (e.g., alternative 5) during a subsequent transmission in the SDT procedure using the provided first PDCCH-related configuration. If the network provides a first PDCCH-related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network also provides a second PDCCH-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE listens to the PDCCH during a subsequent transmission in the SDT procedure using the provided second PDCCH-related configuration (e.g., alternative 3).
For the sixth example, if the network provides (or indicates) a first PDCCH-related configuration in the system information to be used for subsequent transmissions and the network does not provide a second PDCCH-related configuration in an RRCRelease message transmitted before the UE initiated the SDT procedure, then the UE listens for the PDCCH during subsequent transmissions in the SDT procedure using the first PDCCH-related configuration (e.g., alternative 2). If the network provides (or indicates) a first PDCCH-related configuration in the system information to be used for subsequent transmissions, and the network also provides a second PDCCH-related configuration in an RRCRelease message transmitted before the UE initiates the SDT procedure, the UE listens to the PDCCH (e.g., alternative 3 or alternative 5) during subsequent transmissions in the SDT procedure using the second PDCCH-related configuration.
During an RRC recovery procedure (e.g., RA procedure) on the cell, the UE performs transmission on a Physical Uplink Shared Channel (PUSCH) and/or reception on a Physical Downlink Shared Channel (PDSCH) based on a shared channel related configuration provided in system information (e.g., SIB 1) of the cell. In response to successful receipt of the rrcrescente message, the UE may recover the shared channel related configuration from the stored UE inactivity AS context, and the network may also provide the shared channel related configuration in the rrcrescente message. In other words, the UE uses the shared channel related configuration provided in the system information until the rrcrenule message is successfully received. The shared channel related configuration may include a PUSCH configuration (e.g., PUSCH-Config). The shared channel related configuration may include a PDSCH configuration (e.g., PDSCH-Config). The shared channel related configuration may include a TCI state configuration (e.g., TCI-statestoadmodlist) of the PDSCH. The shared channel related configuration may include a configured grant configuration (e.g., configured grantconfigug). The shared channel related configuration may include a semi-persistent scheduling configuration (e.g., SPS-Config).
For RACH based SDT procedure, it is assumed that during RA procedure for SDT on a cell, the UE performs transmission on PUSCH and/or reception on PDSCH based on shared channel related configuration also provided in system information (e.g., SIB 1) of the cell. The shared channel related configuration used during RA procedures for SDT may be the same as the shared channel related configuration used during RA procedures not for SDT. The shared channel related configuration used during RA procedures for SDT may be different from the shared channel related configuration used during RA procedures not for SDT.
For example, the PDSCH configuration used during RA procedure for SDT may be the same as the PDSCH configuration used during RA procedure not for SDT (e.g., PDSCH-Config), while the PUSCH configuration used during RA procedure for SDT (e.g., non-PUSCH-Config) may be different from the PUSCH configuration used during RA procedure not for SDT (e.g., PUSCH-Config). For example, the PDSCH configuration (e.g., non-PDSCH-Config) used during RA procedures for SDT may be different from the PDSCH configuration (e.g., PDSCH-Config) used during RA procedures not for SDT, while the PUSCH configuration used during RA procedures for SDT may be the same as the PUSCH configuration (e.g., PUSCH-Config) used during RA procedures not for SDT.
For example, the PDSCH configuration and PUSCH configuration used during RA procedure for SDT may be the same as those used during RA procedure not for SDT. For example, the PDSCH configuration and PUSCH configuration used during RA procedures for SDT may be different from those used during RA procedures not for SDT.
The network may indicate which shared channel related configuration among the shared channel related configurations provided in the system information during the RA procedure for the SDT is to be used by the UE. For example, the network provides a PDSCH configuration list in the system information and indicates which PDSCH in the list is to be used during the RA procedure for SDT. The indication may be provided in system information (e.g., SIB 1). The indication may be provided in dedicated signaling (e.g., an RRCRelease message) to the UE. Alternatively, the network directly provides a second PDSCH configuration in the system information, where this second PDSCH configuration is for RA procedures for SDT but not for RA procedures not for SDT.
In case there is a subsequent transmission in the RACH based SDT procedure, it is not clear which shared channel related configuration is used by the UE for performing the transmission on PUSCH and/or the reception on PDSCH during (a stage of) the subsequent transmission, since the RA procedure is considered to be completed in response to a successful reception of the first DL transmission (e.g. Msg4 or MsgB) of the SDT procedure.
For subsequent transmissions in the RACH-based SDT procedure, the UE may perform transmissions on PUSCH and/or receptions on PDSCH based on at least one of the following alternatives:
1. the shared channel related configuration for subsequent transmissions is the same as the shared channel related configuration used during RA procedure for SDT
For example, the network provides the first PDSCH configuration in the system information. The UE uses the first PDSCH configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE also uses the first PDSCH configuration during subsequent transmissions in SDT procedures. For example, the network provides the first and second PDSCH configurations in the system information. The UE uses the first PDSCH configuration during RA procedures not used for SDT, the UE uses the second PDSCH configuration during RA procedures used for SDT, and the UE also uses the second PDSCH configuration during subsequent transmissions in SDT procedures.
For example, the network provides a first PUSCH configuration in the system information. The UE uses the first PUSCH configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE also uses the first PUSCH configuration during subsequent transmissions in SDT procedures. For example, the network provides the first and second PUSCH configurations in the system information. The UE uses the first PUSCH configuration during RA procedures not used for SDT, the UE uses the second PUSCH configuration during RA procedures used for SDT, and the UE also uses the second PUSCH configuration during subsequent transmissions in SDT procedures.
Because the shared channel related configuration used during the RA procedure for SDT is provided in the system information, the network may have some limitations on scheduling UEs during subsequent transmissions.
The shared channel related configuration of the SDT procedure may be provided in SIB 1. The shared channel related configuration of the SDT procedure may be provided in a system information block (other than SIB 1), such as a SIB providing configuration related to the SDT.
The network may provide an indication of which of the shared channel related configurations provided in the system information during the RA procedure for the SDT is to be used by the UE.
2. The shared channel related configuration for subsequent transmissions is also provided in the system information but may be different from the shared channel related configuration used during RA procedure for SDT
For example, the network provides the first and second PDSCH configurations in the system information. The UE uses the first PDSCH configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE uses the second PDSCH configuration during subsequent transmissions in SDT procedures. For example, the network provides the first, second, and third PDSCH configurations in the system information. The UE uses the first PDSCH configuration during RA procedures not used for SDT, the UE uses the second PDSCH configuration during RA procedures used for SDT, and the UE also uses the third PDSCH configuration during subsequent transmissions in SDT procedures.
For example, the network provides the first and second PUSCH configurations in the system information. The UE uses the first PUSCH configuration during RA procedures not used for SDT and during RA procedures used for SDT, and the UE uses the second PUSCH configuration during subsequent transmissions in SDT procedures. For example, the network provides the first, second and third PUSCH configurations in the system information. The UE uses the first PUSCH configuration during RA procedures not used for SDT, the UE uses the second PUSCH configuration during RA procedures used for SDT, and the UE also uses the third PUSCH configuration during subsequent transmissions in SDT procedures.
Because the shared channel related configuration for subsequent transmissions is provided in the system information, the network may have some limitations on scheduling UEs during subsequent transmissions.
The shared channel related configuration of the SDT procedure may be provided in SIB 1. The shared channel related configuration of the SDT procedure may be provided in a system information block (other than SIB 1), such as a SIB providing configuration related to the SDT.
The network may provide a first indication of which of the shared channel related configurations provided in the system information is to be used by the UE during the RA procedure for the SDT. The network may provide a second indication of which of the shared channel related configurations provided in the system information will be used by the UE for subsequent transmissions. The second indication may be different from the first indication.
3. Shared channel related configuration for subsequent transmissions is provided in a first DL transmission (e.g., msg4 or MsgB) of an SDT procedure
The network may provide shared channel related configuration directly to the UE in the first DL transfer of the SDT procedure. In response to receiving the shared channel related configuration in the first DL transmission of the SDT procedure, the UE may perform a transmission on PUSCH and/or a reception on PDSCH based on the received shared channel related configuration during a subsequent transmission in the SDT procedure.
For example, the network provides a first PDSCH configuration in the system information and the network provides a second PDSCH configuration in the first DL transmission of the SDT procedure. The UE uses a first PDSCH configuration during an RA procedure for SDT and the UE uses a second PDSCH configuration during subsequent transmissions in the SDT procedure. For example, the network provides a first PUSCH configuration in the system information and the network provides a second PUSCH configuration in the first DL transmission of the SDT procedure. The UE uses the first PUSCH configuration during the RA procedure for SDT and the UE uses the second PUSCH configuration during subsequent transmissions in the SDT procedure.
For example, the network provides TCI status configuration of PDSCH in the first DL transmission of SDT procedure. The UE uses TCI state configuration of PDSCH during subsequent transmissions in SDT procedure.
The shared channel related configuration provided in the first SDT program may be for a second SDT program that is initiated after the first SDT program is completed. For example, when the UE is in rrc_inactive state, the network may transmit an RRCRelease message with a supensconfig to complete the first SDT procedure initiated by the UE. The network may provide the shared channel related configuration in the RRCRelease message such that, thereafter, when the UE initiates the second SDT procedure, the UE may perform a transmission on PUSCH and/or a reception on PDSCH during a subsequent transmission in the second SDT procedure using the previously provided shared channel related configuration.
The shared channel related configuration in the first DL transmission may be included in an RRC message (e.g., an RRCRelease message).
Because the shared channel related configuration is provided in dedicated signaling (e.g., RRCRelease messages) to the UE, the network may provide this UE with a configuration suitable for scheduling subsequent transmissions. For example, the network may provide a TCI state configuration of PDSCH, and the network may indicate a TCI state for receiving PDSCH using DCI format 1_1.
4. The shared channel related configuration for subsequent transmissions is the shared channel related configuration for use by the UE in the previous rrc_connected state
Upon entering the rrc_inactive state from the rrc_connected state, the UE will store (part of) its current RRC configuration in the UE INACTIVE AS context. The UE inactive AS context also contains shared channel related configuration. The UE may recover the shared channel related configuration from the UE inactive AS context to perform transmission on PUSCH and/or reception on PDSCH during subsequent transmissions.
For example, in response to receiving an indication from the network indicating that there is a subsequent transmission in the SDT procedure, the UE restores the PDSCH configuration from the UE inactive AS context and performs reception on the PDSCH during the subsequent transmission using the restored PDSCH configuration. For example, in response to receiving an indication from the network indicating that there is a subsequent transmission in the SDT procedure, the UE restores the PUSCH configuration from the UE inactive AS context and performs a transmission on the PUSCH during the subsequent transmission using the restored PUSCH configuration.
For example, in response to receiving an indication from the network indicating that there is a subsequent transmission in the SDT procedure, the UE restores the TCI state configuration of the PDSCH from the UE inactive AS context and performs reception on the PDSCH during the subsequent transmission using the restored TCI state configuration of the PDSCH.
Since the stored shared channel related configuration is a dedicated configuration for the UE, it may be more appropriate for the UE to schedule subsequent transmissions for this purpose. For example, the stored shared channel related configuration contains a TCI status configuration of PDSCH, and the network may indicate a TCI status for receiving PDSCH using DCI format 1_1.
The UE may resume its shared channel related configuration of SpCell (e.g., PCell in previous RRC connection). In case there are multiple DL BWP (under SpCell) in the UE inactive AS context, the UE may restore the shared channel related configuration under the initial DL BWP. Additionally or alternatively, the network may indicate (e.g., in Msg4 or MsgB) at which DL BWP among the plurality of DL the UE resumes the shared channel related configuration.
For example, if the network does not indicate which DL BWP among the plurality of DL BWPs under which the UE resumes the shared channel related configuration, the UE resumes the shared channel related configuration under the initial DL BWP. For example, if the network indicates (e.g., in Msg4 or MsgB) under which DL BWP among the plurality of DL BWPs the UE resumes the shared channel related configuration, the UE resumes the shared channel related configuration under the DL BWP indicated by the network. In the case where there are multiple UL BWP (under SpCell) in the UE inactive AS context, the UE may resume the shared channel related configuration under the initial UL BWP.
Additionally or alternatively, the network may indicate (e.g., in Msg4 or MsgB) under which UL BWP of the plurality of UL BWPs the UE resumes the shared channel related configuration. For example, if the network does not indicate which UL BWP among the plurality of UL BWPs under which the UE resumes the shared channel related configuration, the UE resumes the shared channel related configuration under the initial UL BWP. For example, if the network indicates (e.g., in Msg4 or MsgB) under which UL BWP of the plurality of UL BWPs the UE resumes the shared channel related configuration, the UE resumes the shared channel related configuration under the UL BWP indicated by the network.
5. Shared channel related configuration for subsequent transmissions is provided in the RRCRelease message that transitions the UE from rrc_connected state to rrc_inactive state
Before the UE enters the rrc_inactive state, the network may provide a shared channel related configuration to be used for subsequent transmissions in SDT procedures that are later initiated by the UE. In response to receiving the shared channel related configuration in the RRCRelease message received in the rrc_connected state triggering the state transition, the UE may store the received shared channel related configuration in the UE inactive AS context. The received shared channel related configuration may be different from the shared channel related configuration used by the UE in the rrc_connected state. In other words, the UE may store (at least) two shared channel related configurations in a UE INACTIVE AS context, one of which is used when the UE is in rrc_connected state, and the other of which is received in an RRCRelease message triggering a state transition to rrc_inactive. In response to initiation of the SDT procedure or in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE may restore the shared channel related configuration (to be used for the subsequent transmission) from the UE inactive AS context.
For example, when the UE is in the rrc_connected state, the network transmits an RRCRelease message with a suspend field to migrate the UE into the rrc_inactive state. The network may provide the shared channel related configuration in the RRCRelease message (to be used for subsequent transmissions) so that later when the UE initiates the SDT procedure, the UE may perform transmissions on PUSCH and/or receptions on PDSCH during subsequent transmissions in the SDT procedure using the previously provided shared channel related configuration received in the RRCRelease message.
Since the stored shared channel related configuration is a dedicated configuration for the UE, it may be more appropriate for the UE to schedule subsequent transmissions for this purpose. For example, the stored shared channel related configuration contains a TCI status configuration of PDSCH, and the network may indicate a TCI status for receiving PDSCH using DCI format 1_1.
Combinations of the above alternatives are possible.
For the first example, if the network provides a shared channel related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs transmission on PUSCH and/or reception on PDSCH during a subsequent transmission in the SDT procedure using the provided shared channel related configuration (e.g., alternative 3). If the network does not provide a shared channel related configuration in the first DL transmission of the SDT procedure (e.g., msg4 or MsgB), then the UE performs transmission on PUSCH and/or reception on PDSCH (e.g., alternative 1 or alternative 2) during a subsequent transmission in the SDT procedure using the shared channel related configuration provided in the system information.
For the second example, if the network provides a shared channel related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs transmission on PUSCH and/or reception on PDSCH during a subsequent transmission in the SDT procedure using the provided shared channel related configuration (e.g., alternative 3). If the network does not provide the shared channel related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE recovers the shared channel related configuration from the UE inactive AS context to perform transmission on PUSCH and/or reception on PDSCH during subsequent transmissions in the SDT procedure (e.g., alternative 4).
For a third example, if the network provides (or indicates) a second shared channel related configuration in the system information to be used for subsequent transmissions, the UE performs transmission on PUSCH and/or reception on PDSCH during subsequent transmissions in the SDT procedure using the second shared channel related configuration (e.g., alternative 2). If the network does not provide (or indicate) a second shared channel related configuration in the system information to be used for subsequent transmissions, the UE continues to use the same shared channel related configuration used during the RA procedure for SDT to perform transmissions on PUSCH and/or receptions on PDSCH during subsequent transmissions in the SDT procedure (e.g., alternative 1).
For the fourth example, if the network provides the first shared channel related configuration in an RRCRelease message transmitted in the first SDT procedure and the network does not provide the second shared channel related configuration in the first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after completion of the first SDT procedure, the UE performs transmission on PUSCH and/or reception on PDSCH during subsequent transmissions in the second SDT procedure using the provided first shared channel related configuration (e.g., alternative 3). If the network provides the first shared channel related configuration in an RRCRelease message transmitted in the first SDT procedure, and the network also provides the second shared channel related configuration in a first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after completion of the first SDT procedure, the UE performs transmission on PUSCH and/or reception on PDSCH during a subsequent transmission in the second SDT procedure using the provided second shared channel related configuration (e.g., alternative 3).
For a fifth example, if the network provides a first shared channel related configuration in an RRCRelease message that transitions the UE from rrc_connected state to rrc_inactive state, and the network does not provide a second shared channel related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs transmission on PUSCH and/or reception on PDSCH during subsequent transmissions in the SDT procedure using the provided first shared channel related configuration (e.g., alternative 5). If the network provides a first shared channel related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network also provides a second shared channel related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs transmission on PUSCH and/or reception on PDSCH during a subsequent transmission in the SDT procedure using the provided second shared channel related configuration (e.g., alternative 3).
For the sixth example, if the network provides (or indicates) a first shared channel related configuration in the system information to be used for subsequent transmissions and the network does not provide a second shared channel related configuration in the RRCRelease message transmitted before the UE initiates the SDT procedure, then the UE uses the first shared channel related configuration to perform transmissions on PUSCH and/or receptions on PDSCH during subsequent transmissions in the SDT procedure (e.g., alternative 2). If the network provides (or indicates) a first shared channel related configuration in the system information to be used for subsequent transmissions, and the network also provides a second shared channel related configuration in an RRCRelease message transmitted before the UE initiates the SDT procedure, then the UE uses the second shared channel related configuration to perform transmissions on PUSCH and/or receptions on PDSCH during subsequent transmissions in the SDT procedure (e.g., alternative 3 or alternative 5).
During an RRC recovery procedure (e.g., RA procedure) on the cell, the UE selects a beam (or SSB) each time before performing an Msg1/MsgA transmission. The UE transmits and/or receives using the selected beam until, for example, the RA procedure is successfully completed. In the event that there is a subsequent transmission in the RACH based SDT procedure, the network may decide to change the beam (or TCI state) used by the UE to perform the transmission and/or reception during the subsequent transmission. The network may need some assistance information to determine which beam (or TCI state) will be used by the UE. For example, the UE may be requested to perform CSI measurements and/or CSI reports so that the network may select a better beam (or TCI state) for the UE when needed.
For example, the UE may perform Channel State Information (CSI) measurements during RA procedures for SDT. For example, the UE may perform CSI measurements during subsequent transmissions in the SDT procedure. For example, the UE may perform CSI reporting during RA procedure for SDT. For example, the UE may perform CSI reporting during subsequent transmissions in the SDT procedure. CSI reports may be periodic. CSI reports may be aperiodic (e.g., triggered using CSI requests in DCI format 0_1). CSI reporting may be semi-static.
Because the UE cannot perform CSI measurement and/or CSI reporting without a corresponding configuration (referred to as a "CSI measurement/reporting related configuration"), it is necessary to specify how the UE acquires the CSI measurement/reporting related configuration to be used in the SDT. The CSI measurement/reporting related configuration may include a CSI measurement configuration (e.g., CSI-MeasConfig). The CSI measurement/reporting related configuration may include a CSI reporting configuration (e.g., CSI-ReportConfig). The CSI measurement/reporting related configuration may include a Physical Uplink Control Channel (PUCCH) configuration (e.g., PUCCH-Config).
For RACH-based SDT procedures, the UE may perform CSI measurements and/or CSI reports (during the SDT procedure) based on at least one of the following alternatives:
1. CSI measurement/reporting related configuration for RACH-based SDT procedure is provided in first DL transmission (e.g., msg4 or MsgB) of SDT procedure
The network may provide CSI measurement/reporting related configuration directly to the UE in the first DL transmission of the SDT procedure. In response to receiving the CSI measurement/report related configuration in the first DL transmission of the SDT procedure, the UE may perform CSI measurement and/or CSI reporting based on the received CSI measurement/report related configuration during a subsequent transmission in the SDT procedure.
For example, the network provides CSI measurement configuration in the first DL transmission of the SDT procedure. The UE performs CSI measurement using the CSI measurement configuration during subsequent transmissions in the SDT procedure. For example, the network provides CSI reporting configuration in the first DL transmission of the SDT procedure. The UE performs CSI reporting using the CSI reporting configuration during subsequent transmissions in the SDT procedure.
The CSI measurement/reporting related configuration provided in the first SDT procedure may be used for a second SDT procedure initiated after the first SDT procedure is completed. For example, when the UE is in rrc_inactive state, the network may transmit an RRCRelease message with a supensconfig to complete the first SDT procedure initiated by the UE. The network may provide the CSI measurement/reporting related configuration in an RRCRelease message such that, thereafter, when the UE initiates the second SDT procedure, the UE may perform CSI measurement and/or CSI reporting during a subsequent transmission in the second SDT procedure and/or during an RA procedure for the second SDT procedure using the previously provided CSI measurement/reporting related configuration.
The CSI measurement/reporting related configuration in the first DL transmission may be included in an RRC message (e.g., an RRCRelease message).
2. The CSI measurement/report related configuration for RACH based SDT procedure is the CSI measurement/report related configuration used by the UE in the previous rrc_connected state
Upon entering the rrc_inactive state from the rrc_connected state, the UE will store (part of) its current RRC configuration in the UE INACTIVE AS context. The UE inactive AS context also contains CSI measurement/reporting related configuration. The UE may recover the CSI measurement/reporting related configuration from the UE inactive AS context to perform CSI measurement and/or CSI reporting during subsequent transmissions in the SDT procedure and/or during RA procedure for the SDT procedure.
For example, in response to initiating the SDT procedure, the UE restores the CSI measurement configuration from the UE inactive AS context, and performs CSI measurement during the RA procedure for the SDT procedure and/or during a subsequent transmission in the SDT procedure using the restored CSI measurement configuration. For example, in response to initiating the SDT procedure, the UE restores the CSI reporting configuration from the UE inactive AS context and performs CSI reporting using the restored CSI reporting configuration during the RA procedure for the SDT procedure and/or during a subsequent transmission in the SDT procedure.
For example, in response to receiving an indication from the network that there is a subsequent transfer in the SDT procedure, the UE restores the CSI measurement configuration from the UE inactive AS context and performs CSI measurement during the subsequent transfer using the restored CSI measurement configuration. For example, in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE restores the CSI reporting configuration from the UE inactive AS context, and performs CSI reporting during the subsequent transmission using the restored CSI reporting configuration.
The UE may recover its CSI measurement/reporting related configuration for the SpCell (e.g., PCell in the previous RRC connection).
3. CSI measurement/reporting related configuration for RACH based SDT procedure is provided in RRCRelease message to migrate UE from rrc_connected state to rrc_inactive state
The network may provide CSI measurement/reporting related configuration to be used for RACH based SDT procedures later initiated by the UE before the UE enters rrc_inactive state. In response to receiving the CSI measurement/report related configuration in the RRCRelease message received in the rrc_connected state that triggered the state transition, the UE may store the received CSI measurement/report related configuration in the UE inactive AS context. The received CSI measurement/report related configuration may be different from the CSI measurement/report related configuration used by the UE in the rrc_connected state. In other words, the UE may store (at least) two CSI measurement/reporting related configurations in a UE INACTIVE AS context, one of which is used when the UE is in rrc_connected state, and the other of which is received in an RRCRelease message triggering a state transition to rrc_inactive. In response to initiation of the SDT procedure or in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE may recover the CSI measurement/report related configuration (to be used for RACH-based SDT procedure) from the UE inactive AS context.
For example, when the UE is in the rrc_connected state, the network transmits an RRCRelease message with a suspend field to migrate the UE into the rrc_inactive state. The network may provide CSI measurement/report related configuration in the RRCRelease message (to be used for RACH based SDT procedure) so that later when the UE initiates the SDT procedure, the UE may perform CSI measurement and/or CSI reporting during RA procedure for the SDT procedure and/or during subsequent transmission in the SDT procedure using the previously provided CSI measurement/report related configuration received in the RRCRelease message.
Combinations of the above alternatives are possible.
For the first example, if the network provides a CSI measurement/reporting related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE performs CSI measurement and/or CSI reporting (e.g., alternative 1) during a subsequent transmission in the SDT procedure using the provided CSI measurement/reporting related configuration. If the network does not provide the CSI measurement/reporting related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE recovers the CSI measurement/reporting related configuration from the UE inactive AS context to perform CSI measurement and/or CSI reporting during subsequent transmissions in the SDT procedure (e.g., alternative 2).
For the second example, if the network provides the first CSI measurement/reporting related configuration in an RRCRelease message transmitted in the first SDT procedure and the network does not provide the second CSI measurement/reporting related configuration in the first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after the completion of the first SDT procedure, the UE performs CSI measurement and/or CSI reporting during a subsequent transmission in the second SDT procedure using the provided first CSI measurement/reporting related configuration (e.g., alternative 1). If the network provides the first CSI measurement/reporting related configuration in an RRCRelease message transmitted in the first SDT procedure, and the network also provides the second CSI measurement/reporting related configuration in a first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after completion of the first SDT procedure, the UE performs CSI measurement and/or CSI reporting (e.g., alternative 1) during a subsequent transmission in the second SDT procedure using the provided second CSI measurement/reporting related configuration.
For a third example, if the network provides a first CSI measurement/reporting related configuration in an RRCRelease message that transitions the UE from rrc_connected state to rrc_inactive state, and the network does not provide a second CSI measurement/reporting related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs CSI measurement and/or CSI reporting during a subsequent transmission in the SDT procedure using the provided first CSI measurement/reporting related configuration (e.g., alternative 3). If the network provides a first CSI measurement/reporting related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network also provides a second CSI measurement/reporting related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE performs CSI measurement and/or CSI reporting (e.g., alternative 1) during a subsequent transmission in the SDT procedure using the provided second CSI measurement/reporting related configuration.
During an RRC recovery procedure (e.g., RA procedure) on the cell, the UE selects a beam (or SSB) each time before performing an Msg1/MsgA transmission. The UE transmits and/or receives using the selected beam until, for example, the RA procedure is successfully completed. From the network's perspective, after the network successfully detects and receives UL transmissions from the UE, the network may use the beam for subsequent transmissions to and/or receptions from the UE during the RA procedure.
In the event that there is a subsequent transmission in the RACH based SDT procedure, the network may decide to change the beam used by the network to perform transmission (to the UE) and/or reception (from the UE) during the subsequent transmission. The network may need some assistance information to determine which beam will be used by the network. For example, the UE may be requested to perform Sounding Reference Signal (SRS) transmission so that the network may select a better beam to use when needed. The SRS transmission may be periodic. SRS transmission may be aperiodic (e.g., triggered using SRS requests in DCI format 0_1 or DCI format 1_1). SRS transmission may be semi-static.
Because the UE cannot perform SRS transmission without a corresponding configuration (referred to as an "SRS-related configuration"), it is necessary to specify how the UE acquires the SRS-related configuration to be used in the SDT. The SRS-related configuration may include an SRS configuration (e.g., SRS-Config).
For RACH based SDT procedures, the UE may perform SRS transmission (during the SDT procedure) based on at least one of the following alternatives:
1. SRS related configuration for RACH-based SDT procedure is provided in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure
The network may provide SRS-related configuration directly to the UE in the first DL transmission of the SDT procedure. In response to receiving the SRS-related configuration in the first DL transmission of the SDT procedure, the UE may perform SRS transmission based on the received SRS-related configuration during a subsequent transmission in the SDT procedure.
For example, the network provides SRS configuration in the first DL transmission of the SDT procedure. The UE performs SRS transmission using the SRS configuration during subsequent transmissions in the SDT procedure.
The SRS-related configuration provided in the first SDT program may be used for a second SDT program initiated after the first SDT program is completed. For example, when the UE is in rrc_inactive state, the network may transmit an RRCRelease message with a supensconfig to complete the first SDT procedure initiated by the UE. The network may provide the SRS-related configuration in the RRCRelease message such that, thereafter, when the UE initiates the second SDT procedure, the UE may perform SRS transmission during subsequent transmissions in the second SDT procedure using the previously provided SRS-related configuration.
The SRS-related configuration in the first DL transmission may be included in an RRC message (e.g., an RRCRelease message).
2. The SRS-related configuration for RACH-based SDT procedure is the SRS-related configuration used by the UE in the previous rrc_connected state
Upon entering the rrc_inactive state from the rrc_connected state, the UE will store (part of) its current RRC configuration in the UE INACTIVE AS context. The UE inactive AS context also contains SRS-related configuration. The UE may recover the SRS-related configuration from the UE-inactive AS context to perform SRS transmission during the subsequent transmission.
For example, in response to receiving an indication from the network indicating that there is a subsequent transmission in the SDT procedure, the UE restores the SRS configuration from the UE inactive AS context and performs SRS transmission during the subsequent transmission using the restored SRS configuration.
The UE may resume its SRS-related configuration of SpCell (e.g., PCell in previous RRC connection). In the case where there are multiple UL BWP (under SpCell) in the UE inactive AS context, the UE may resume the SRS-related configuration under the initial UL BWP. Additionally or alternatively, the network may indicate (e.g., in Msg4 or MsgB) under which UL BWP of the plurality of UL BWPs the UE resumes SRS-related configuration. For example, if the network does not indicate which UL BWP among the plurality of UL BWP under which the UE resumes the SRS-related configuration, the UE resumes the SRS-related configuration under the initial UL BWP. If the network indicates (e.g., in Msg4 or MsgB) under which UL BWP of the plurality of UL BWPs the UE resumes the SRS-related configuration, the UE resumes the SRS-related configuration under the UL BWP indicated by the network.
3. SRS related configuration for RACH-based SDT procedure is provided in RRCRelease message that transitions UE from RRC_CONNECTED state to RRC_INACTIVE state
Before the UE enters the rrc_inactive state, the network may provide SRS-related configuration to be used for subsequent transmissions in the SDT procedure initiated by the UE later. In response to receiving the SRS-related configuration in the RRCRelease message received in the rrc_connected state triggering the state transition, the UE may store the received SRS-related configuration in the UE-inactive AS context. The received SRS-related configuration may be different from the SRS-related configuration used by the UE in the rrc_connected state. In other words, the UE may store (at least) two SRS-related configurations in a UE-INACTIVE AS context, one of which is used when the UE is in rrc_connected state, and the other of which is received in an RRCRelease message triggering a state transition to rrc_inactive. In response to initiation of the SDT procedure or in response to receiving an indication from the network that there is a subsequent transmission in the SDT procedure, the UE may resume SRS-related configuration from the UE-inactive AS context (to be used for the subsequent transmission).
For example, when the UE is in the rrc_connected state, the network transmits an RRCRelease message with a suspend field to migrate the UE into the rrc_inactive state. The network may provide the SRS-related configuration in the RRCRelease message (to be used for subsequent transmissions) so that later when the UE initiates the SDT procedure, the UE may perform SRS transmission during subsequent transmissions in the SDT procedure using the previously provided SRS-related configuration received in the RRCRelease message.
Combinations of the above alternatives are possible.
For the first example, if the network provides an SRS-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE performs SRS transmission during a subsequent transmission in the SDT procedure using the provided SRS-related configuration (e.g., alternative 1). If the network does not provide the SRS-related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE restores the SRS-related configuration from the UE-inactive AS context to perform SRS transmission during subsequent transmissions in the SDT procedure (e.g., alternative 2).
For the second example, if the network provides the first SRS-related configuration in an RRCRelease message transmitted in the first SDT procedure and the network does not provide the second SRS-related configuration in the first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after completion of the first SDT procedure, then the UE performs SRS transmission during a subsequent transmission in the second SDT procedure using the provided first SRS-related configuration (e.g., alternative 3). If the network provides the first SRS-related configuration in an RRCRelease message transmitted in the first SDT procedure and the network also provides the second SRS-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the second SDT procedure initiated by the UE after completion of the first SDT procedure, the UE performs SRS transmission during a subsequent transmission in the second SDT procedure using the provided second SRS-related configuration (e.g., alternative 3).
For a third example, if the network provides the first SRS-related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network does not provide the second SRS-related configuration in the first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, then the UE performs SRS transmission during a subsequent transmission in the SDT procedure using the provided first SRS-related configuration (e.g., alternative 3). If the network provides the first SRS-related configuration in an RRCRelease message that transitions the UE from the rrc_connected state to the rrc_inactive state, and the network also provides the second SRS-related configuration in a first DL transmission (e.g., msg4 or MsgB) of the SDT procedure, the UE performs SRS transmission during a subsequent transmission in the SDT procedure using the provided second SRS-related configuration (e.g., alternative 1).
The subsequent transmissions described in the alternatives above may be time periods in which subsequent UL/DL transmissions may occur. The subsequent transmissions described in the alternatives above may be time periods in which the UE may perform UL transmissions or DL receptions.
The above-described embodiments may be applicable to (and/or supported by) reduced capability NR devices (i.e., nr_light devices). The above embodiments may be applicable to (and/or supported by) normal NR devices.
The UE may initiate a small data transfer procedure on the serving cell of the non-last (primary) serving cell in the rrc_connected state. The UE may initiate a small data transfer procedure on the same serving cell as the last (primary) serving cell in the rrc_connected state.
Fig. 25 is a flow chart 2500 in accordance with an exemplary embodiment from the perspective of a UE. In step 2505, the UE receives a first PDCCH-related configuration in system information. In step 2510, the UE initiates a Small Data Transfer (SDT) procedure in an rrc_inactive state, wherein the SDT procedure includes a Random Access (RA) procedure and at least one subsequent transfer following the RA procedure. In step 2515, the UE listens to the PDCCH during the RA procedure based on the first PDCCH-related configuration in the rrc_inactive state. In step 2520, in the event (or when) the UE receives the second PDCCH-related configuration, the UE listens to the PDCCH in the rrc_inactive state based on the second PDCCH-related configuration for the at least one subsequent transmission.
In one embodiment, in the event that the UE does not receive the second PDCCH-related configuration (or when the UE does receive the second PDCCH-related configuration), the UE may monitor the PDCCH for the at least one subsequent transmission based on the first PDCCH-related configuration. Further, the UE may receive the second PDCCH-related configuration in a system information, msg4, MSGB, or RRCRelease message.
In one embodiment, the first PDCCH-related configuration and/or the second PDCCH-related configuration may include at least one of a search space configuration or a control resource set (core) configuration. The search space configuration may be associated with a common search space.
In one embodiment, the system information may include a third PDCCH-related configuration for listening to PDCCH during RA procedures not used for SDT. The at least one subsequent transmission may be for an Uplink (UL) and may be scheduled by a dynamic uplink grant. In addition, the SDT procedure may be an RRC connection recovery procedure.
Referring back to fig. 3 and 4, in one exemplary embodiment of the UE, the UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable the UE to: (i) receive a first PDCCH-related configuration in system information, (ii) initiate an SDT procedure in an rrc_inactive state, wherein the SDT procedure comprises an RA procedure and at least one subsequent transmission after the RA procedure, (iii) listen to the PDCCH based on the first PDCCH-related configuration during the RA procedure in the rrc_inactive state, and (iv) listen to the PDCCH based on the second PDCCH-related configuration in the rrc_inactive state for the at least one subsequent transmission if (or when) the second PDCCH-related configuration is received by the UE. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps or other acts and steps described herein.
Fig. 26 is a flow chart 2600 according to an exemplary embodiment from the perspective of a network node. In step 2605, the network node transmits a first PDCCH-related configuration to the UE in system information. In step 2610, the network node transmits a PDCCH to the UE in the rrc_inactive state based on the first PDCCH-related configuration during an RA procedure, wherein the RA procedure is part of an SDT procedure, and the SDT procedure includes at least one subsequent transmission after the RA procedure. In step 2615, in the case where the network node provides the second PDCCH-related configuration to the UE (or when the network node provides the second PDCCH-related configuration to the UE), the network node transmits the PDCCH to the UE in the rrc_inactive state based on the second PDCCH-related configuration for the at least one subsequent transmission.
In one embodiment, the network node may transmit the PDCCH for the UE in the rrc_inactive state based on the first PDCCH-related configuration for the at least one subsequent transmission in case (or when) the network node does not provide the second PDCCH-related configuration to the UE. Furthermore, the network node may provide the second PDCCH-related configuration in a system information, msg4, MSGB, or RRCRelease message.
In one embodiment, the first PDCCH-related configuration and/or the second PDCCH-related configuration may comprise at least one of a search space configuration or a CORESET configuration. The system information may include a third PDCCH-related configuration for transmitting a PDCCH during RA procedures not used for SDT.
Referring back to fig. 3 and 4, in one exemplary embodiment of the network node, the network node 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a network node to: (i) transmitting a first PDCCH-related configuration to the UE in system information, (ii) transmitting a PDCCH to the UE in the rrc_inactive state based on the first PDCCH-related configuration during an RA procedure, wherein the RA procedure is part of an SDT procedure and the SDT procedure includes at least one subsequent transmission after the RA procedure, and (iii) transmitting a PDCCH to the UE in the rrc_inactive state based on the second PDCCH-related configuration for the at least one subsequent transmission if (or when) the network node provides the second PDCCH-related configuration to the UE. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps or other acts and steps described herein.
Fig. 27 is a flow chart 2700 from the perspective of a UE according to an example embodiment. In step 2705, the UE initiates an SDT procedure on the cell in an rrc_inactive state, wherein the SDT procedure includes an RA procedure for SDT and subsequent transmissions after the RA procedure for SDT, and the cell is controlled by the network node. In step 2710, the UE listens to the PDCCH based on the first PDCCH-related configuration during the RA procedure for SDT. In step 2715, the UE listens to the PDCCH during subsequent transmissions based on the second PDCCH-related configuration.
In one embodiment, the UE may obtain a first PDCCH-related configuration from first system information of a cell. The first system information of the cell may be a system information block type 1 (SIB 1).
In one embodiment, the UE may acquire the second PDCCH-related configuration from the second system information of the cell before listening to the PDCCH based on the second PDCCH-related configuration. The second PDCCH-related configuration may be the same as the first PDCCH-related configuration. Alternatively, the second PDCCH-related configuration may be different from the first PDCCH-related configuration. The second system information of the cell may be a system information block type 1 (SIB 1). Alternatively, the second system information of the cell may be a system information block of a non-system information block type 1 (SIB 1).
In one embodiment, the UE may receive the second PDCCH-related configuration in a downlink message from the network node during an RA procedure for SDT before listening for the PDCCH based on the second PDCCH-related configuration. The UE may treat the RA procedure for SDT as completed in response to receiving the downlink message during the RA procedure for SDT.
In one embodiment, the UE may recover the second PDCCH-related configuration from the UE-inactive AS context before listening for the PDCCH based on the second PDCCH-related configuration. When the UE is in the rrc_connected state, the UE may monitor the PDCCH using the second PDCCH-related configuration. Upon a state transition from the rrc_connected state to the rrc_inactive state, the UE may store RRC configurations in the UE INACTIVE AS context, wherein the RRC configurations include a second PDCCH-related configuration.
In one embodiment, the UE may receive an RRCRelease message from the network node triggering a state transition of the UE from the rrc_connected state to the rrc_inactive state before listening to the PDCCH based on the second PDCCH-related configuration, wherein the RRCRelease message comprises the second PDCCH-related configuration.
In one embodiment, the first PDCCH-related configuration may be a control resource set (CORESET) configuration, a search space configuration, or a TCI state configuration, a CORESET configuration of the PDCCH. The second PDCCH-related configuration may be a search space configuration or a TCI state configuration of the PDCCH.
In one embodiment, the subsequent transmissions may include at least one UL transmission from the UE to the cell. The subsequent transmissions may also include at least one DL transmission from the cell to the UE. Subsequent transmissions may be scheduled by the network through dynamic uplink grants or dynamic downlink assignments. Subsequent transmissions may also be scheduled by the network through a configured uplink grant or a configured downlink assignment.
Referring back to fig. 3 and 4, in one exemplary embodiment of the UE, the UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable the UE to: (i) initiate an SDT procedure on the cell in an rrc_inactive state, wherein the SDT procedure comprises an RA procedure for SDT and subsequent transmissions after the RA procedure for SDT, and the cell is controlled by the network node, (ii) listen to the PDCCH based on the first PDCCH-related configuration during the RA procedure for SDT, and (iii) listen to the PDCCH based on the second PDCCH-related configuration during the subsequent transmissions. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps or other acts and steps described herein.
Various aspects of the disclosure have been described above. It should be apparent that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method practiced using any number of the aspects set forth herein. Moreover, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the concepts described above, in some aspects, parallel channels may be established based on pulse repetition frequencies. In some aspects, parallel channels may be established based on pulse position or offset. In some aspects, parallel channels may be established based on a time hopping sequence. In some aspects, parallel channels may be established based on pulse repetition frequency, pulse position or offset, and time hopping sequence.
Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), and various forms of program or design code with instructions (which may be referred to herein as "software" or "software modules" for convenience), or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
Further, the various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. The IC may include a general purpose processor, a digital signal processor (digital signal processor, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field programmable gate array (field programmable gate array, FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within the IC, external to the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
It should be understood that any particular order or hierarchy of steps in any disclosed process is an example of an example approach. It should be understood that the particular order or hierarchy of steps in the process may be rearranged based on design preferences while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. Software modules (e.g., including executable instructions and associated data) and other data may reside in a data memory, such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An example storage medium may be coupled to a machine, such as a computer/processor (which may be referred to herein as a "processor" for convenience), such that the processor can read information (e.g., code) from, and write information to, the storage medium. An example storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user equipment. In the alternative, the processor and the storage medium may reside as discrete components in a user device. Additionally, in some aspects, any suitable computer program product may comprise a computer-readable medium comprising code relating to one or more of the aspects of the disclosure. In some aspects, the computer program product may include packaging material.
While the application has been described in connection with various aspects, it will be appreciated that the application is capable of further modifications. This disclosure is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known and customary practice within the art to which the application pertains.
Claims (19)
1. A method for a user device, comprising:
receiving a first physical downlink control channel related configuration in system information, wherein the first physical downlink control channel related configuration comprises at least one of a first search space configuration or a first control resource set configuration;
initiating a small data transfer procedure in an rrc_inactive state, wherein the small data transfer procedure comprises a random access procedure and at least one subsequent transfer after the random access procedure;
listening for a physical downlink control channel based on the first physical downlink control channel related configuration during the random access procedure in the rrc_inactive state;
listening, in the rrc_inactive state, for the at least one subsequent transmission, to a second physical downlink control channel related configuration based on the second physical downlink control channel related configuration, where the second physical downlink control channel related configuration includes at least one of a second search space configuration or a second control resource set configuration, if the user equipment receives the second physical downlink control channel related configuration in the system information; and
Listening to the physical downlink control channel for the at least one subsequent transmission based on the first physical downlink control channel related configuration if the second physical downlink control channel related configuration is not received by the user equipment.
2. The method of claim 1, wherein the system information is SIB1.
3. The method of claim 1, wherein the first search space configuration is ra-SearchSpace.
4. The method of claim 1, wherein the second search space configuration is associated with a common search space.
5. The method according to claim 1, wherein the system information comprises a third physical downlink control channel related configuration for listening to the physical downlink control channel during a random access procedure not used for small data transmissions.
6. The method of claim 1, wherein the at least one subsequent transmission is for uplink and scheduled by dynamic uplink grants.
7. The method according to claim 1, wherein the small data transfer procedure is a radio resource control connection recovery procedure.
8. A method for a network node, comprising:
transmitting a first physical downlink control channel related configuration to a user equipment in system information, wherein the first physical downlink control channel related configuration comprises at least one of a first search space configuration or a first control resource set configuration;
transmitting a physical downlink control channel to the user equipment in an rrc_inactive state based on the first physical downlink control channel related configuration during a random access procedure, wherein the random access procedure is part of a small data transmission procedure, and the small data transmission procedure comprises at least one subsequent transmission after the random access procedure;
transmitting, by the network node, a second physical downlink control channel related configuration to the user equipment in the rrc_inactive state for the at least one subsequent transmission, the physical downlink control channel based on the second physical downlink control channel related configuration, wherein the second physical downlink control channel related configuration comprises at least one of a second search space configuration or a second control resource set configuration; and
Transmitting the physical downlink control channel to the user equipment in the RRC INACTIVE state based on the first physical downlink control channel related configuration for the at least one subsequent transmission without the network node providing the second physical downlink control channel related configuration to the user equipment.
9. The method of claim 8, wherein the system information is SIB1.
10. The method of claim 8, wherein the first search space configuration is ra-SearchSpace.
11. The method of claim 8, wherein the second search space configuration is associated with a common search space.
12. The method of claim 8, the at least one subsequent transmission is for uplink and scheduled by a dynamic uplink grant.
13. A user device, comprising:
a control circuit;
a processor mounted in the control circuit; and
a memory mounted in the control circuit and operatively coupled to the processor;
wherein the processor is configured to execute program code stored in the memory to:
Receiving a first physical downlink control channel related configuration in system information, wherein the first physical downlink control channel related configuration comprises at least one of a first search space configuration or a first control resource set configuration;
initiating a small data transfer procedure in a RRC INACTIVE state, wherein the small data transfer procedure comprises a random access procedure and at least one subsequent transfer following the random access procedure;
listening for a physical downlink control channel based on the first physical downlink control channel related configuration during the random access procedure in the RRC INACTIVE state;
listening, in the RRC INACTIVE state, for the at least one subsequent transmission, to a second physical downlink control channel related configuration if the user equipment receives the physical downlink control channel related configuration in the system information, wherein the second physical downlink control channel related configuration comprises a first; at least one of a search space configuration or a second control resource set configuration; and
listening to the physical downlink control channel for the at least one subsequent transmission based on the first physical downlink control channel related configuration if the second physical downlink control channel related configuration is not received by the user equipment.
14. The user equipment of claim 13, wherein the system information is SIB1.
15. The user device of claim 13, wherein the first search space configuration is ra-SearchSpace.
16. The user equipment according to claim 13, characterized in that the small data transfer procedure is a radio resource control connection recovery procedure.
17. The user device of claim 13, wherein the second search space configuration is associated with a common search space.
18. The user equipment according to claim 13, characterized in that the system information comprises a third physical downlink control channel related configuration for listening to the physical downlink control channel during a random access procedure not used for small data transmission.
19. The user device of claim 13, wherein the at least one subsequent transmission is for uplink and is scheduled by a dynamic uplink grant.
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US202063079934P | 2020-09-17 | 2020-09-17 | |
| US202063079911P | 2020-09-17 | 2020-09-17 | |
| US202063079890P | 2020-09-17 | 2020-09-17 | |
| US202063079897P | 2020-09-17 | 2020-09-17 | |
| US63/079,934 | 2020-09-17 | ||
| US63/079,890 | 2020-09-17 | ||
| US63/079,911 | 2020-09-17 | ||
| US63/079,897 | 2020-09-17 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114205920A CN114205920A (en) | 2022-03-18 |
| CN114205920B true CN114205920B (en) | 2023-12-08 |
Family
ID=77518964
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110989915.XA Active CN114205920B (en) | 2020-09-17 | 2021-08-26 | Method and apparatus for small data transfer procedure in wireless communication system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20220086899A1 (en) |
| EP (1) | EP3972368B1 (en) |
| KR (1) | KR20220037342A (en) |
| CN (1) | CN114205920B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11239939B2 (en) * | 2019-03-22 | 2022-02-01 | Samsung Electronics Co., Ltd. | Scheduling in communication systems with multiple service types |
| US11743948B2 (en) * | 2020-10-16 | 2023-08-29 | Qualcomm Incorporated | SRS transmitted with Msg4 ACK |
| WO2022139245A1 (en) * | 2020-12-21 | 2022-06-30 | Samsung Electronics Co., Ltd. | Method and apparatus for handling configured grant resources for small data transmission in wireless communication system |
| KR102517302B1 (en) * | 2022-03-18 | 2023-04-03 | 주식회사 블랙핀 | Method and Apparatus for RRC_CONNECTED state uplink transmission and RRC_INACTIVE uplink transmission in wireless mobile communication system |
| WO2023201729A1 (en) * | 2022-04-22 | 2023-10-26 | Nokia Shanghai Bell Co., Ltd. | Method and apparatus for small data transmission |
| KR102605958B1 (en) * | 2022-05-11 | 2023-11-24 | 주식회사 블랙핀 | Method and Apparatus for uplink transmission in RRC_INACTIVE state |
Citations (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107241764A (en) * | 2016-03-29 | 2017-10-10 | 电信科学技术研究院 | A kind of up, descending small data transmission method and device |
| WO2018172013A1 (en) * | 2017-03-24 | 2018-09-27 | Panasonic Intellectual Property Corporation Of America | User equipment and base station participating in radio access network update procedure |
| CN108738139A (en) * | 2017-04-18 | 2018-11-02 | 华为技术有限公司 | downlink data transmission method and device |
| CN109644452A (en) * | 2017-06-23 | 2019-04-16 | 联发科技股份有限公司 | It is used for the method and apparatus of random access channel program in a wireless communication system |
| CN109983822A (en) * | 2019-02-18 | 2019-07-05 | 北京小米移动软件有限公司 | Operation method, device, equipment and the storage medium of DRX timer |
| CN110536472A (en) * | 2019-08-08 | 2019-12-03 | 中兴通讯股份有限公司 | A kind of data transmission method, device and computer readable storage medium |
| CN110831123A (en) * | 2018-08-10 | 2020-02-21 | 电信科学技术研究院有限公司 | Signal sending and receiving method, network equipment and terminal |
| CN110913499A (en) * | 2018-09-18 | 2020-03-24 | 维沃移动通信有限公司 | Random access method and terminal |
| CN110944341A (en) * | 2018-09-25 | 2020-03-31 | 夏普株式会社 | Method performed by user equipment and user equipment |
| CN110958088A (en) * | 2018-09-27 | 2020-04-03 | 华为技术有限公司 | Communication method and device |
| CN111034329A (en) * | 2017-08-11 | 2020-04-17 | 高通股份有限公司 | Uplink early data transmission |
| EP3648539A1 (en) * | 2018-11-01 | 2020-05-06 | Comcast Cable Communications, LLC | Random access response reception |
| CN111132345A (en) * | 2018-10-31 | 2020-05-08 | 华硕电脑股份有限公司 | Method and apparatus for transmitting using preconfigured uplink resources |
| CN111181686A (en) * | 2018-11-09 | 2020-05-19 | 华硕电脑股份有限公司 | Method and apparatus for improving physical downlink control channel listening mode |
| CN111194089A (en) * | 2020-01-08 | 2020-05-22 | 北京紫光展锐通信技术有限公司 | BWP indication and conversion method, base station and user, electronic device and medium |
| CN111246590A (en) * | 2020-01-10 | 2020-06-05 | 北京紫光展锐通信技术有限公司 | Data transmission method and related product |
| CN111432460A (en) * | 2019-01-10 | 2020-07-17 | 北京三星通信技术研究有限公司 | Monitoring method of physical downlink control channel, terminal equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10568007B2 (en) * | 2017-03-22 | 2020-02-18 | Comcast Cable Communications, Llc | Handover random access |
-
2021
- 2021-08-26 CN CN202110989915.XA patent/CN114205920B/en active Active
- 2021-08-26 KR KR1020210113430A patent/KR20220037342A/en unknown
- 2021-08-26 EP EP21193183.7A patent/EP3972368B1/en active Active
- 2021-08-26 US US17/412,861 patent/US20220086899A1/en active Pending
Patent Citations (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107241764A (en) * | 2016-03-29 | 2017-10-10 | 电信科学技术研究院 | A kind of up, descending small data transmission method and device |
| WO2018172013A1 (en) * | 2017-03-24 | 2018-09-27 | Panasonic Intellectual Property Corporation Of America | User equipment and base station participating in radio access network update procedure |
| CN108738139A (en) * | 2017-04-18 | 2018-11-02 | 华为技术有限公司 | downlink data transmission method and device |
| CN109644452A (en) * | 2017-06-23 | 2019-04-16 | 联发科技股份有限公司 | It is used for the method and apparatus of random access channel program in a wireless communication system |
| CN111034329A (en) * | 2017-08-11 | 2020-04-17 | 高通股份有限公司 | Uplink early data transmission |
| CN110831123A (en) * | 2018-08-10 | 2020-02-21 | 电信科学技术研究院有限公司 | Signal sending and receiving method, network equipment and terminal |
| CN110913499A (en) * | 2018-09-18 | 2020-03-24 | 维沃移动通信有限公司 | Random access method and terminal |
| CN110944341A (en) * | 2018-09-25 | 2020-03-31 | 夏普株式会社 | Method performed by user equipment and user equipment |
| CN110958088A (en) * | 2018-09-27 | 2020-04-03 | 华为技术有限公司 | Communication method and device |
| CN111132345A (en) * | 2018-10-31 | 2020-05-08 | 华硕电脑股份有限公司 | Method and apparatus for transmitting using preconfigured uplink resources |
| EP3648539A1 (en) * | 2018-11-01 | 2020-05-06 | Comcast Cable Communications, LLC | Random access response reception |
| CN111181686A (en) * | 2018-11-09 | 2020-05-19 | 华硕电脑股份有限公司 | Method and apparatus for improving physical downlink control channel listening mode |
| CN111432460A (en) * | 2019-01-10 | 2020-07-17 | 北京三星通信技术研究有限公司 | Monitoring method of physical downlink control channel, terminal equipment and storage medium |
| CN109983822A (en) * | 2019-02-18 | 2019-07-05 | 北京小米移动软件有限公司 | Operation method, device, equipment and the storage medium of DRX timer |
| CN110536472A (en) * | 2019-08-08 | 2019-12-03 | 中兴通讯股份有限公司 | A kind of data transmission method, device and computer readable storage medium |
| CN111194089A (en) * | 2020-01-08 | 2020-05-22 | 北京紫光展锐通信技术有限公司 | BWP indication and conversion method, base station and user, electronic device and medium |
| CN111246590A (en) * | 2020-01-10 | 2020-06-05 | 北京紫光展锐通信技术有限公司 | Data transmission method and related product |
Non-Patent Citations (4)
| Title |
|---|
| "38331_CR1557r2_(Rel-16)_R2-2006350 - CR for 38.331 for CA_DC_enhancements".3GPP tsg_ran\tsg_ran.2020,全文. * |
| "draft_38331-g10_v3".3GPP tsg_ran\wg2_rl2.2020,全文. * |
| A_hybrid_Random_Access_method_for_smart_meters_on_LTE_networks;Chacalom;《IEEE XPLORE》;全文 * |
| 基于TD_LTE的网络优化设计与应用;郭小光;《中国优秀硕士学位论文全文数据库（电子期刊）信息科技辑》;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20220086899A1 (en) | 2022-03-17 |
| EP3972368A1 (en) | 2022-03-23 |
| CN114205920A (en) | 2022-03-18 |
| KR20220037342A (en) | 2022-03-24 |
| EP3972368B1 (en) | 2023-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220232659A1 (en) | Small Data Transmission | |
| US11653315B2 (en) | Method and apparatus for triggering and canceling power headroom report (PHR) in small data transmission procedure in a wireless communication system | |
| US11516873B2 (en) | Small data transmission | |
| CN114205920B (en) | Method and apparatus for small data transfer procedure in wireless communication system | |
| US11533773B2 (en) | Early data transmission | |
| KR102619898B1 (en) | Method and apparatus for selecting bwp for subsequent transmission in pre-configured resources based sdt in a wireless communication system | |
| US20230120096A1 (en) | Radio Resource Control Messaging | |
| US20220264680A1 (en) | Random Access on Multiple Active Protocol Stacks | |
| CN114258161B (en) | Method and apparatus for new data arrival for small data transfer in wireless communication | |
| US11570844B2 (en) | Release message in small data transmission procedure | |
| US11570836B2 (en) | Logical channel configuration | |
| US20220256634A1 (en) | Cell Configuration Parameters | |
| KR20220077869A (en) | Method and apparatus for supporting ue-to-network relay communication in a wireless communication system | |
| JP2023546922A (en) | Downlink data of small data transmission procedure | |
| US20220345970A1 (en) | Connection Reestablishment Procedure | |
| US20230309081A1 (en) | Method and apparatus for mobile terminated small data transmission in a wireless communication system | |
| WO2023205512A1 (en) | Timer for small data transmission | |
| WO2023154446A1 (en) | Small data transmission timer |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |