Patent Application
20250038807
This disclosure pertains to the operation of wireless networks such as those described in, for example: RP-202846, NR Sidelink Enhancement Work Item Description; 3GPP TR 22.886, Study on enhancement of 3GPP Support for 5G V2X Services; V16.2.0; TS 22.186, Service requirements for enhanced V2X scenarios, V16.2.0; TR 22.842, Study on Network Controlled Interactive Service (NCIS) in the 5G System (5GS), V17.1.0; TS 38.321, NR; Medium Access Control (MAC) protocol specification, V16.3.0; TS 38.331, Radio Resource Control (RRC) protocol specification, V16.3.1; TS 23.287, Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services, V16.5.0; TS 37.213, Physical layer procedures for shared spectrum channel access, V16.6.0; and TS 36.300, (E-UTRAN); Overall description; Stage 2, V16.6.0.
In licensed bands, when the MAC layer asks the physical layer to generate a sidelink (SL) transmission, the MAC layer assumes that the transmission may be made by the physical layer. The MAC layer takes a number of actions (also known as SL MAC layer procedures) based on this assumption. In unlicensed bands, the assumption no longer holds. The physical layer has to share the channel with other users and systems, and SL transmission attempts may fail because of Listen Before Talk (LBT) failures. This may negatively impact the SL MAC layer procedures. Accordingly, there is a need for improved SL procedures.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.
Methods are described herein to address the issues at the MAC layer resulting from potential LBT failures, and potential delayed transmissions. Methods are described herein to handle consistent LBT failures (LBT monitoring, consistent LBT failure determination, and consistent LBT failure recovery), LBT impact on SL RLF procedure, LBT impacts on PSFCH reception, LBT impacts on TX resource reselection procedure, LBT impacts on HARQ buffer management, LBT impacts on SL DRX procedure, LBT impacts on SL CSI Reporting procedure, LBT impacts on SL Scheduling Request procedure, and LBT impacts on SL Buffer Status Reporting procedure, and methods to improve efficiency of the UL/SL prioritization procedure over unlicensed bands.
For example, a wireless transmit/receive unit (WTRU) may monitor a plurality of TX resource pools within a sidelink bandwidth part (BWP) for LBT events. The LBT events may comprise an LBT success, an LBT failure, or an LBT attempt. The WTRU may cause, based on determining that an LBT failure has occurred, a corrective action associated with a sidelink MAC procedure. The WTRU may determine, based on the LBT failure, that a total number or consecutive number of detected LBT failures for one of the monitored TX resource pools exceeds a threshold, indicating a consistent LBT failure. The WTRU may, based on the consistent LBT failure, send an indication of the consistent LBT failure for the TX resource pool to peer WTRUs, and an indication of the consistent LBT failure for the TX resource pool to a serving cell.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.
Methods are described herein to address the issues at the MAC layer resulting from potential LBT failures, and potential delayed transmissions. The techniques described herein may be described as being performed by a wireless transmit/receive unit (WTRU). It is understood that with the wide variety of use cases contemplated for wireless communications, each WTRU may comprise or be included in any type of apparatus or device configured to transmit and/or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, bus or truck, a train, or an airplane, and the like.
Table 1 describes acronyms used herein.
The following terms are used herein:
LBT failure: A transmission attempt over unlicensed spectrum that results in a failure. The transmission cannot be made as the channel is being used by another user. The other user may be from the same system or different system, using the same technology or different technology. An LBT failure applies to a given transmission.
LBT success: A transmission attempt over unlicensed spectrum that results in a success. The transmitter has sensed the channel and determined that no other user is using the channel. The other user may be from the same system or different system, using the same technology or different technology. An LBT success applies to a given transmission.
LBT attempt: A transmission attempt to access a channel. The result of an LBT attempt is either an LBT success or LBT failure. An LBT attempt applies to a given transmission
LBT operation: Refers to the steps where a WTRU performs a Clear Channel Assessment (CCA) and determines whether the channel is free or busy. If free the LBT is successful. If busy, the LBT is a failure.
LBT state: The ongoing state of the channel that is to be used for transmission, A channel may be in at least 2 states: busy or free. When the LBT state of a channel is “busy,” transmission attempts may result in LBT failures. When the LBT state of a channel is “free,” transmission attempts may result in LBT successes.
Delayed transmissions: as part of NR-U standardization, the notion of pending HARQ processes was introduced, to allow for the case that transmissions of HARQ processes may result in LBT failures. The transmissions of these pending HARQ processes are delayed and are attempted in future configured uplink grants.
Unlicensed spectrum/unlicensed bands: Radio Spectrum, in general, can be categorized into two types, a) licensed—assigned exclusively to operators for independent usage, b) unlicensed—assigned to every citizen for non-exclusive usage subject to some regulatory constraints, like restrictions in transmission power etc.
Shared Spectrum: Spectrum that is shared and may be used by multiple categories of users. Some coexistence mechanism is required to allow the sharing of spectrum (e.g., listen before talk). Shared spectrum is typically unlicensed. However, it is also possible to share licensed spectrum.
NR Sidelink is envisioned for a number of use cases:
NR V2X sidelink: In one use case information is to be provided to vulnerable road users, e.g., pedestrian or cyclist, about the presence of moving vehicles in case of dangerous situation.
NR Commercial (non-V2X) sidelink: In another use case (Proximity based applications Augmented Reality/Virtual Reality (AR/VR)), sidelink communications with high throughput and low latency may be required. For example, a head mounted device VR unit may have a sidelink to offload computing to a gateway device.
NR Critical (non-V2X) sidelink: Some critical/emergency situations may require SL communications with little or no cellular coverage, and with first responders using their WTRUs for extended periods of time to communicate with each other and to send out location information. Power savings for first responders is an important factor.
Increased data rate has been a popular topic for Rel-17. The motivation behind it is to support higher data rate demanded by advanced V2X scenarios and also commercial sidelink use cases other than V2X.
In TS 22.186, the requirement of sensor information sharing between WTRUs is defined as 1000 Mbps data rate with reliability of 99.99%. Additionally, new service for people to exchange information and play game are expected to become increasingly popular (e.g., NCIS: Network Controlled Interactive Service). TR 22.842 captured several typical use cases for NCIS. The interactive services may happen between local users via sidelink where the local users may be AR/VR enabled phones or glasses, 3D-gaming equipment, and other HMDs. The required data rate is very high (e.g., several Gbps) as defined in TR 22.842. In current sidelink, the spectrum is too limited to achieve these higher data rate requirements.
XR and gaming is the acknowledged killer applications for glasses, Head Mounted Displays (HMDs), etc. SA1 has identified the use cases and requirements in Network Controlled Interactive Services: NCIS (TR 22.842)
Sidelink is identified as an important use case for XR, e.g., consume VR content via tethered VR headset in the interactive service. SA2 has defined the corresponding PQI for such kinds of requirements, where end-to-end latency is 5-10 ms and the required data rate requirement is 0.1-10 Gbps with reliability 99.99%. Table 2 shows an example of the new services for SL.
RANI has evaluated and concluded that the current release of NR sidelink cannot support the required data rate. Further, currently there is no suitable spectrum/bandwidth to support this kind of commercial service.
As part of Release 13, there was a study Item “Study on Licensed-Assisted Access Using LTE”. The amount of data traffic carried over cellular networks was increasing at a very fast rate and is expected to increase for many years to come. The number of users/devices was increasing and each user/device was accessing an increasing number and variety of services, e.g. video delivery. This required not only high capacity in the network, but also provisioning very high data rates to meet customers' expectations on interactivity and responsiveness. More spectrum was therefore needed for cellular operators to meet the increasing demand. The preferred type of spectrum to efficiently serve users is licensed spectrum. Licensed spectrum can deliver predictable high-quality services with the highest spectral efficiency. In addition, in order to deliver predictable services, mobile operators need to perform heavy network investments, through careful planning and deployment of high-quality network equipment and devices. The justifications for such extensive capital investments require the reliability and operational assurance enabled by licensed spectrum. It is therefore essential that the regulatory community keeps focusing on identifying and allocating new licensed spectrum that can be utilized specifically for mobile communications.
Striving to meet the market demands, there was increasing interest from operators in deploying some complementary access utilizing unlicensed spectrum to meet the traffic growth. e.g. large number of operator-deployed Wi-Fi networks and the 3GPP standardization of LTE/WLAN interworking solutions. This interest indicated that unlicensed spectrum, when present, may be an effective complement to licensed spectrum, for cellular operators to help address the traffic explosion in some scenarios, such as hotspot areas. A number of open questions needed to be addressed: question 1: which unlicensed spectrum to target and question 2: How 3GPP WTRUs would “use” this unlicensed spectrum?
Initially, the cellular industry, led by several network operators, infrastructure vendors and chipset manufacturers, focused on the 5 GHz industrial, scientific and medical (ISM) band, to serve the immediate need for additional spectrum for mobile broadband applications due to the ever increasing mobile data traffic.
The ISM bands are generally defined by the International Telecommunication Union (ITU) Radio Regulations (Article 5), but are regulated differently by each region (e.g. European Telecommunications Standards Institute (ETSI) in Europe or Federal Communications Commission (FCC) in USA).
The exact frequency allocation and detailed regulation depends on the country (e.g. South Korea vs. Japan). Note the allocations are not exactly the same in each country and that there are different rules depending on country. For example, there are different rules with respect to dynamic frequency selection (DFS), indoor/outdoor use, and transmit power control (TPC). There are also rules regarding power spectral density limits and Discontinuous transmission (e.g. in Japan). There are also rules regarding channel access and occupation rules: the equipment may implement an adequate spectrum sharing mechanism in order to facilitate sharing between the various technologies and applications. The adequate spectrum sharing mechanism can be e.g. LBT (Listen Before Talk), DAA (Detect And Avoid).
A nNumber of standardized solutions have been developed to use this unlicensed band:
LWA (LTE Wi-Fi Aggregation): enables utilizing both LTE and Wi-Fi links simultaneously, without requiring hardware changes to the network infrastructure equipment and mobile devices. LWA leverages carrier Wi-Fi deployments based on a dual connectivity architecture, where Wi-Fi is used instead of a secondary LTE eNB.
LAA: extension of LTE to unlicensed spectrum based on carrier aggregation, which has been standardized by 3GPP.
WLAN Offloading: 3GPP traffic offloaded to WiFi. Much older technology
Category 1: No LBT procedure is performed;
Category 2: LBT without random backoff with deterministic waiting time when the channel is found free;
Category 3: LBT with random backoff and fixed contention window size; and
Category 4: LBT with random backoff and variable contention window size (between some minimum and maximum).
The need to ensure fair sharing and coexistence with other technologies has led to the introduction of frame structure type 3. It is applicable to LAA secondary cell operation with normal cyclic prefix. The radio frame duration for frame structure type 3 is 10 ms. The 10 subframes within a radio frame are available for downlink transmissions. Downlink transmissions may occupy one or more consecutive subframes, starting anywhere within a subframe and ending with the last subframe either fully occupied or following one of the DwPTS durations. This may be referred to as an LAA burst. The 10 subframes [1 ms each] may be available for downlink transmission, where a transmission can occupy one or more consecutive subframes, starting within a subframe at the first or second slot boundaries. The transmission also does not need to end with the subframe. Instead, the downlink pilot time slot (DwPTS) architecture from frame structure type 2 (TDD) is reused. That means the last subframe of the “LAA radio frame” can either be fully occupied or follow one of the DwPTS durations.
Even though a LAA burst can span multiple subframes, the scheduling Downlink Control Information DCI (DCI1, DCI2, DCI2A etc) is being transmitted at every subframe that carries Physical Downlink Shared Channel (PDSCH). Information on starting and stopping points is carried in DCI. To provide these additional information to WTRU, DCI format 1C is used. For example, the following rules may apply: i) If there is regular scheduling DCI only DCI (DCI1, DCI2, DCI2A etc), it is assumed that all the symbol in the subframe are carrying LAA data; ii) If there is both regular scheduling DCI and DCI 1C, the subframe (current subframe) or next subframe may or may not be partial subframe (subframe carrying data in less than 14 Orthogonal Frequency Division Multiplexing (OFDM) symbol); or iii) If there no DCI at all, the subframe does not transmit any LAA data.
LAA may apply CCA in two steps: an initial CCA and an enhanced (or extended) CCA. In LAA, CCA is based on ED over a defined time duration, that does not exceed a certain threshold value (the ED threshold). There was significant discussion on the value of the threshold, but in the end a fixed threshold was adopted. The detected energy level needs to be below this threshold for a certain amount of time with a slot duration Tsl and defer time Td. Td depends on the priority of the traffic. If the channel is sensed to be clear, the transmitter can only transmit for a limited amount of time defined as the maximum channel occupancy time (COT) (Tm cot,p). Maximum channel occupancy time (COT) depends on the priority of the traffic. If the channel is sensed to be occupied during that time or after a successful transmission, the “enhanced (or extended) CCA” period is started by generating a random number ‘N’ that is within the contention window (CW). CW is within a range that depends on the priority of the traffic. For enhanced CCA: WTRU decrements N for each slot that the channel is sensed free. When N=0, WTRU can transmit.
The Discovery Reference Signals (DRS) is a set of signals that includes the Primary Synchronization Signal, the Secondary Synchronization Signal, the Cell-specific Reference Signal, and the Channel State Information Reference Signal (if configured). DRS transmission is utilized in LAA for cell detection, synchronization, and radio resource management (RRM) measurement. Similar to the Rel-12 DRS, LAA DRS can be transmitted within a periodically occurring time window called the DRS measurement timing configuration (DMTC) occasion. However, to reduce a collision probability, the transmission of DRS is also subject to LBT. DRS can be transmitted following a single idle observation interval of at least 25 μs. To compensate for potential DRS transmission blocking due to LBT and increase the probability of successful DRS transmission, the network is allowed to attempt DRS transmission in any subframe within the DMTC occasion.
Channel selection for LAA is important for coexistence with other RATs such as Wi-Fi. For example, LAA may avoid frequencies that are more congested with Wi-Fi [access points/station (APs/STAs)] and RRM measurements are critical for this purpose. In legacy LTE operation, Reference Signal Received Power (RSRP), Received Signal Strength Indicator (RSSI), and Reference Signal Received Quality (RSRQ) are specified and only RSRP and RSRQ can be reported to an eNB by a WTRU. RSSI can serve as a metric for the interference strength on a carrier, and it is possible to infer RSSI from RSRP and RSRQ reports. However, if the DRS is not transmitted by the eNB on a carrier, for example due to LBT, RSRP and RSRQ reports would not be available. As a result, RSSI measurement reports along with time information about when the measurements were made by a WTRU are useful for hidden node detection at an LAA eNB. The absolute RSSI level observed by a WTRU as well as statistics of RSSI distribution during a measurement period are useful to provide a more complete picture of the load on a carrier and assist in hidden node detection by correlating measurements made by one or more WTRUs with those made by the eNB. As a result, LAA has introduced new measurements of average RSSI and channel occupancy (percentage of time that RSSI was observed above a configured threshold) for RRM reports. To this end, a RSSI measurement timing configuration (RMTC) can be configured to indicate a measurement duration (e.g. 1-5 ms) and period between measurements (e.g. {40, 80, 160, 320, 640} ms).
LBT is also used for uplink channel access. Rel-14 eLAA supports two types of uplink channel access procedures:
Type 1 uplink channel access procedure is analogous to the one for downlink channel access in Rel-13 LAA where a series of slots for CCA have to be sensed as clear on a channel before a WTRU can transmit on the channel. The number of slots is generated from a CWS that is adaptively adjusted by a WTRU. Four types of priority classes are also supported in the uplink; however, particular values for MCOT and CWS are different from the ones in downlink.
Type 2 uplink channel access procedure is analogous to the one for Discovery Reference Signals (DRS) transmission where a WTRU performs CCA over only a short period. The duration of the period is fixed to be at least 25 μs.
For transmission of a Physical Uplink Shared Channel (PUSCH), an eNB indicates to a WTRU the type of channel access procedure through an uplink grant scheduling the PUSCH transmission.
In general, type 1 uplink channel access procedure is utilized to initialize a MCOT containing PUSCH transmission, while type 2 uplink channel access procedure is utilized within the MCOT for resuming a suspended transmission or for changing the transmission direction from downlink to uplink
In addition, in order to meet various regulatory requirements, there was a need for a new uplink waveform for eLAA. For example, the European Telecommunication Standardization Institute (ETSI) mandates that the occupied channel bandwidth, defined by 3GPP to be the bandwidth containing 99% of the power of the signal, may be between 80% and 100% of the declared nominal channel bandwidth. 3GPP adapted the principle of block interleaved frequency division multiplex (B-IFDMA) for eLAA.
COT sharing is a mechanism (enabled by ETSI-BRAN) wherein one device acquires a COT using usual CAT4 LBT and another device shares it using a 25 μs LBT with a gap provided the amount of transmission does not exceed the MCOT limit for the given priority class.
For eNB to WTRU COT sharing, the purpose of this mechanism was to allow LAA UL in which an eNB must send a grant to the WTRU before it can transmit on the UL and the delay between the grant and the corresponding UL transmission is at least 4 ms. For a WTRU to use the shared COT for Autonomous UL (AUL) transmissions, the following rule applies: the eNB may indicate using the ‘UL duration and offset’ field and ‘COT sharing indication for AUL’ field that a WTRU configured with autonomous UL may perform a Type 2 channel access procedure for autonomous UL transmissions(s) including PUSCH on a channel in subframe n when:
For WTRU to eNB COT sharing, it has been proposed that any COT acquired by a WTRU for Autonomous UpLink (AUL) transmission, if not fully exhausted, should be allowed to be shared with the eNB who in turn can use it for transmission of control or data to any WTRU with a pause and just 25 μs LBT as long as it transmits for the minimum duration required to transmit data of equal or higher priority. In the end however, the conditions for an eNB to share a COT initiated by a WTRU are much more restrictive:
For the case where an eNB shares a channel occupancy initiated by a WTRU, the eNB may transmit a transmission that follows an autonomous PUSCH transmission by the WTRU as follows: If ‘COT sharing indication’ in AUL-UCI in subframe n indicates ‘l’, an eNB may transmit a transmission in subframe n+X, where X is subframeOffsetCOT-Sharing, including PDCCH but not including PDSCH on the same channel immediately after performing a Type 2A DL channel access procedure, if the duration of the PDCCH is less than or equal to duration of two OFDM symbols and it may contain at least AUL-DFI or UL grant to the WTRU from which the PUSCH transmission indicating COT sharing was received.
For SL, transmission resources may be allocated to the WTRU by the gNB (for e.g., NR mode 1 resource allocation) or may be autonomously selected by the WTRU (for e.g., NR mode 2 resource allocation). Autonomous resource selection by the WTRU may be performed randomly or may be based on sensing. The terms WTRU autonomous resource selection, as referred to herein, denotes sensing-based resource selection and may be used interchangeably with mode 2 resource allocation or mode 2 sensing-based resource allocation.
If configured for mode 1 Operation, then in step 316 the Sidelink Grant Reception determines if the PDCCH occasion has a sidelink grant. This is determined if the DCI is destined for SL-RNTI or SLCS-RNTI. The former is used for dynamic grants, while the latter is used for configured grant Type 2—namely activation, deactivation, or to schedule a retransmission for a Configured grant transmission
If configured for mode 2 Operation, the WTRU follows steps 318, 320, and 322.
At step 318, in mode 2, the transmitting WTRU may continually evaluate which PSCCH/PSSCH durations may be used for a single MAC PDU transmission, for multiple MAC PDU transmissions, and the potential retransmissions of these MAC PDUs. To accomplish this, the Sidelink Grant Reception continually evaluates if TX resource (re) selection is necessary. A number of triggers may tell the MAC layer that it needs to find new PSCCH/PSSCH durations. For example, there is a reconfiguration of the Tx resource pools, there is new traffic that has no opportunity to be transmitted on sidelink, the PSCCH/PSSCH durations have not been used for an extended period of time, etc. At step 320, in order to assist the Sidelink Grant Reception, the MAC layer may ask the PHY layer to provide a set of potential resources. These are provided by the PHY layer (based on sensing). This is referred to as the Candidate Resource set. Ask PHY for list of candidate resources (based on sensing or based on RRC configuration from RRC (for exception resource pool). At step 322, the Sidelink Grant Reception may randomly select from this provided set of potential resources—in order to satisfy the transmission of one MAC PDU, multiple MAC PDUs, and the potential retransmissions of these MAC PDUs. The selected set denote the PSCCH/PSSCH durations for transmission.
At step 324, at the PSCCH/PSSCH duration, the Sidelink Grant Reception may select the MCS for the sidelink grant, and then may send the sidelink grant, the selected MCS, and the associated HARQ information to the Sidelink HARQ Entity for this PSSCH duration.
At step 326, the Sidelink HARQ entity, may obtain the MAC PDU from a Multiplexing and Assembly process. This is where Logical Channel Prioritization (LCP) occurs. The Sidelink HARQ entity, may also determine the sidelink control information for MAC PDU, and then may deliver the MAC PDU, the sidelink grant, and the Sidelink transmission information to the associated Sidelink process
At steps 328 and 330, the Sidelink Process, at the appropriate PSCCH/PSSCH duration, may notify the PHY to transmit SCI, then may notify the PHY to generate a transport block transmission. If HARQ is enabled, Sidelink Process also notifies the PHY to monitor PSFCH
In order to allow sidelink operations over unlicensed bands, the following areas need to be addressed:
What is the overall resource allocation mechanism in unlicensed bands?
What is the impact of the unlicensed band and LBT on the MAC procedures?
In licensed bands, when the MAC layer asks the physical layer to generate a transmission, the MAC layer assumes that the transmission may be made by the physical layer. The MAC layer takes a number of actions based on this assumption. In unlicensed bands, the assumption no longer holds, as the physical layer has to share the channel with other users and systems, and the transmission may lead to LBT failures. This results in the following issues:
Issue 1: Consistent LBT failure on SL: A sidelink WTRU may have multiple PC5 RRC connections to other peer WTRUs. In addition, the WTRU may be transmitting SL groupcast traffic and SL broadcast traffic. Any or all of these transmissions may be over unlicensed spectrum. LBT failures may occur for each of these transmissions. In some cases, the WTRU may suffer from consistent LBT failures. However, the notion of consistent LBT failures is not defined for sidelink operation. For example, the granularity of the LBT failure monitoring needs to be defined. Is this monitoring per source (TX) WTRU, per PC5 RRC connection, per SL groupcast transmission, per SL broadcast transmission, per specific cast type, per destination (RX) WTRU, etc. The actions of the WTRU upon declaring consistent LBT failure are also dependent on the selected granularity.
Issue 2: Impact to PSFCH Reception: In Rel. 16, after the MAC layer instructs the PHY layer to transmit the transport block, and if the HARQ feedback is enabled for this MAC PDU, the MAC layer also instructs the PHY layer to monitor PSFCH and perform PSFCH reception. In unlicensed bands, if the PHY layer transmission fails the LBT, the MAC PDU may not be transmitted and no HARQ feedback is expected for this sidelink transmission. Sidelink operation needs to take into account that no feedback is expected in these cases.
Issue 3: Impact on Sidelink RLF Declaration: The HARQ-based Sidelink RLF detection procedure is used to detect Sidelink RLF based on a number of consecutive DTX on PSFCH reception occasions for a PC5-RRC connection. PSFCH reception occasions are defined to occur when HARQ feedback has been enabled for the MAC PDU and the MAC layer generates a SL transmission. In such a case, the physical layer is instructed to monitor PSFCH for this SL transmission and perform PSFCH reception. However, the generated SL transmission at the MAC layer may result in an LBT failure. The PDU may not be transmitted on the SL, and no PSFCH may be generated by the RX WTRU. The TX WTRU may interpret this as a DTX, and this may trigger unwanted SL RLF declarations.
Issue 4: Impact on Resource Reselection Counter: If the MAC entity SL process is configured to perform transmissions of multiple MAC PDUs with Sidelink resource allocation mode 2, the process maintains a counter SL_RESOURCE_RESELECTION_COUNTER. This counter is initially set when the MAC entity is first triggered to perform a TX resource (re-) selection. The counter may be decremented when the Sidelink process generates a transmission. Namely if this transmission corresponds to the last transmission of the MAC PDU. As with the RLF declaration, the generated SL transmission at the MAC layer may result in an LBT failure. In such a case, the PDU may not be transmitted on the SL, and the SL_RESOURCE_RESELECTION_COUNTER should not be decremented.
Issue 5: Impact on HARQ buffer in Sidelink Process: A sidelink configured grant may be configured with a maximum number of transmissions (sl-MaxTransNum). When the Sidelink process generates a transmission and this transmission corresponds to the last transmission of the MAC PDU, the MAC entity checks if the maximum number of transmission attempts have been made for this MAC PDU. If so, the MAC entity assumes that the MAC PDU has been repeated the maximum number of times, and it flushes the HARQ buffer of the associated Sidelink process. As with the RLF declaration, the generated SL transmission at the MAC layer may result in an LBT failure. In such a case, the MAC PDU may not have been transmitted the maximum number of times, and the HARQ buffer should not be flushed.
Issue 6: Impact on SL UL Prioritization: A number of prioritization rules exist to allow the WTRU to send sidelink traffic over uplink traffic. In Rel. 16, the rule is based on:
One issue with the above is that in some cases, the prioritized SL transmission may not be sent since it leads to an LBT failure. In such cases, it would have been more efficient to transmit the uplink traffic. Prioritization rules may need to be modified to take into account the potential LBT failures. Although the example shows LBT failure on the sidelink, a similar problem exists in cases that LBT failure may also occur on the uplink.
Issue 7: Impact on SL DRX Procedure: As of Rel. 17, peer WTRUs involved in SL unicast communication may have a SL DRX configuration. This configuration provides SL DRX configuration to a RX WTRU. For proper SL communication the TX WTRU and RX WTRU must have the same understanding of the RX WTRU Active time—otherwise the TX WTRU may send a transmission to the RX WTRU, while the RX WTRU is in inactive mode, and not monitoring SL transmissions. The triggers to start and stop the majority of the timers that control the Active time are based on transmissions and receptions. As LBT failures impact transmissions, the RX WTRU Active time maintained by the TX WTRU and RX WTRU, may not be the same.
Issue 8: Impact on SL CSI Reporting: The Sidelink Channel State Information (SL-CSI) reporting procedure is used to provide a peer WTRU with sidelink channel state information. RRC configures a sl-LatencyBoundCSI-Report, which is maintained for each PC5-RRC connection.
The MAC entity maintains a sl-CSI-ReportTimer for each pair of the Source Layer-2 ID and the Destination Layer-2 ID corresponding to a PC5-RRC connection. sl-CSI-ReportTimer is used for a SL-CSI reporting WTRU to follow the latency requirement signaled from a CSI triggering WTRU. The value of sl-CSI-ReportTimer is the same as the latency requirement of the SL-CSI reporting in sl-LatencyBoundCSI-Report configured by RRC. In Rel. 16, the MAC entity starts the timer when triggered by a request from the peer WTRU. The MAC entity stops the timer if it has SL resources allocated for new transmission and the SL-SCH resources can accommodate the SL-CSI reporting MAC CE and its subheader as a result of logical channel prioritization. The assumption being that the WTRU may send the SL-CSI MAC CE to the requesting peer WTRU. However, in unlicensed bands, the WTRU may have an LBT failure, and the SL-CSI MAC CE may not be sent. The SL CSI reporting procedure needs to be enhanced to take into account the potential LBT failure.
Issue 9: Impact on SL Scheduling Request Procedure: When LBT failures occur:
When LBT failures occur, when there may be UL-SCH resources available, BSR may not be transmitted, and an SR may not be triggered.
In the embodiments described herein, the terms band and spectrum may be used interchangeably. Furthermore, the embodiments described herein may refer to operation over unlicensed bands or spectrum. It should be understood that these embodiments are also applicable to any shared spectrum where coexistence may rely on a listen-before-talk like mechanism.
In accordance with one embodiment, WTRUs may be configured with the necessary parameters to operate over the unlicensed band. The configuration may be provided through a preconfiguration, a configuration through system information, a configuration through dedicated signaling from a serving base station, or from a peer WTRU.
In the following, use is made of the terms: LBT failure, LBT success, LBT attempt, and LBT state.
An LBT failure may refer to a transmission attempt over unlicensed spectrum that results in a failure. The transmission cannot be made as the channel is being used by another user. The other user may be from the same system or different system, using the same technology or different technology. An LBT failure applies to a given transmission.
An LBT success may refer to a transmission attempt over unlicensed spectrum that results in a success. The transmitter has sensed the channel and determined that no other user is using the channel. The other user may be from the same system or different system, using the same technology or different technology. An LBT success applies to a given transmission.
An LBT attempt may refer to a transmission attempt to access a channel. The result of an LBT attempt is either an LBT success or LBT failure. An LBT attempt applies to a given transmission.
An LBT state may refer to the monitored state of the channel that is to be used for transmission, A channel may be in at least 2 states: busy or free. When the LBT state of a channel is “busy,” transmission attempts may result in LBT failures. When the LBT state of a channel is “free,” transmission attempts may result in LBT successes. The LBT state may be continually available to the MAC layer.
Note that in the following described embodiments, it is assumed that the MAC layer enhancements/changes rely on LBT events for individual transmission attempts. So, each attempt results in an LBT failure or LBT success, and actions are based on the LBT success or LBT failure. It should be understood that these enhancements/changes may also apply from the perspective of a number of transmission attempts. For example, an action may be performed when the number of LBT successes crosses a threshold or the number of consecutive LBT successes crosses a threshold. Or an action may be performed when the number of LBT failures crosses a threshold or the number of consecutive LBT failures crosses a threshold. For another example, an action may be performed when the ratio of LBT successes exceeds a threshold that may be (pre-) configured or predefined. Or an action may be performed when the ratio of LBT failures exceeds another threshold that may be (pre-)configured or predefined. It should also be understood that enhancements/changes may also apply from the perspective of LBT state. So, an action may occur if the MAC layer determines that the LBT state is FREE (or BUSY).
1. A WTRU involved in one or more sidelink transmissions that monitors the channel for LBT events and evaluates whether to determine consistent LBT failure and evaluates whether to take some corrective action as a result of the LBT events.
2. The WTRU of embodiment 1, wherein the LBT events may be LBT failures, LBT successes, LBT attempts.
3. The WTRU of embodiment 1, wherein the WTRU monitors LBT events at the granularity of one or more of the following: per LBT type, per band, per PC5 RRC connection, per cast type, per destination layer 2 ID, per source Layer 2 UID, per QoS profile, per sidelink service, per resource pool, per traffic type, per beam, per carrier.
4. The WTRU of embodiment 1, wherein the WTRU may determine an LBT state as BUSY, when the channel is being used by another terminal.
5. The WTRU of embodiment 1, wherein the WTRU may determine an LBT state as FREE, when the channel is not being used by another terminal.
6. The WTRU of embodiment 1, wherein the WTRU may determine an LBT state as PENDING, when the WTRU may not determine if the channel is being used by another terminal.
7. The WTRU of embodiment 4,5, or 6, wherein the determining is aperiodic, on demand, or performed continually.
8. The WTRU of embodiment 1, wherein the LBT events are aperiodic, occurring before the beginning of every transmission slot.
Related to determining consistent LBT failure:
9. The WTRU of embodiment 1, wherein the evaluation to determine consistent LBT failure, results in WTRU declaring a consistent LBT failure.
10. The WTRU of embodiment 9, wherein the declaration is based on number of LBT failures, number of consecutive LBT failures, percentage of LBT events crossing a threshold.
11. The WTRU of embodiment 10, wherein the crossing a threshold is over an observation window (for example sl_lbt-FailureDetectionTimer).
12. The WTRU of embodiment 9, wherein the declaration of consistent LBT failure may be determined at the granularity of one or more of the following: per LBT type, per band, per PC5 RRC connection, per cast type, per destination layer 2 ID, per source Layer 2 UID, per QoS profile, per sidelink service, per resource pool, per traffic type, per beam, per carrier.
13. The WTRU of embodiment 9, wherein as a result of the consistent LBT failure declaration, the WTRU performs an LBT recovery procedure.
14. The WTRU of embodiment 13, wherein the LBT recovery procedure involves informing the one or more peer WTRUs impacted by the consistent LBT failure through an indication.
15. The WTRU of embodiment 14, wherein the indication is sent over the PHY layer on the PSFCH.
16. The WTRU of embodiment 14, wherein the indication is sent over the MAC layer in a new MAC CE.
17. The WTRU of embodiment 16, wherein the MAC CE has an assigned high priority.
18. The WTRU of embodiment 14, wherein the indication is part of an LBT Report, that includes information on LBT Failures and/or Successes over a period of time; LBT timing information such as CCA time periods (such as the CCA sensing time), selected MCOT and/or CWS period; the MAC procedure that triggered the LBT report.
19. The WTRU of embodiment 14, wherein the informing the peer WTRUs is triggered by one or more of the following: the count of LBT Failures reaches a threshold, when LBT events on MAC procedures results in a change of operation of that procedure, when a periodic timer expires.
20. The WTRU of embodiment 13, wherein the LBT recovery procedure involves informing higher layers.
21. The WTRU of embodiment 13, wherein the LBT recovery procedure involves informing the serving gNB about the consistent LBT failure through an LBT report.
22. The WTRU of embodiment 21, wherein the LBT report includes one or more of the following information: band of failure, destination layer 2 ID, cast type, count of LT failures or LBT success, MAC procedure that triggered the LNT report, LBT timing information such as CCA time periods (such as the CCA sensing time), selected MCOT and/or CWS period.
23. The WTRU of embodiment 21, wherein the informing the peer WTRUs or serving gNB is triggered by one or more of the following: the count of LBT Failures reaches a threshold, when LBT events on MAC procedures results in a change of operation of that procedure, when a periodic timer expires.
24. The WTRU of embodiment 13, wherein the LBT recovery procedure involves declaring a SL RLF for the sidelink.
25. The WTRU of embodiment 13, wherein the LBT recovery procedure involves moving the sidelink transmission to a new unlicensed band.
Related to taking some corrective action as a result of the LBT events:
26. The WTRU of embodiment 1, wherein the evaluation to determine whether to take some corrective action as a result of the LBT events, involves modifying a MAC procedure.
27. The WTRU of embodiment 26, wherein the MAC procedure is the Monitoring of PSFCH Procedure.
28. The WTRU of embodiment 27, wherein as part of the Monitoring of PSFCH Procedure, the WTRU instructs the PHY layer to monitor PSFCH for a sidelink transmission and perform PSFCH reception, only if LBT is successful for the sidelink transmission.
29. The WTRU of embodiment 26, wherein the MAC procedure is the SL RLF Declaration Procedure.
30. The WTRU of embodiment 29, wherein as part of the SL RLF Declaration Procedure, the WTRU increments the count of HARQ DTX (numConsecutiveDTX) for each PSFCH reception occasion associated to the PSSCH transmission, only if LBT success was detected for the PSSCH transmission.
31. The WTRU of embodiment 29, wherein as part of the SL RLF Declaration Procedure, the WTRU receives assistance information from the peer WTRU sending the HARQ feedback, which includes information related to LBT successes.
32. The WTRU of embodiment 29, wherein as part of the SL RLF Declaration Procedure, the WTRU scales the configured timers and counters for SL RLF determination, by a factor K, if the SL transmissions are over unlicensed spectrum.
33. The WTRU of embodiment 29, wherein as part of the SL RLF Declaration Procedure, the WTRU may be configured with separate timers and counters for licensed spectrum and unlicensed spectrum.
34. The WTRU of embodiment 26, wherein the MAC procedure is the Resource Reselection Procedure.
35. The WTRU of embodiment 34, wherein as part of the Resource Reselection Procedure, the WTRU generates a transmission according to a stored sidelink grant, and decrements SL_RESOURCE_RESELECTION_COUNTER by 1 if this transmission corresponds to the last transmission of the MAC PDU and LBT success has been detected for this transmission.
36. The WTRU of embodiment 34, wherein as part of the Resource Reselection Procedure, the WTRU performs a SL resource reselection, when consistent LBT failure is declared.
37. The WTRU of embodiment 26, wherein the MAC procedure is HARQ flushing Procedure.
38. The WTRU of embodiment 37, wherein as part of the HARQ flushing Procedure, the WTRU maintains a count of the number of transmissions of a MAC PDU, and only includes in this count those transmissions of the MAC PDU for which the physical layer has determined LBT success.
39. The WTRU of embodiment 37, wherein as part of the HARQ flushing Procedure, the WTRU flushes the HARQ buffer of the associated Sidelink process, when consistent LBT failure is declared.
40. The WTRU of embodiment 26, wherein the MAC procedure is UL/SL Prioritization Procedure.
41. The WTRU of embodiment 40, wherein as part of the UL/SL Prioritization Procedure, the WTRU PHY layer provides an LBT state indication to the MAC layer, and the MAC layer uses this indication as part of the UL/SL Prioritization Procedure.
42. The WTRU of embodiment 40, wherein if the SL LBT state is known to be BUSY and the UL LBT state is known to be FREE, the WTRU should not prioritize the SL transmission, even if all the other conditions for the SL prioritization are met.
43. The WTRU of embodiment 26, wherein the MAC procedure is SL DRX Operation.
44. The WTRU of embodiment 43, wherein as part of SL DRX Operation, a TX WTRU only start the inactivity timer when the TX WTRU transmits a MAC PDU in a configured sidelink and the transmission results in an LBT success (or lack of LBT failure).
45. The WTRU of embodiment 26, wherein the MAC procedure is the SL CSI Reporting Procedure.
46. The WTRU of embodiment 45, wherein as part of SL CSI Reporting Procedure, the CSI reporting WTRU check whether the LBT was a success for the transmission of the CSI report, and if not (i.e., LBT failed), the CSI reporting WTRU should not cancel a triggered SL-CSI report.
47. The WTRU of embodiment 45, wherein as part of SL CSI Reporting Procedure, when WTRU chooses a HARQ process, the WTRU should prioritize the “pending” HARQ process that have MAC PDUs that carry a SL CSI reports.
48. The WTRU of embodiment 45, wherein as part of SL CSI Reporting Procedure, the CSI report includes an indication of when the CSI report calculation was made.
49. The WTRU of embodiment 26, wherein the MAC procedure is the Scheduling Request Procedure for sidelink.
50. The WTRU of embodiment 49, wherein as part of the Scheduling Request Procedure for sidelink, the SR Prohibit Timer should only be stopped when LBT success is determined for BSR transmission.
An LBT monitoring procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, a WTRU may have multiple concurrent sidelinks. The WTRU may have one or more sidelinks to a peer WTRU, as well as sidelinks to other WTRUs, as well as a Uu link to a gNB. The other WTRUs may have functionality that allows these to behave as controlling entities, scheduling entities, or relay entities (or simply relays). Some of these sidelinks may be over unlicensed spectrum, some over licensed spectrum, and some over ITS spectrum. In addition, the sidelinks over unlicensed spectrum may be over multiple unlicensed bands. For example, the 5 GHz band, the 6 GHz band, the 60 GHz band, etc.
A WTRU using unlicensed spectrum may perform LBT monitoring, which involves monitoring a number of LBT events. The LBT events may be LBT failures, LBT successes, LBT attempts. As a result of these LBT events, the WTRU may take certain WTRU actions, such as to declare consistent LBT failure, modify a MAC procedure, etc. The WTRU actions may be based on individual LBT events or based on a number of monitored LBT events in an observation window. In addition, the WTRU actions may be based on a single LBT event, or a combination of LBT events. For example, a WTRU action may be performed when the WTRU detects 90% of the LBT attempts result in an LBT failure, within an observation window of K msec.
The granularity of monitoring may be for one or a combination of the following:
Per LBT type: For example, based on the existing types, this may include: Type 1, Type 2, Type 2A, Type 2B, Type 2C. A WTRU may monitor how many LBT failures occur for Type 1 attempts. Additionally, this may be for any new types defined.
Per band: the WTRU may have sidelinks on different unlicensed bands and the monitoring may be per band. For example, monitoring over the 5 GHz band may be different from the monitoring over the 60 GHz band.
Per PC5 RRC connection: The WTRU may monitor LBT events for each PC5 RRC connection (from a source L2 ID to a destination Layer 2 ID).
Per cast type: The WTRU may monitor LBT events for each cast type. For example, it may perform the LBT monitoring for all broadcast sidelink transmissions, or all multicast sidelink transmissions, or all unicast sidelink transmissions.
Per destination layer 2 ID: The WTRU may monitor LBT events for a specific destination layer 2 ID. This may be useful for sidelink transmissions to a specific groupcast group, which share the same destination layer 2 ID.
Per source Layer 2 ID: The WTRU may monitor LBT events for a source layer 2 ID.
Per QoS profile: The WTRU may monitor LBT events for a specific QoS profile—so that all sidelinks having the same or similar profile may be monitored together.
Per sidelink service: The WTRU may monitor LBT events per sidelink service.
Per resource pool: The WTRU may monitor the LBT events for a specific resource pool or group of resource pools. For example, a WTRU may be configured with multiple TX resource pools. These resource pools may be in one SL BWP or over multiple SL BWPs. Some of the TX resource pools may be configured as “active”, and may be used for sidelink transmissions, while others may be configured as “inactive” and are not used for sidelink transmissions. The WTRU may be configured to monitor LBT events for each of these TX resource pools. The WTRU may have a different configuration for the monitoring of “active” and “inactive” TX resource pools.
Per traffic type: The WTRU may monitor the LBT events for a specific traffic type such as for user plane data, control plane data, sidelink HARQ feedback, etc.
Per beam: The WTRU may monitor the LBT events in omni-direction, or the WTRU may monitor the LBT events in each beam. For example, a beam may be QCL-ed with one SL reference signal, e.g., SL-SSB, or SL-CSI-RS, SL DMRS, etc.
Per carrier: The WTRU may monitor the LBT events for a specific carrier, for example in the carrier aggregation case.
The LBT events may be determined at any layer of the protocol stack (PHY, MAC, RLC, PDCP, RRC). In one example, the LBT event is determined at the PHY layer and an indication of the LBT event is sent to the higher layers (such as the MAC or RRC).
The WTRU may monitor the LBT events and make certain decisions regarding LBT state (busy, free, etc.). For example, the WTRU may monitor the state of a channel. If the channel is found to be busy (for example energy detection suggests another user is using the channel) the WTRU may indicate that the LBT state is BUSY. Alternatively, if the channel is found to be free (for example energy detection suggests no other user is using the channel) the WTRU may indicate that the LBT state is FREE. Alternatively, if the WTRU is not able to assess if the channel is busy or free (for example if not enough measurements are available) the WTRU may indicate that the LBT state is PENDING. The LBT state may be determined continually, for example it can be provided from the physical layer to the upper layers through a primitive. Alternatively, it can be provided upon aperiodically, for example before the beginning of every transmission slot. As another alternative it can be provided upon demand, for example the MAC layer may ask the physical layer to assess the LBT state. As another alternative it may be provided based on the condition(s) and/or triggering, for example a certain condition or combination of conditions may autonomously trigger the physical layer for access of LBT state.
A consistent LBT failure determination procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, WTRU actions to determine consistent LBT failure may include monitoring the LBT events and determining when the total number of LBT failure events crosses a threshold. This may be for an observation window. Alternatively, the consistent LBT failure may include monitoring the LBT events and determining when a consecutive number of LBT failure events crosses a threshold. Alternatively, the consistent LBT failure may include monitoring the LBT events and determining when a certain percentage of LBT events occur. For example, when 90% of the LBT events result in an LBT failure. The consistent LBT failure may be determined at any layer of the protocol stack (PHY, MAC, RLC, PDCP, RRC). In one preferred alternative, the consistent LBT failure is determined at the MAC layer based on indications of LBT events from the PHY layer. The granularity of the consistent LBT failure determination may be for one or a combination of the following:
Per LBT type: For example, based on the existing types, this may include: Type 1, Type 2, Type 2A, Type 2B, Type 2C. A WTRU may determine consistent LBT failure per Type 1 attempts. Additionally, this may be for any new types defined.
Per band: the WTRU may have sidelinks on different unlicensed bands and the monitoring may be per band. For example, monitoring over the 5 GHz band may be different from the monitoring over the 60 GHz band.
Per PC5 RRC connection: The WTRU may determine consistent LBT failure for each PC5 RRC connection (from a source L2 ID to a destination Layer 2 ID).
Per cast type: The WTRU may determine consistent LBT failure for each cast type. For example, it may determine consistent LBT failure for all broadcast sidelink transmissions, or all multicast sidelink transmissions, or all unicast sidelink transmissions
Per destination layer 2 ID: The WTRU may determine consistent LBT failure for a specific destination layer 2 ID. This may be useful for sidelink transmissions to a specific groupcast group, which share the same destination layer 2 ID.
Per source Layer 2 ID: The WTRU may determine consistent LBT failure for a source layer 2 ID.
Per QoS profile: The WTRU may determine consistent LBT failure for a specific QoS profile—so that all sidelinks having the same or similar profile may be monitored together.
Per sidelink service: The WTRU may determine consistent LBT failure per sidelink service.
Per resource pool: The WTRU may determine consistent LBT failure for a specific resource pool or group of resource pools. For example, a WTRU may determine consistent LBT failure for multiple TX resource pools. These resource pools may be in one SL BWP or over multiple SL BWPs. Some of the TX resource pools may be configured as “active”, and may be used for sidelink transmissions, while others may be configured as “inactive” and are not used for sidelink transmissions. The WTRU may be configured to determine consistent LBT failure for each of these TX resource pools. The WTRU may have a different configuration for the determination of consistent LBT failure of “active” and “inactive” TX resource pools.
Per traffic type: The WTRU may determine consistent LBT failure user plane data, control plane data, sidelink HARQ feedback.
Per beam: The WTRU may determine consistent LBT failure in omni-direction, or the WTRU may monitor the LBT events in each beam. For example, a beam may be QCL-ed with one SL reference signal, e.g., SL-SSB, or SL-CSI-RS, SL DMRS, etc.
Per carrier: The WTRU may determine consistent LBT failure for specific carrier, for example in the carrier aggregation case.
Note that the granularity of the LBT monitoring may be different from the granularity of the consistent LBT failure. So, for example, the LBT events may be monitored at the granularity of a PC5 RRC connection, and the consistent LBT failure may be declared per band.
A typical realization for the determination of the consistent SL LBT failure is shown below (from TS 38.321):
A consistent LBT failure recovery procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. Once a consistent LBT failure is declared, the WTRU may take one or more of the following actions.
In a first action, the WTRU may inform the peer WTRU or peer WTRUs impacted by the consistent LBT failure. The WTRU may send an indication to the peer WTRU(s) that a consistent LBT failure has been detected. This message may be sent via an existing PC5 RRC message, a new PC5 RRC message, a MAC CE, or a PHY layer SCI signal or a PSFCH or PSFCH-like channel.
If PSFCH or PSFCH-like channel is used, sequence-based PSFCH or FDM-based PSFCH may be used to indicate to the peer WTRU(s) that a consistent LBT failure has been detected. For example, two sequences in PSFCH may be used to serve as 1-bit indication for consistent LBT failure detection. Sequence-x in PSFCH may indicate that a consistent LBT failure has been detected. Sequence-y in PSFCH may indicate that a consistent LBT failure has not been detected.
In another example, two separate PSFCHs in frequency domain may be used to serve as 1-bit indication for consistent LBT failure detection. PSFCH #1 may be used to indicate that a consistent LBT failure has been detected. PSFCH #2 may be used to indicate that a consistent LBT failure has not been detected. This may be an efficient and low overhead method for indication if such indication to the peer WTRU(s) that a consistent LBT failure has been detected has small number of bits e.g., one bit or two bits or the like.
Further, a joint sequence-based and FDM-based PSFCH may be used to extend the bit space to two bits or more for consistent LBT failure detection reporting, when a slightly higher number of bits for PSFCH-based indication is needed. For example, if additional assistance information in addition to consistent LBT failure detection are required, the extra bit space may be used to indicate additional assistance information. It is possible the physical layer does some pre-processing to limit the number of primitives signaled between the MAC and PHY layers.
A new LBT MAC procedure may consolidate these LBT indications and generates a Listen Before Talk Report (LBTR) MAC CE which provides information on LBT failures and/or successes over a period of time. In addition to LBT success and/or failure indications, the WTRU physical layer may provide the LBT category to the MAC layer, as well as the LBT timing information to the MAC layer. For example, LBT timing information may include CCA time periods (such as the CCA sensing time), selected MCOT and/or CWS periods. The LBTR may provide LBT failures for the WTRU active as a TX WTRU and a RX WTRU, separately. A WTRU may monitor LBT events for its SL transmissions. When the WTRU is acting as a TX WTRU, and the LBT failures may be referred to as TX WTRU based LBT failures. The peer WTRU communicating with this WTRU may be doing the same.
Information about LBT events at the peer WTRU may also benefit the RX WTRU. In such a case the WTRU is acting as a RX WTRU and the LBT failures are referred to as RX WTRU based LBT failures. When a UE sends an LBTR report, it may include information related to the TX UE based LBT failures as well as the RX UE based LBT failures. TX WTRU based LBT failures are unknown to the peer WTRUs and need to be signaled to maintain MAC procedure coordination. But also, RX WTRU based LBT failures that the WTRU is aware of from the peer WTRU, may be useful to the peer WTRU, since the peer WTRU may not be able to assume what RX WTRU LBT failures, either signaled to the WTRU or otherwise detected by the WTRU, are known to the RX WTRU.
The LBTR procedure may require several triggers to initiate the procedure resulting in cases of transmitting the LBTR. Triggers may include but are not limited to:
LBT Failures reaching a threshold. There may be an RRC configured LBT failure threshold. This threshold may either be a number of LBT failures over a known time period or a number of consecutive LBT failures. These parameters may be configurable since the reporting urgency may be dependent of the type of traffic supported.
When certain effects on other MAC procedures results in a change of operation of that procedure which needs to be known by the peer WTRU for proper operation. For example, any change in DRX operation that effects Active Time or the DRX cycle. In this case the MAC DRX procedure triggers the LBTR.
RRC configured periodic LBTRs.
An LBTR Prohibit timer should also be introduced to limit LBTR frequency.
The LBTR procedure may count LBT failures and/or successes over a configured LBTR Monitoring Period. For example:
If LBT Failure Count is greater than a configured LBT failure Count within a LBTR monitoring period, an LBTR is triggered; or
If LBT success count is less than a configured LBT success minimum within a LBTR monitoring period, an LBTR is triggered.
The LBTR procedure may derive the ratio of LBT failures and/or successes over a configured LBTR monitoring period. For example:
The LBTR procedure may count consecutive LBT failures and/or successes over a configured LBTR monitoring period.
If consecutive LBT Failure Count is greater than a configured consecutive LBT Failure Count within a LBTR Monitoring Period, an LBTR is triggered.
If consecutive LBT Success Count is less than a configured consecutive LBT Success Minimum within a LBTR Monitoring Period, an LBTR is triggered.
When other MAC Procedures trigger an LBTR, this may be by setting an LBTR Pending indication. The LBTR pending indication is later checked during MAC PDU multiplexing assembly to see an LBTR MAC CE is to be built.
The LBTR may include the following information:
It should be noted that similar operations may be provided by the PHY layer or RRC layer, and PHY layer or RRC layer signaling may be used to convey similar information to the NB.
The WTRU may attempt to transmit the LBTR on the same channel over which the consistent SL LBT is declared. The SL MAC CE may be assigned a very high priority, so that it is prioritized by the MAC entity, Alternatively, the WTRU may attempt to transmit the LBTR over another channel. The other channel may be over licensed band, or over another resource pool, or over another unlicensed band. This other resource pool or other unlicensed band may have no consistent SL LBT failure. Alternatively, there may be a short (control signaling) window which is exempted from LBT. The indication may be signaled through this short (control) window.
In a second action, the WTRU may inform higher layers. The WTRU may inform higher layers about the consistent LBT failure. For example, if the consistent LBT failure is determined at the MAC layer, the MAC layer may send an indication to its higher layers, such as the RRC and the NAS layer.
In a third action, the WTRU may perform housecleaning at WTRU (timers/counters). When a consistent LBT failure is declared, the WTRU may perform resetting of timers and counters that have stalled as a result of the LBT failures.
In a fourth action, the WTRU may declare SL RLF for sidelink. If the consistent LBT failure is for a specific band, the WTRU may declare a SL RLF for all sidelinks using this band. If the consistent LBT failure is for a specific PC5 RRC connection, the WTRU may declare a SL RLF for this particular sidelink
In a fifth action, the WTRU may inform the gNB. If the WTRU is in RRC CONNECTED, it may notify its serving gNB about the consistent LBT failure, using an LBTR. The message carrying the notification may also include the granularity of the consistent LBT failure. For each type of granularity, the WTRU may also include additional information in the message carrying the notification:
In a sixth action, the WTRU may move to a new unlicensed band. If a consistent LBT failure is determined for a specific unlicensed band, the WTRU may switch to another unlicensed band. In order to continue the sidelink communication, the peer WTRU would also need to move to the new unlicensed band. The peer WTRU may be made aware of this new unlicensed band through (pre) configuration, through configuration between the two peer WTRUs (for example as part of the AS capability exchange or PC RRC configuration exchange), through a dedicated exchange between the peer WTRUs (for example when the TX WTRU notifies the peer WTRU about the consistent LBT failure the message may include the information for the new unlicensed band)
In a seventh action, if the WTRU is using resource allocation mode 2, and a consistent LBT failure is determined on a “active” TX resource pool, the WTRU may autonomously change to an alternate TX resource pool that is being monitored, one for which no consistent LBT failure has been determined. The alternate TX resource pool may be “active” TX resource pool or an “inactive” TX resource pool.
In an eight action, if a consistent LBT failure is determined, this may trigger the WTRU to change the sidelink BWP.
A typical realization for the consistent SL LBT failure recovery is shown below (from TS 38.321):
In Rel. 16, after the MAC layer instructs the PHY layer to transmit the transport block and if the HARQ feedback is enabled for this MAC PDU, the MAC layer also instructs the PHY layer to monitor PSFCH for the transmission and perform PSFCH reception. In unlicensed bands, if the PHY layer transmission fails the LBT, the MAC PDU may not be transmitted and no HARQ feedback is expected for this sidelink transmission.
In such a case, a monitoring of the PSFCH procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, the TX WTRU may instruct the PHY layer to monitor the PSFCH for the sidelink transmission and perform PSFCH reception only if LBT is successful.
For example, the MAC specification TS 38.321 may be modified as follows:
Alternatively, the criteria may also be based on LBT failure detections. For example, the MAC specification TS 38.321 may be modified as follows:
Based on R16 sidelink behavior, the minimum time gap between PSFCH and the associated PSSCH is configured via the IE: sl-MinTimeGapPSFCH, and can be 2 or 3 slots. An LBT failure for either of these transmissions may result in the TX WTRU incorrectly interpreting this as a HARQ DTX.
Since an LBT failure is not necessarily an indication of poor radio channel quality, a WTRU should not declare a SL RLF in cases when the HARQ DTX is caused by LBT failures. The SL RLF declaration procedure may be modified as follows:
For LBT operation 1, it is possible that an LBT failure at the TX WTRU may result in the WTRU not transmitting the transport block to the RX WTRU. In such a case, the WTRU may not receive any HARQ feedback for the transport block and should not count this as a HARQ DTX.
For example, the MAC specification TS 38.321 may be modified as follows:
Alternatively, the PSFCH reception occasions may be redefined to only include those occasions where the sidelink transmission from the TX WTRU is an LBT success. For example, a PSFCH reception occasion may be defined as those occasions resulting from a sidelink transmission with HARQ feedback and for which and LBT success has been detected for the transmission.
For LBT operation 2, it is possible that an LBT failure at the RX WTRU may result in the RX WTRU not transmitting the HARQ feedback for the transport block. It is proposed that the TX WTRU does not interpret this as a HARQ DTX. Three alternatives are described, where the RX WTRU provides assistance to the TX WTRU to allow the TX WTRU to better assess if a HARQ DTX is a result of an LBT failure on a HARQ transmission from the RX WTRU. These alternatives are all described from the perspective of the RX WTRU sending assistance information related to LBT failures. It should be understood that the RX WTRU may also send assistance information related to LBT successes.
In a first alternative, the RX WTRU sends an LBT report to the TX WTRU to indicate the status of the LBT failures for HARQ feedback. This information may be for feedback for a specific PC5 RRC connection, or for a specific groupcast. The information may include the total number of LBT failures, or the total number of LBT failures for cases where the HARQ feedback was a NACK, or the total number of LBT failures for cases where the HARQ feedback was an ACK.
The RX WTRU may send this indication for each LBT failure. The indication may be sent over PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling, or piggybacked on a user plane message between the RX WTRU and the TX WTRU.
The RX WTRU may send this indication periodically. The RX WTRU may be configured with a reporting timer. At expiry of this timer, the RX WTRU may send a summary of the LBT failures since the last periodic report. The RX WTRU may send this periodic indication over PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling, or piggybacked on a user plane message between the RX WTRU and the TX WTRU.
The RX WTRU may be configured to send this indication when a configured trigger condition occurs. The RX WTRU may be configured with a threshold and an observation window time. The RX WTRU may monitor the number of LBT failures for HARQ transmissions and if this number exceeds the threshold during the observation window, the RX WTRU notifies the TX WTRU. The RX WTRU may send this triggered indication over PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling, or piggybacked on a user plane message between the RX WTRU and the TX WTRU.
The RX WTRU may be configured to send this indication when a configured trigger condition occurs. The RX WTRU may be configured with a threshold and an observation window time. The RX WTRU may monitor the number of consecutive LBT failures for HARQ transmissions, and if this number exceeds the threshold during the observation window, the RX WTRU notifies the TX WTRU. The RX WTRU may send this triggered indication over PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling, or piggybacked on a user plane message between the RX WTRU and the TX WTRU.
The RX WTRU may be polled by the TX WTRU to send an LBT report. For example, the TX WTRU may monitor the number of consecutive DTX, and have a first threshold for triggering an LBT report request, and a second threshold for triggering SL RLF. If the number of consecutive DTX passes a first threshold, the TX WTRU sends an LBT report request to the RX WTRU. This request may include an indication of the last time the TX WTRU received a non-DTX feedback (that is a HARQ ACK or NACK). The WTRU may store this time for each occurrence of a non-DTX HARQ feedback in a PSFCH reception occasion. Upon reception of the LBT report request, the RX WTRU prepares an LBT report indicating the number of LBT failures that have been observed for HARQ feedback transmission. If the TX WTRU provides the time of the last received non-DTX HARQ feedback, the RX WTRU uses this time to only include LBT failure information since this time. The LBT report request may be sent using a PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling. Similarly, the LBT report from the RX WTRU may be sent over PHY layer control signaling (SCI), over a MAC CE, over dedicated RRC signaling, or piggybacked on a user plane message between the RX WTRU and the TX WTRU.
Upon receiving the LBT report, the TX WTRU uses the information in the SL RLF procedure. If the report indicates that a LBT failure occurred, the TX WTRU may restart the consecutive DTX counter.
In a second alternative, the TX WTRU may be configured to be more conservative in the RLF monitoring for cases that the sidelink transmission is over unlicensed spectrum.
The TX WTRU may be configured with a scaling factor (K) to be used for sidelink transmission over unlicensed band. The scaling factor may be 1 for licensed band and some value>1 for unlicensed bands. The thresholds and/or timers are scaled by K for unlicensed bands. In effect the TX WTRU assumes that some of the DTXs are a result of the LBT failures for the HARQ transmissions at the RX WTRU and tries to compensate by using a higher threshold.
The TX WTRU may be configured with two thresholds-one for licensed bands and one for unlicensed bands. The threshold for unlicensed bands being higher than that for the licensed band. In effect the TX WTRU assumes that some of the DTXs are a result of the LBT failures for the HARQ transmissions at the RX WTRU, and the TX WTRU tries to compensate by using the higher 2nd threshold.
In a third alternative, the TX WTRU may configure the RX WTRU to always respond in the same slot. So, the IE: sl-MinTimeGapPSFCH may be set to 0, to indicate that the RX WTRU should provide its HARQ feedback in the same slot. If the LBT attempt at the TX WTRU is successful, the corresponding LBT attempt at the RX WTRU should also be successful.
An resource reselection procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, if the sidelink process is configured to perform transmissions of multiple MAC PDUs with sidelink resource allocation mode 2, the process maintains a counter SL_RESOURCE_RESELECTION_COUNTER. When this counter reaches 0, it is a signal to the TX WTRU to trigger TX resource (re-)selection, whereby the TX WTRU selects new resources for mode 2 resource allocation. In Rel. 16, this counter is decremented every time the MAC layer instructs the physical layer to generate a transmission according to the stored sidelink grant, and this transmission is the last transmission of a MAC PDU. However, the MAC layer may instruct the physical layer to generate a transmission, but this transmission may not be sent because of an LBT failure.
It is possible that an LBT failure at the TX WTRU may result in the WTRU not transmitting the transport block to the RX WTRU. In such a case, the WTRU may not transmit the last MAC PDU, and it should not receive any HARQ feedback for the transport block, nor should it decrement the SL_RESOURCE_RESELECTION_COUNTER. For example, the MAC specification TS 38.321 may be modified as follows where the criteria are based on LBT success for a transmission:
Alternatively, the criteria may also be based on LBT failure detections. For example, the MAC specification TS 38.321 may be modified as follows:
It is also necessary to avoid decrementing this counter for an extended period of time due to LBT failures so that the WTRU never does SL resource reselection. This may be achieved by monitoring for consistent LBT failure. When consistent LBT failure is declared, the WTRU may perform SL resource reselection.
Alternatively, the MAC layer may be configured with a maximum number of times the SL_RESOURCE_RESELECTION_COUNTER is not decremented because of an LBT failure. For example, the following procedure may be added to the MAC layer. It is assumed that the WTRU is configured with a maximum number of times the WTRU does not do a SL resource reselection as a result of an LBT failure (SL_RESOURCE_RESELECTION_COUNTER-LBTFailureThreshold). The WTRU uses a new counter SL_RESOURCE_RESELECTION_COUNTER-LBTFailureCount to count the number of times the SL resource reselection is not performed.
An HARQ flushing procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, a sidelink configured grant may be configured with a maximum number of transmissions (sl-MaxTransNum). When the Sidelink process generates a transmission and this transmission corresponds to the last transmission of the MAC PDU, the MAC entity checks if the maximum number of transmission attempts have been made for this MAC PDU. If so, the MAC entity assumes that the MAC PDU has been repeated the maximum number of times, and it flushes the HARQ buffer of the associated Sidelink process. As a result of LBT failures, the SL transmission at the MAC layer may not be transmitted. In such a case, the MAC PDU may not have been transmitted the maximum number of times, and the HARQ buffer should not be flushed.
For example, the MAC specification TS 38.321 may be modified as follows:
Alternatively, the criteria may also be based on LBT failure detections. For example, the MAC specification TS 38.321 may be modified as follows:
It is also necessary to avoid waiting an extended period of time due to LBT failures so that the WTRU never flushes the HARQ buffer of the associated Sidelink process. This may be achieved by monitoring for consistent LBT failure. When consistent LBT failure is declared, the WTRU may flush the HARQ buffer of the associated Sidelink process.
Alternatively, to avoid not flushing the HARQ buffer because of repeated LBT failures, the MAC layer may be configured with a maximum number of times the MAC layer does not consider MAC PDUs for which an LBT failure is detected. For example, the following new procedure may be added to the MAC layer. It is assumed that the WTRU is configured with a maximum number of times the WTRU does not count MAC PDUs that are not transmitted because of an LBT failure (sl-MaxTransNum-LBTFailureThreshold). The WTRU uses a new counter sl-MaxTransNum-LBTFailureCount to count the number of times that a transmission is not considered in the count to determine the Max TransNum.
An UL/SL prioritization procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. For example, when a WTRU has both SL and UL MAC PDUs ready for transmission, and it cannot send both simultaneously, the WTRU must make a prioritization decision. Based on the prioritization decision, the WTRUs MAC layer selects either the UL transmission or the SL transmission. The MAC layer than instructs the Physical layer to generate the transmission according to the associated grant.
However, because of LBT, the MAC PDU may not be transmitted. This is further complicated by the fact the LBT may occur on either the UL, the SL, or both the UL and the SL. It is proposed that the prioritization rules be modified to take into account the potential LBT failures.
In a first option, the PHY layer may provide an indication of the LBT state to the MAC layer. The LBT state is an indication of whether the channel is currently FREE or BUSY. The PHY layer may continually provide this indication to the MAC layer, or the MAC layer may query the PHY layer. The LBT state may be used during the prioritization procedure. The LBT state may be maintained for both the SL (sl_lbtState) and the UL (ul_lbtState). The LBT state for a channel that does not rely on LBT may be considered as “FREE.” When selecting a SL transmission over an UL transmission, the MAC layer may use the LBT state. Various combinations are possible. If the SL LBT state is known to be BUSY and the UL LBT state is known to be FREE, the WTRU should not prioritize the SL transmission, even if all the other conditions for the SL prioritization are met. An example MAC specification TS 38.321, taking into account the LBT states, is as follows:
In a second option, the MAC layer may instruct the PHY layer to “conditionally” generate both transmissions. The UL transmission according to the uplink grant, and the SL transmission according to the stored sidelink grant. The PHY layer may also be told if the transmission is first priority or second priority. A first priority transmission is the transmission that has priority according to UL/SL prioritization. A second priority transmission is the transmission that does not have priority according to UL/SL prioritization, but which may be transmitted if the first priority transmission results in an LBT failure. The PHY layer may also be told to monitor a GoAhead indication. This GoAhead indication is used to tell the PHY layer of the second priority transmission that the first priority transmission has resulted in an LBT failure.
At step 511, for the first priority transmission, the MAC layer tells the PHY layer to generate a transmission.
At step 512, for the second priority transmission, the MAC layer tells the PHY layer to conditionally generate a transmission. It also tells the PHY layer to monitor the LBT indication.
At step 513, the first priority transmission results in either an LBT failure or LBT success.
At step 514a, if an LBT success is detected, the second priority transmission should not be sent. The MAC layer may notify the PHY layer to cancel the transmission. This notification may be sent on the GoAhead indication.
At step 514b, if an LBT failure is detected, the second priority transmission should be sent. The MAC layer can notify the PHY layer to proceed with the second priority transmission. This notification may be sent on the GoAhead indication.
Note that in step 514a and 514b, an indication is sent from the MAC layer to the PHY layer (referred to as the GoAhead Indication). As an alternative to an indication for the second priority transmission to “go ahead” or “not go ahead,” the MAC layer may use the indication simply to signal “go ahead” and rely on a lack of indication to signal “no go ahead.” For example, the PHY layer may maintain a timer for each request to conditionally generate a transmission. If this timer expires without receiving a “go ahead” indication, the PHY layer cancels the second priority transmission. As another example, the PHY layer may maintain a timer for each request to conditionally generate a transmission. If this timer expires without receiving a “no go ahead” indication, the PHY layer proceeds with the second priority transmission.
In a third option, there may be specific rules for prioritization based on whether the UL and/or SL transmissions are over unlicensed bands. Below are example rules:
Alternatively, the WTRU may use different UL and or SL priority thresholds if the transmissions happen to be over unlicensed bands. Or they may use scaled versions of the thresholds over these bands. The priority thresholds may also be dynamically changed based on the load in the unlicensed band. For example, for a case where a channel is heavily loaded, LBT failures may be more common. For this case, it may be better to deprioritize the transmissions using this channel. If the channel is for SL, this can be accomplished by using a lower sl-PrioritizationThres. If the channel is for UL, this can be accomplished by using a lower ul-Prioritization Thres.
A SL DRX operation may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. As of Rel. 17, peer WTRUs involved in SL unicast communication may have a SL DRX configuration. This configuration provides SL DRX configuration to a RX WTRU. For proper SL communication the TX WTRU and RX WTRU must have the same understanding of the RX WTRU Active time—otherwise the TX WTRU may send a transmission to the RX WTRU, while the RX WTRU is in inactive mode-time during which the RX WTRU is not monitoring SL transmissions. The triggers to start and stop the majority of the timers that control the Active time are based on transmissions and receptions.
It is assumed that the TX WTRU may maintain equivalent timers to the RX WTRU to determine the active time. This implies that TX WTRU may maintain the following equivalent timers and parameters:
This may allow the TX WTRU to determine the Active time at the RX WTRU, and thereby send SL transmissions during the RX Active time.
Two issues that need to be addressed. A first issue is that, in licensed bands, the TX WTRU is expected to start its inactivity timer when the TX WTRU asks the physical layer to generate a transmission for the MAC PDU, according to the configured sidelink grant. The assumption is that the reception of the SCI may trigger the RX WTRU to also start its inactivity timer.
To remedy this, it is proposed that the TX WTRU only start the inactivity timer when the TX WTRU transmits a MAC PDU in a configured sidelink and the transmission results in an LBT success (or lack of LBT failure).
In case there is an LBT failure for a MAC PDU, the MAC layer may try to transmit the MAC PDU at a later time. These transmissions are not new transmissions or retransmissions, but delayed transmissions of a MAC PDU that has undergone an LBT failure. The MAC layer handles these delayed MAC PDU transmissions differently from new transmissions and retransmissions, and this needs to be accounted for. For example, if this later transmission results in an LBT success, then upon reception of the SCI for this transmission, this may trigger the RX WTRU to start its inactivity timer. However, the MAC layer at the TX WTRU may also need to start its equivalent inactivity timer. As a result, it is proposed that the MAC layer start its equivalent inactivity timer for the HARQ process of a delayed transmission, when the MAC PDU for this HARQ process is transmitted with LBT success.
In a second issue, in licensed bands, a RX WTRU may enter into a micro-sleep state for a sidelink HARQ process if it sends feedback for the received sidelink transmission (by starting HARQ-RTT-Timer). While this timer is running, the RX WTRU is not expected to receive any retransmissions from the TX WTRU, and it may enter an OFF state. The duration of the timer is set as the minimum time needed before a TX WTRU can process the feedback from the RX WTRU and then schedule the sidelink retransmission. However, in unlicensed bands, the sidelink feedback transmission may undergo an LBT failure. As a result, the RX WTRU may enter an OFF state, and the TX WTRU may never receive the feedback. The actions of the TX WTRU on reception of HARQ DTX for unlicensed bands have not been defined. However, certain actions may lead to a desynchronization between the TX WTRU and RX WTRU.
In case of an LBT failure, the RX WTRU may:
Cancel the sidelink feedback transmission and may rely on the HARQ DTX behavior of the TX WTRU. However, as already mentioned, the actions of the TX WTRU on reception of HARQ DTX for unlicensed bands have not been defined.
Alternatively, the RX WTRU may retry to send the sidelink HARQ feedback, but this transmission may be delayed. The RX WTRU upon an LBT failure, may start the HARQ RTT timer. Upon expiry, the RX WTRU may start the retransmission timer. While this timer is running, the TX WTRU may have sent a retransmission of the data. If this is successfully received by the RX WTRU, then the RX WTRU may inform the physical layer to cancel the delayed sidelink HARQ feedback for this HARQ process. Similarly, while this timer is running, the RX WTRU may successfully transmit the delayed sidelink HARQ feedback. It is proposed that the RX WTRU not restart the HARQ RTT timer and only restart the Retransmission timer (or start a second retransmission timer which may be different from the first retransmission timer).
Referring to
If an ACK was received 711, and there was LBT success 713, the RX WTRU may start a HARQ RTT timer and may enter OFF mode 715. If the HARQ RTT timer expires 717, the RX WTRU may wait for a new SL transmission 721.
If an NACK was received 712, and there was LBT success 714, the RX WTRU may start a HARQ RTT timer and may enter OFF mode 716. If the HARQ RTT timer expires 718, the RX WTRU may start a retransmission timer 720 and enter ACTIVE mode and may wait for a new SL transmission 722.
Referring to
Referring to
A SL CSI reporting procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. The SL CSI reporting procedure may be used by a CSI triggering WTRU to retrieve sidelink channel state information from a peer CSI reporting WTRU. The CSI triggering WTRU sends a CSI request to the peer CSI reporting WTRU, and the peer WTRU responds with the CSI report. The MAC entity maintains a sl-CSI-ReportTimer for each pair of the Source Layer-2 ID and the Destination Layer-2 ID corresponding to a PC5-RRC connection. sl-CSI-ReportTimer is used for a SL-CSI reporting WTRU to follow the latency requirement signaled from a CSI triggering WTRU. The timer provides the CSI reporting WTRU an indication of how long it has to send the CSI report. A CSI report sent after the timer expires is not useful to the CSI triggering WTRU, as it exceeds the sl-LatencyBoundCSI-Report which indicates the latency bound of SL CSI report in terms of number of slots. A CSI reporting WTRU normally cancels a triggered SL-CSI reporting if it sends the CSI report in a SL MAC CE to the CSI triggering WTRU, or if the sl-CSI-ReportTimer expires.
In Rel. 16, the former condition may be based on when the MAC entity has SL resources allocated for new transmission and the SL-SCH resources can accommodate the SL-CSI reporting MAC CE and its subheader as a result of logical channel prioritization. However, the resulting MAC PDU may not be transmitted by the PHY layer as a result of an LBT failure. In such cases, it is proposed to add new criteria before cancelling a triggered SL-CSI report. The CSI reporting WTRU check whether the LBT was a success for the transmission. If LBT failed, the CSI reporting WTRU should not cancel a triggered SL-CSI report. For example, the MAC specification TS 38.321 may be modified as follows:
Alternatively, the new criteria may also be based on LBT failure detections. For example, the MAC specification TS 38.321 may be modified as follows:
The time when the MAC layer generates the Sidelink CSI Reporting MAC CE and the time when the MAC layer generates the MAC PDU carrying this MAC CE do not necessarily coincide. It is expected that typically the MAC layer may generate the MAC CE before the MAC PDU is built. In such a case, it is also proposed that the MAC layer keeps track of which MAC PDU carries the CSI report MAC CE. This allows the MAC layer to know if the CSI report transmission was successful (LBT success) or not (LBT failure).
As an alternative, the CSI reporting procedure may stop the timer and cancel the triggered SL-CSI reporting as soon as the MAC layer generates the Sidelink CSI Reporting MAC CE. However, upon detection of an LBT failure for the MAC PDU carrying this MAC CE, the MAC layer may revert its decision to cancel the triggered SL-CSI reporting, and it may restart the stopped sl-CSI-ReportTimer for the triggered SL-CSI reporting. For example, it may re-trigger the SL-CSI reporting, and it may start a sl-CSI-ReportTimer. However, the timer is set to a value that is based on the time remaining to send the CSI report. For example, the difference between the configured sl-LatencyBoundCSI-Report and the time already spent waiting to transmit the CSI report.
One issue unique to unlicensed operation is what to do if Sidelink CSI report undergoes an LBT failure. One option is to delay the transmission of the MAC PDU until a later time, as used for NR-U. Here, all HARQ processes that have MAC PDUs that result in an LBT failure, are considered “pending.” For these available uplink grants, the WTRU relies on implementation to determine which of the “pending” HARQ processes uses this grant. If no special action is taken, the WTRU may not prioritize the pending” HARQ processes that may transmit the Sidelink CSI report. In so doing, the latency bound of the CSI report may not be met. As a result, when choosing a HARQ process, the WTRU may prioritize the “pending” HARQ process that have MAC PDUs that carry a SL CSI report. As a further enhancement, the WTRU may stop this prioritization when the latency bound is exceeded.
One issue with the delaying the CSI report because of LBT failures, is that the CSI triggering WTRU may not know the conditions under which the CSI report was generated. It is proposed that when CSI report MAC CE transmission is blocked by LBT Failure, and retransmitted later in time, additional signaling is introduced to either inform the CSI triggering WTRU when the CSI report was calculated and/or inform the CSI triggering WTRU of the transmission conditions when the CSI report was calculated.
When not operating in unlicensed spectrum and LBT is not used, the CSI triggering WTRU can determine when the CSI report calculation was made. The below address this problem:
Provide an additional indication in the CSI report that allows the CSI triggering WTRU to determine when the CSI report calculation was made. This may be the delay caused by LBT relative to the time of the first LBT failure, or it may be an absolute time reference.
LBT Failures and/or LBT Successes may be independently indicated to the CSI triggering WTRU so that the CSI triggering WTRU may determine the effective delay incurred by LBT for the CSI report.
The CSI triggering WTRU may receive additional information which allows the CSI triggering WTRU to know how the CSI report was calculated. Alternatively, the CSI triggering WTRU may indicated LBT Failure and Success to the CSI triggering WTRU, allowing the CSI triggering WTRU to determine there were LBT Failures which delayed the CSI report.
A scheduling request procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. A sidelink Scheduling Request is used for requesting SL-SCH resources for new transmissions when triggered by the Sidelink BSR or the SL-CSI reporting. Pending SR(s) should only be cancelled, and SR Prohibit Timer should only be stopped when LBT success is determined for BSR transmission. This is necessary to ensure the Prohibit Timer, delaying subsequent SR transmissions is not set when the current SR is not transmitted due to LBT Failure.
The following modifications to the sidelink SR procedure of TS 38.321 take into account the effect of LBT:
The example above from TS 38.321 may also be expressed in terms of LBT failure detection instead of LBT success detection as follows:
Alternatively, pending SR(s) may be cancelled, and prohibit timers may be stopped when the MAC PDU including the BSR is provided to the PHY layer as it is done in the existing Rel 16 procedure, but if LBT failure (or equivalently no LBT success) is determined the Pending SR(s) are restored and the Prohibit Timer restarted.
In addition, in Rel. 16 devices may cancel pending SR triggered according to the SL-CSI reporting and stop the respective sr-ProhibitTimer under two conditions: 1) when a SL grant(s) can accommodate the Sidelink CSI Reporting MAC CE 2) when the SL-CSI report is cancelled due to latency non-fulfilment. The first condition assumes that the WTRU may use the SL grant in time, which is before the SL-CSI report is cancelled due to latency non-fulfilment. However, the MAC PDU carrying the SL-CSI report on the sidelink grant may undergo an LBT failure, and its transmission may be delayed. The delayed transmission may be such that the SL-CSI report may not meet the latency requirement. To correct for this issue, it is proposed that the first condition be modified to make sure the MAC PDU carrying the SL CSI report undergoes a LBT success prior to the latency limit. The following modifications may be made to the sidelink SR procedure of TS 38.321 to take into account the effect of LBT:
or when the triggered SL-CSI report is cancelled due to latency non-fulfilment as
A buffer status reporting procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. The following modifications to the BSR procedure may be made to take into account the effect of LBT in sidelink:
If a Regular BSR has been triggered and there are UL-SCH resources available for transmission, but the transmission is blocked by LBT Failure an SR should be triggered. This is necessary since if the available grant is lost due to LBT Failure a new SR is needed to help ensure a subsequent grant is made available for transmission of the BSR.
For example, the MAC specification TS 38.321 may be modified as follows:
While the modified text above is described in terms of LBT Failure, it may have been also expressed in terms of no LBT Success.
The LBT Failure or LBT Success may not be a single instance. It may be a number of LBT Failure or Success detections. An SR may be triggered only after a series of LBT Failures affecting MAC BSR CE transmission.
A procedure may also be defined to count LBT Failures or LBT Successes, or to count consecutive LBT Failures or consecutive LBT Successes. Only if LBT Failures or consecutive LBT Failures exceeding a configured Maximum LBT Failure Threshold or if LBT Successes or consecutive LBT Successes are less than a configured Minimum LBT Success Threshold, is an SR triggered.
When BSR MAC CE transmission is blocked by LBT Failure and retransmitted later in time additional signaling is introduced to either inform the NB when the BSR was calculated and/or informs the NB of the transmission conditions when the BSR was calculated.
In order for the NB to properly process BSR it is necessary for the NB to know when the BSR was calculated.
When not operating in unlicensed spectrum and LBT is not used, the NB can roughly know when the content of the BSR was determined. Since the NB is aware of what scheduled and received and the rules for BSR, it can adequately interpret the BSR. But when LBT Fails and the transmission is delayed until LBT Success, the NB may receive an outdated BSR or inaccurate BSR leading potentially to more resource assignment than required by the WTRU, or less resources than needed by WTRU and/or transmission delay and QoS assurance penalty.
The following examples may solve this problem:
Provide an additional indication to the BSR that allows the NB to determine when the BSR was built. This may be the delay caused by LBT relative to the time of the first LBT failure, or it may be an absolute time reference.
LBT Failures and/or Successes may be independently indicated to the NB so that the NB may determine the effective delay incurred by LBT for the BSR.
Provide additional information with the BSR that informs the NB of the grant (e.g., uplink grant) used when the BSR was calculated.
It is preferred but it is not absolute necessary for the NB to receive additional information which allows the NB to know when the BSR was built. Alternatively, the NB must at least know when a BSR is providing inaccurate information. This may be accomplished by the WTRU indicating LBT Failure and Success to the NB, allowing the NB to determine there were LBT Failures which delayed the BSR.
BSR Triggering conditions should consider LBT Failures. New data becoming available and fulfilling the currently specified regular BSR triggering criteria, padding BSR triggering condition, BSR Retransmission Timer expiration, BSR Periodic Timer expiration, triggering criteria should only be considered when LBT succeeds. The addition of LBT criteria is mutually exclusive for each existing trigger and may therefore only affect a subset of the existing criteria.
For example (where all triggers are considered), the MAC specification TS 38.321 may be modified as follows:
A MAC PDU may contain at most one SL-BSR MAC CE, even when multiple events have triggered a SL-BSR. The Regular SL-BSR and the Periodic SL-BSR may have precedence over the padding SL-BSR.
The MAC entity may restart sl-retxBSR-Timer upon reception of an SL grant for transmission and LBT Success is determined of new data on any SLSCH.
All triggered SL-BSRs may be cancelled when the SL grant(s) can accommodate all pending data available for transmission. All BSRs triggered prior to MAC PDU assembly may be cancelled when LBT Success is determined and when a MAC PDU is transmitted and this PDU includes a SL-BSR MAC CE which contains buffer status up to (and including) the last event that triggered a SL-BSR prior to the MAC PDU assembly. All triggered SL-BSRs may be cancelled, and sl-retx-BSR-Timer and slperiodic-BSR-Timer may be stopped, when RRC configures Sidelink resource allocation mode 2.
While the modified text above is described in terms of LBT Success, it may have been also expressed in terms of no LBT Failure.
The LBT Failure or LBT Success may not be a single instance. It may be a number of LBT Failure or Success detections. An SR may be triggered only after a series of LBT Failures affecting MAC BSR CE transmission.
A procedure may also be defined to count LBT Failures or LBT Successes, or to count consecutive LBT Failures or consecutive LBT Successes. Only if LBT Failures or consecutive LBT Failures exceeding a configured Maximum LBT Failure Threshold or if LBT Successes or consecutive LBT Successes are less than a configured Minimum LBT Success Threshold, is an SR triggered.
While the exemplary MAC specific change above is described in terms of LBT success, the example may also be equally expressed in terms of no LBT Failure.
Alternatively, the BSR Periodic Timer and the BSR Retransmission Timer may be started or restarted as it is done in the existing procedure, but if LBT Failure is determined the BSR Periodic Timer and BSR Retransmission Timer is reset to the remaining value before the last reset because of LBT failure, or to a different time value for e.g., a configured time value.
This modification is necessary to ensure the BSR Periodic Timer or BSR Retransmission Timer are not reset so that periodic BSR or retransmission of BSR are not delayed when an BSR transmission is blocked by LBT Failure.
A MAC PDU retransmission procedure may be performed in accordance with one embodiment, which can be used in combination with any of the other embodiments described herein. In Mode 1 configured grant operation, a WTRU may be configured with IE: sl-Max TransNum, which determines the maximum number of transmissions for a SL HARQ process.
One issue with unlicensed bands is that a TX WTRU may not transmit a MAC PDU because of an LBT failure. In such a case, the count of the maximum number of transmissions for a SL HARQ process needs to take into account the LBT failures.
In mode 2 resource allocation, the TX WTRU may be configured with IE: sl-MaxTxTransNumPSSCH, which indicates the maximum transmission number (including new transmission and retransmission) for PSSCH. When the MAC entity determines the selected sidelink grants, it determines the number of HARQ retransmissions for a MAC PDU, from the configured IE: MaxTxTransNumPSSCH.
One issue with unlicensed bands is that a TX WTRU may not transmit a MAC PDU because of an LBT failure. In such a case, the TX WTRU would not make the configured number of retransmissions of the MAC PDU.
In order to address both these issues, upper layers may be notified that the MAC PDU was not transmitted the configured number of times.
The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities-including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G.” 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHZ, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHZ, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that may provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.
3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.
It may be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. In the example of
The communications system 100 may also include a base station 114a and a base station 114b. In the example of
TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, and/or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, and/or Network Services 113. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.
The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b/104b/105b, which may also include other base stations and/or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, e.g., one for each sector of the cell. The base station 114a may employ Multiple-Input Multiple Output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell, for instance.
The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115/116/117 may be established using any suitable Radio Access Technology (RAT).
The base station 114b may communicate with one or more of the RRHs 118a and 118b, TRPs 119a and 119b, and/or RSUs 120a and 120b, over a wired or air interface 115b/116b/117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b/116b/117b may be established using any suitable RAT.
The RRHs 118a, 118b, TRPs 119a, 119b and/or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/116c/117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface 115c/116c/117c may be established using any suitable RAT.
The WTRUs 102 may communicate with one another over a direct air interface 115d/116d/117d, such as Sidelink communication which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface 115d/116d/117d may be established using any suitable RAT.
The communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and/or RSUs 120a and 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, and 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 and/or 115c/116c/117c respectively using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
The base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, and 102g, or RRHs 118a and 118b, TRPs 119a and 119b, and/or RSUs 120a and 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or 115c/116c/117c respectively using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A), for example. The air interface 115/116/117 or 115c/116c/117c may implement 3GPP NR technology. The LTE and LTE-A technology may include LTE D2D and/or V2X technologies and interfaces (such as Sidelink communications, etc.) Similarly, the 3GPP NR technology may include NR V2X technologies and interfaces (such as Sidelink communications, etc.)
The base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a and 118b, TRPs 119a and 119b, and/or RSUs 120a and 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, and 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 114c in
The RAN 103/104/105 and/or RAN 103b/104b/105b may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and/or Voice Over Internet Protocol (VOIP) services to one or more of the WTRUs 102. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
Although not shown in
The core network 106/107/109 may also serve as a gateway for the WTRUs 102 to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the internet protocol (IP) in the TCP/IP internet protocol suite. The other networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 and/or RAN 103b/104b/105b or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102g shown in
Although not shown in
As shown in
The core network 106 shown in
The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c, and traditional land-line communications devices.
The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c, and IP-enabled devices.
The core network 106 may also be connected to the other networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it may be appreciated that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in
The core network 107 shown in
The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.
The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c, and IP-enabled devices.
The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
The RAN 105 may include gNode-Bs 180a and 180b. It may be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and/or digital beamforming technology. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It may also be appreciated the RAN 105 may employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.
The N3IWF 199 may include a non-3GPP Access Point 180c. It may be appreciated that the N3IWF 199 may include any number of non-3GPP Access Points. The non-3GPP Access Point 180c may include one or more transceivers for communicating with the WTRUs 102c over the air interface 198. The non-3GPP Access Point 180c may use the 802.11 protocol to communicate with the WTRU 102c over the air interface 198.
Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in
The core network 109 shown in
In the example of
In the example of
The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive the user plane tunnel configuration information from the SMF via an N11 interface. The AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in
The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for Session Management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.
The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, Other Networks 112 may be Ethernet Networks or any type of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.
The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.
The PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in
The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect to network functions, so that network function can add to, read from, and modify the data that is in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.
The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access of the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and UDM 197 may be tightly integrated.
The AUSF 190 performs authentication related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.
The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface. The NEF may connect to an AF 188 via an N33 interface, and it may connect to other network functions in order to expose the capabilities and services of the 5G core network 109.
Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functions may be via a direct interface or may occur via the NEF 196. The Application Functions 188 may be considered part of the 5G Core Network 109 or may be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.
Network Slicing is a mechanism that may be used by mobile network operators to support one or more ‘virtual’ core networks behind the operator's air interface. This involves ‘slicing’ the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance, and isolation.
3GPP has designed the 5G core network to support Network Slicing. Network Slicing is a useful tool that network operators can use to support the diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) which demand diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.
Referring again to
The core network 109 may facilitate communications with other networks. For example, the core network 109 may include, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, which serves as an interface between the 5G core network 109 and a PSTN 108. For example, the core network 109 may include, or communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and servers or applications functions 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
The core network entities described herein and illustrated in
WTRUS A, B, C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131. In the example of
WTRUS A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to a V2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.
The processor 118 may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While
The transmit/receive element 122 of a UE may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a of
In addition, although the transmit/receive element 122 is depicted in
The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, for example NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.
The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad/indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown).
The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.
The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It may be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method.
The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
The WTRU 102 may be included in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.
In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.
In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
Further, computing system 90 may contain communication circuitry, such as for example a wireless or wired network adapter 97, that may be used to connect computing system 90 to an external communications network or devices, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, WTRUs 102, or Other Networks 112 of
It is understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless and/or wired network communications. Computer readable storage media includes volatile and nonvolatile, removable, and non-removable media implemented in any non-transitory (e.g., tangible, or physical) method or technology for storage of information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information, and which may be accessed by a computing system.
This application claims the benefit of U.S. Provisional Patent Application No. 63/279,730, filed Nov. 16, 2021, which is hereby incorporated by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2022/079977 | 11/16/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63279730 | Nov 2021 | US |
