Shared data channel design

By employing a unified architecture for signal processing and dynamic beamforming technology, the problem of low simultaneous transmission efficiency of URLLC and eMBB traffic in mobile communications has been solved, achieving efficient data channel management and resource utilization.

CN115052350BActive Publication Date: 2025-10-21INTERDIGITAL PATENT HOLDINGS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202210539340.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2017-03-22
Filing Date
2017-11-02
Publication Date
2025-10-21
Estimated Expiration
2037-11-02

AI Technical Summary

Technical Problem

Existing mobile communication technologies struggle to effectively support simultaneous transmission of ultra-reliable low latency (URLLC) and enhanced mobile broadband (eMBB) traffic volumes in data channel design, particularly due to inefficiencies and interference issues in resource allocation and signal processing.

Method used

The uplink and downlink signal processing adopts a unified architecture. By carrying padding bits, hybrid beamforming, waveform selection and multi-user MIMO transmission, URLLC data is inserted and decoded in eMBB transmission. Blind decoding technology is used to identify URLLC resources and perform dynamic beamforming and resource reservation.

Benefits of technology

It improves the latency performance of URLLC data, enhances the transmission efficiency of eMBB and URLLC traffic, reduces resource waste and interference, and enables flexible data channel management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115052350B_ABST
    Figure CN115052350B_ABST
Patent Text Reader

Abstract

Systems, methods, and instrumentalities are disclosed for decoding data. For example, it can be determined whether data received in a previous slot is successfully decoded in a current slot. The data received in the previous slot can be included in a physical downlink shared channel (PDSCH). If the data received in the previous slot is not successfully decoded, pre-emption information can be detected in a first search space. The data received in the previous slot can be decoded using the detected pre-emption information, for example. The pre-emption information can be in the current slot. The pre-emption information can be included in a first DCI. A second search space of the current slot can be searched. For example, the second search space can be searched for a second DCI. The first DCI and the second DCI can be different.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of Chinese patent application No. 201780076557.5, entitled “Shared Data Channel Design”, filed on November 2, 2017, the contents of which are incorporated herein by reference in their entirety.

[0002] Cross-references

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 416,620, filed November 2, 2016; U.S. Provisional Application Serial No. 62 / 443,457, filed January 6, 2017; U.S. Provisional Application Serial No. 62 / 454,425, filed February 3, 2017; and U.S. Provisional Application Serial No. 62 / 474,897, filed March 22, 2017, the contents of which are incorporated herein by reference in their entirety. Background Art

[0004] Mobile communications continue to evolve. The fifth generation may be referred to as 5G. Previous (eg, legacy) generations of mobile communications may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0005] Systems, methods, and tools for sharing data channels are disclosed. Functional blocks and processing flows for 5G data channels can be implemented, for example, using a unified architecture for uplink and downlink. Information can be carried, for example, using filler bits in code blocks. Uplink and downlink signal processing chains can be variable to accommodate various selectable channel codes, ultra-reliable and low latency communication (URLLC) data insertion and traffic prioritization, hybrid beamforming, and waveform selection. Data (e.g., low-latency data, such as URLLC) can be inserted into ongoing transmissions (e.g., low priority, such as eMBB). Low-latency traffic can take over resources allocated to other traffic, for example, through one or more of the following: puncturing, superposition, and multi-user MIMO transmission. Enhanced mobile broadband (eMBB) WTRUs and URLLC WTRUs can perform blind decoding. Uplink unlicensed (e.g., random access) URLLC transmissions can be multiplexed with (e.g., scheduled) uplink eMBB transmissions (e.g., from other WTRUs). Sub-slot MU / SU MIMO switching can be provided.

[0006] Disclosed are systems, methods, and tools for decoding data. For example, a determination may be made in a current time slot as to whether data received in a previous time slot was successfully decoded. The data received in the previous time slot may be included in a physical downlink shared channel (PDSCH). If the data received in the previous time slot was not successfully decoded, preemptive multiplexing information may be detected in a first search space. The data received in the previous time slot may be decoded, for example, using the detected preemptive multiplexing information. The preemptive multiplexing information may be in the current time slot. The preemptive multiplexing information may be included in a first DCI. A second search space of the current time slot may be searched. For example, the second search space may be searched for a second DCI. The first DCI and the second DCI may be different. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is an example of code block segmentation and the addition of information-carrying filler bits;

[0008] Figure 2 is an example structure or format of filler bits in a code block;

[0009] Figure 3 is an example of a DL-SCH channel processing chain;

[0010] Figure 4 is an example of a UL-SCH processing chain (e.g., for a PU-SCH channel);

[0011] Figure 5 is an example of inserting low-latency data (e.g., URLLC) into an ongoing low-priority transmission (e.g., eMBB);

[0012] Figure 6 is an example of periodic in-band control information used to indicate which eMBB resource elements to use for URLLC;

[0013] Figure 7 is an example of blind decoding at an eMBB WTRU;

[0014] Figure 8 is an example of blind decoding at an eMBB WTRU;

[0015] Figure 9 is an example of blind decoding of in-band control information at a URLLC WTRU;

[0016] Figure 10 This is an example of inserting URLLC into eMBB transmission at the eNB / gNB / TRP;

[0017] Figure 11 is an example of dynamically changing analog beamforming when URLLC data insertion occurs;

[0018] Figure 12 This is an example of dynamically changing the total beam when URLLC data insertion occurs;

[0019] Figure 13 This is an example of dynamically changing the total beam when URLLC data insertion occurs. The URLLC beam may not have any digital beamforming.

[0020] Figure 14 is an example of RS positioning using front-loaded RS;

[0021] Figure 15 is an example of using an additional control zone;

[0022] Figure 16 is an example of a URLLC transmission with a boosted power level overlaid with an existing eMBB transmission in the uplink;

[0023] Figure 17 This is an example of a URLLC transmission scheduled in a mini-slot preempting an enhanced mobile broadband (eMBB) transmission scheduled in a normal timeslot.

[0024] Figure 18 is an example of a next-generation Node B (gNB) for processing admission requests from URLLC wireless transmit / receive units (WTRUs);

[0025] Figure 19 is an example of a preemption indication in the presence of a mini-slot;

[0026] Figure 20 is an example of using the offset of a signifier to convey information;

[0027] Figure 21 is an example of mapping bits to resource offsets and resources (e.g., without channel decoding);

[0028] Figure 22 is an example of mapping bits to resource offsets and resources (e.g., using channel coding);

[0029] Figure 23 is an example of preemptive multiplexing information provided in the downlink control information (DCI) of the next time slot;

[0030] Figure 24 is an example of enhanced mobile broadband (eMBB) using multiple search spaces for DCI;

[0031] Figure 25 An example is shown where an eMBB WTRU may search three search spaces;

[0032] Figure 26 is an example of decoding and transmit power for eMBB transmission using URLLC uplink (UL) preemption;

[0033] Figure 27 is an example of URLLC UL transmission using resource reservation and URLLC capability signaling;

[0034] Figure 28 This is an example of UL resource reservation based on URLLC UL load ratio and URLLC performance signaling;

[0035] Figure 29A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0036] Figure 29B It is shown that according to the embodiment, Figure 29A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG.

[0037] Figure 29C It is shown that according to the embodiment, Figure 29A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system shown in FIG.

[0038] Figure 29D It is shown that according to the embodiment, Figure 29A A system diagram of another example RAN and another example CN used within a communication system is shown in FIG. DETAILED DESCRIPTION

[0039] A detailed description of the illustrated embodiments will now be described with reference to the accompanying drawings. While this description provides detailed examples of possible implementations, it should be understood that these details are intended to provide examples and in no way limit the scope of this application. These and other examples may be implemented in their entirety, in part, or in addition to one another. The order shown in the examples may be changed as appropriate.

[0040] 5G can implement various technologies. For example, 5G can implement multiple waveforms for uplink and / or advanced beam management. 5G can be used for Ultra Reliable Low Latency (URLLC). 5G data channels can be different from the data channels used in LTE / LTE-A / LTE-Pro (e.g., the Physical Uplink Shared Channel (PUSCH) and the Physical Downlink Shared Channel (PDSCH)).

[0041] Functional blocks and flows for data channels (e.g., PDSCH and PUSCH) that can support 5G technology can be implemented using a unified architecture for uplink and downlink.

[0042] Information carrying filler bits may be used. For example, information carrying filler bits may be used in a code block.

[0043] In one example (e.g., LTE / LTE-A / LTE Pro), a transport block may be divided into multiple code blocks. The multiple code blocks may have equal sizes. For example, when the transport block size is greater than a threshold Z (e.g., 6144 bits), the transport block may be divided into multiple code blocks of equal size. The size of one or more code blocks may be different from the size of one or more other code blocks. Filler bits may be added to one or more code blocks. For example, filler bits may be added to one or more code blocks to fill the difference to form equal-sized code blocks. The filler bits may be set to NULL (e.g., zero) and / or the filler bits may not carry information. In one example (e.g., eMBB), the code block size may be larger and / or the number of filler bits may be larger (e.g., 6136 bits). Having a large code block size and / or a large number of filler bits wastes resources.

[0044] Figure 1 This is an example of code block segmentation and the addition of information-carrying filler bits. Information-carrying filler bits can be used to protect data and / or enhance control signaling. A CRC can be calculated for a code block containing filler bits. For example, the CRC for a code block containing filler bits can be calculated using one or more (e.g., all) bits in the code block and / or using non-filler bits in the code block.

[0045] like Figure 1 As shown, a transport block 10 may be provided. Transport block 10 may include a cyclic redundancy check (CRC). Transport block 10 may be segmented. For example, transport block 10 may be segmented into one or more code blocks (e.g., code block 1, code block 2, code block M, etc.). A CRC may be added to one or more of the code blocks. For example, a CRC may be added to one or more of code block 1, code block 2, code block M, etc.

[0046] Figure 2 is an example structure (e.g., format) of filler bits in a code block. One or more variables may be used to describe filler bits. For example, filler bits may include a length 202 of the filler bits, a purpose 204 of the filler bits, a payload 206 of the filler bits, and / or a CRC 208 of the filler bits.

[0047] The filler bit cyclic redundancy check (CRC) 208 may be optional. For example, when the code block CRC is calculated using filler bits and / or data bits, the filler bit CRC 208 may not be used.

[0048] The length of filler bits field 202 may indicate the number of bits in the information carrying filler.

[0049] The filler bits' purpose field 204 may provide an indication. For example, the filler bits' purpose field 204 may indicate whether the filler bits' payload 206 is for data protection and / or control enhancement.

[0050] The filler bit payload 206 may be one or more of the following. For example, the filler bit payload 206 may be a repetition of a portion of the code block (e.g., excluding the CRC), which may be used as side information for a channel decoding algorithm that may operate on a systematic code. The filler bit payload 206 may be parity bits for the data portion of the code block (e.g., additional parity bits). The filler bit payload 206 may be control information, such as a modulation and coding scheme (MCS), resource allocation, or channel state information (CSI), and / or feedback for downlink (DL) and / or uplink (UL) transmissions.

[0051] A signal processing chain for a data channel may be performed, for example to support 5G.

[0052] Figure 3 is an example of a downlink shared channel (DL-SCH) channel processing chain. One or more of the following may apply.

[0053] The signal processing chain on the data channel can provide selection of one or more families of channel codes. Channel code families can include Turbo codes, LDPC codes, polar codes, TBCC, etc. The selection criteria can be based on one or more of the following: code block length, bit error rate (BLER) or bit error rate (BER), encoding latency, decoding latency, power consumption, etc. The channel code selection control module can determine the one or more channel codes to be used.

[0054] The URLLC data insertion module may provide priority service to URLLC traffic. For example, the URLLC data insertion module may provide priority service to URLLC traffic in the middle of serving lower priority traffic. Examples of lower priority traffic may include eMMB traffic, mMTC traffic, etc. URLLC traffic may take over resources that have been allocated to eMBB traffic (e.g., frequency and time in the case of truncation) and / or may share resources (e.g., frequency and time in the case of superposition decoding, or space in the case of MU-MIMO between a URLLC WTRU and an eMBB WTRU).

[0055] The digital / analog beamforming control module can control hybrid beamforming (e.g., a combination of digital beamforming (or precoding) and analog beamforming). The digital / analog beamforming control module can perform digital beamforming / precoding, antenna selection, beam searching, and / or analog beamforming, among other things.

[0056] An uplink data channel may be implemented, for example, to support 5G.

[0057] Figure 4 This is an example of a physical uplink shared channel (PUSCH) processing chain. The PUSCH processing chain may be similar to the PDSCH processing chain. The PUSCH chain may have a waveform selection module (e.g., for selecting CP OFDM or DFT-s-OFDM). Decisions (e.g., regarding waveform selection) may be made. This decision may be made by the eNB / gNB. For example, the decision may be based on the WTRU's capabilities and / or coverage requirements.

[0058] The data may be inserted into a data transmission (e.g., an ongoing data transmission). The data may be low-latency data. The data may be preemptively inserted into the ongoing data transmission.

[0059] Figure 5 is an example of inserting low-latency data (e.g., URLLC) into an ongoing low-priority transmission (e.g., eMBB).

[0060] Low-latency data may be URLLC traffic. URLLC traffic may include URLLC data 502. URLLC traffic may have strict latency requirements. Ongoing data transmission may have lower priority traffic and may be eMBB traffic. In one example, the eNB (or gNB) may be transmitting eMBB data. For example, the eNB (or gNB) may be transmitting eMBB data 504 and / or eMBB data 506. URLLC data 502 may use resources that may have been allocated to MBB data (e.g., eMBB data 504). For example, URLLC data 502 may use resources allocated to eMBB data 504 to reduce the latency of URLLC traffic. URLLC data may use resources allocated to eMBB data, for example, to avoid waiting for completion of ongoing eMBB data transmission in the current subframe.

[0061] Low-latency (e.g., URLLC) traffic may use allocated (e.g., eMBB) resources. For example, low-latency (e.g., URLLC) traffic may use allocated (e.g., eMBB) resources by one or more of the following. Low-latency traffic may use allocated resources by puncturing. Pruning may include removing the eMBB signal from the resource region and / or mapping the URLLC signal to the resource region. Low-latency traffic may use allocated resources by superposition. For example, low-latency traffic may use allocated resources by superimposing a URLLC signal on an eMBB signal (or superimposing an eMBB signal on a URLLC signal). Low-latency traffic may use allocated resources by superimposing a URLLC signal on an eMBB signal or superimposing an eMBB signal on a URLLC signal using superposition decoding. Superposition decoding may be performed on a symbol-by-symbol or codeword-by-codeword basis. Low-latency traffic may use allocated resources by multi-user MIMO transmission. MIMO transmission may include transmitting information on one or more analog or digital spatial beams.

[0062] The eMBB WTRU may identify one or more portions of resources used by URLLC traffic. For example, the eMBB WTRU may identify one or more portions of resources used by URLLC traffic to decode eMBB data. The URLLC traffic may puncture one or more portions of the eMBB resources. Puncturing portions of the eMBB resources may introduce erroneous signals at the eMBB receiver. For example, puncturing portions of the eMBB resources may introduce erroneous signals at the eMBB receiver without the URLLC traffic being aware of the location of the punctured eMBB resources, thereby not allowing the eMBB WTRU to decode the eMBB data.

[0063] The URLLC WTRU may identify the location of the URLLC transmission. The control channel may inform the URLLC WTRU of the resource allocation for the URLLC transmission.

[0064] The system can switch between an eMBB directional beam and a beam that can accommodate eMBB transmissions and / or URLLC transmissions within a single transmission time interval. For example, a hybrid beamforming system (e.g., at mmW frequencies where data transmission can be directional) can switch between an eMBB directional beam and a beam that can accommodate eMBB transmissions and / or URLLC transmissions within a single transmission time interval. The simulated beam can be wideband across the transmission channel bandwidth. For example, the simulated beam can be wideband across the entire transmission channel bandwidth.

[0065] The eMBB WTRU and / or URLLC WTRU may perform blind decoding. For example, the eMBB WTRU and / or URLLC WTRU may perform blind decoding for DL ​​transmission of eMBB data and / or URLLC data. The eMBB WTRU may use blind decoding to determine the portion of resources that may be allocated to the eMBB WTRU that are already being used by URLLC traffic.

[0066] One or more (e.g., all) WTRUs and / or gNBs may be aware of one or more resource regions. Resource regions may be reserved for the transmission of in-band control information. For example, when URLLC traffic is present, resource regions may be reserved for the transmission of in-band control information.

[0067] The resources that can be used for potential in-band signaling can follow a pattern. The pattern can be known to the transmitter and / or receiver. The pattern can be periodic or pseudo-random. Figure 6 is an example of periodic in-band control information. Periodic in-band control information may be used to indicate which eMBB resource elements may be used by URLLC. The gNB may use a sequence of resource regions to send in-band control information to the URLLC WTRU. The sequence of resource regions used by the gNB for sending in-band control information to the URLLC WTRU may be represented as 604. The URLLC WTRU may listen for URLLC control information (e.g., possible URLLC control information) in the resource regions. If URLLC traffic arrives, one or more of the resource regions may be activated. The activated resource regions may be represented as 606. If URLLC traffic does not arrive, the resource regions may not be activated and / or may be used for eMBB transmission.

[0068] The eMBB WTRU may decode the data. For example, the eMBB WTRU may decode the data without regard to the presence of URLLC data. The eMBB WTRU may trigger a search for in-band control information. For example, the eMBB WTRU may trigger a search for in-band control information upon a decoding failure. The search may incur a processing time overhead. The overhead may be limited. For example, the overhead may be limited when the URLLC traffic is dispersed and / or the channel conditions (e.g., no preemptive URLLC transmission) are benign.

[0069] Figure 7 is an example of eMBB WTRU blind decoding. One or more of the following may be performed.

[0070] At 702, the eMBB WTRU may receive eMBB data. The eMBB WTRU may (e.g., may first) attempt to decode the eMBB data. For example, at 704, the eMBB WTRU may perform channel decoding (e.g., normal channel decoding). The eMBB WTRU may (e.g., may first) attempt to decode the eMBB data without determining whether URLLC traffic is present. URLLC traffic may be added to the eMBB transmission by puncturing, superimposing, and / or another feature.

[0071] At 706, it may be determined whether the decoding is successful. If the decoding is successful, then the eMBB data reception may be complete.

[0072] The eMBB decoding may be unsuccessful (e.g., may fail). For example, unsuccessful (e.g., failed) eMBB decoding may result in a determination (e.g., determined by the eMBB WTRU) as to whether the failure was due to the presence of URLLC data. The eMBB WTRU may perform a determination as to whether the failure was due to the presence of URLLC data. At 708, if the eMBB decoding is unsuccessful, the eMBB WTRU may search the in-band control information area. For example, the eMBB WTRU may search the in-band control information area in the resource grid for in-band control information (e.g., possible in-band control information). The in-band control information area may include a number (e.g., a fixed number) of resource elements. The in-band control information area may use a predefined MCS. The in-band control information may include a CRC calculated using the in-band control information and / or an identifier (e.g., RNTI) of the eMBB WTRU, which allows the eMBB WTRU to determine whether the eMBB decoded the in-band control information correctly. One or more factors may be used to determine successful decoding. For example, decoding may be determined to be successful when a CRC check is passed.

[0073] At 710, a determination may be made as to whether in-band control information has been found. At 712, if in-band control information is not found, eMBB reception may be determined to have failed. If in-band control information is not found, one or more other actions may be continued. For example, if in-band control information is not found, HARQ may be continued.

[0074] The eMBB WTRU may locate (e.g., identify) in-band control information. The eMBB WTRU may follow instructions provided by the in-band control information. For example, at 714, if the in-band control information is found, the eMBB WTRU may follow instructions provided by the in-band control information to locate resource elements that may be used by URLLC traffic. The eMBB WTRU may identify one or more types of features provided and / or used. For example, the eMBB WTRU may identify puncturing, overlay, multi-user MIMO, etc.

[0075] At 716, the eMBB WTRU may separate the URLLC transmission and the eMBB transmission. The eMBB WTRU may decode the eMBB data. The eMBB WTRU may skip punctured portions of the eMBB signal. For example, for punctures, the eMBB WTRU may skip punctured portions of the eMBB signal. The eMBB WTRU may recover the eMBB data symbols on the resource grid used by the URLLC traffic. For example, for overlay decoding, the eMBB WTRU may recover the eMBB data symbols on the resource grid used by the URLLC traffic. The recovery may be performed on one or more bases. For example, the recovery may be performed on a per-symbol basis and / or on a per-codeword basis.

[0076] Other features may be used to perform blind decoding. For example, one or more features having the same or different streams and / or orders may be used to perform blind decoding.

[0077] Figure 8 is an example of eMBB WTRU blind decoding. One or more of the following may be performed.

[0078] For example, there may be a large amount of URLLC traffic. The eMBB receiver may perform one or more (e.g., different) decoding orders. For example, the eMBB receiver may perform one or more (e.g., different) decoding orders by selecting from one or more (e.g., one or more different) decodings and / or by reordering features.

[0079] The eMBB receiver may perform blind decoding of in-band control information. For example, the eMBB receiver may perform blind decoding of in-band control information before or instead of blind decoding of eMBB data. At 802, the eMBB WTRU may receive eMBB data. At 804, the eMBB WTRU may search for in-band control information. At 806, the eMBB WTRU may determine whether the in-band control information is found.

[0080] At 808, the eMBB receiver may locate the in-band control information. The eMBB receiver may follow instructions that may be provided by the in-band control information. For example, at 808, the eMBB receiver may follow instructions that may be provided by the in-band control information to locate resource elements that may be used by URLLC and / or identify one or more types of features that are provided and / or used. The features may include one or more of puncturing, overlay, multi-user MIMO, etc. The eMBB WTRU may separate the URLLC transmission and the eMBB transmission. The eMBB WTRU may decode the eMBB data. At 810, the eMBB receiver may separate the URLLC transmission and / or the eMBB transmission. The eMBB receiver may decode the eMBB data.

[0081] At 812, for example, if the eMBB receiver does not find the in-band control information, it may perform channel decoding (e.g., normal channel decoding). At 814, it may be determined whether the decoding was successful. At 816, for example, if the decoding was unsuccessful, it may be determined that the eMBB reception failed. The eMBB receiver may continue with one or more other actions (e.g., HARQ, etc.).

[0082] The eMBB receiver may determine whether to perform blind decoding of in-band control channels. For example, the eMBB receiver may determine whether to perform blind decoding of in-band control channels for URLLC and / or eMBB data. The receiver may track URLLC insertion statistics. The receiver may switch at a predefined threshold.

[0083] The TRP may reserve a specific area in (e.g., each) scheduling interval. For example, the TRP may reserve a portion of in-band control information in (e.g., each) scheduling interval. The TRP may send a signal indicating the presence of URLLC insertion. The receiver may check for the indication. For example, the receiver may check for the indication before starting reception.

[0084] Figure 9 is an example of a URLLC WTRU blindly decoding in-band control information. One or more of the following may be performed.

[0085] The URLLC receiver may listen (e.g., may continuously listen) for resource elements. For example, at 902, the URLLC receiver may tune to an in-band control signaling resource (e.g., a potential in-band control signaling resource). The URLLC receiver may listen for resource elements that may be allocated for in-band control information. At 904, it may be determined whether in-band information has been found. The URLLC receiver may find in-band control information. At 906, if in-band information is found, the URLLC data is decoded. If no in-band information is found, then at 902, the URLLC receiver is tuned to a potential in-band control signaling resource.

[0086] The URLLC receiver can follow the information. For example, the URLLC receiver can locate resource elements and / or determine how to receive URLLC data according to the information. The URLLC receiver can use superposition decoding to receive URLLC data.

[0087] Figure 10 This is an example of the eNB / gNB / TRP inserting URLLC into the eMBB transmission. One or more of the following may be performed.

[0088] At 1002, eMBB data may be prepared and / or one or more resources may be mapped. Transmission may begin. At 1004, it may be determined whether URLLC traffic has arrived. At 1006, for example, if URLLC traffic has not arrived, a timeout may be waited for.

[0089] At 1008, if URLLC traffic has arrived, a determination is made as to whether the eMBB transmission is complete. At 1010, if the eMBB transmission is not yet complete, the eNB / gNB / TRP may perform URLLC data insertion. For example, the eNB / gNB / TRP may perform URLLC data insertion when URLLC traffic arrives during an ongoing eMBB transmission. In-band control information may be added and / or precoding may be changed. At 1012, if the eMBB transmission is complete, URLLC control information may be sent. URLLC data may be transmitted. Precoding may be changed.

[0090] Beamforming may be directed (e.g., may be directed only) to the eMBB WTRU. For example, beamforming may be directed (e.g., may be directed only) to the eMBB WTRU when the eNB / gNB / TRP transmits eMBB data (e.g., only eMBB data). A beam may cover multiple (e.g., two) WTRUs. For example, a beam may cover multiple (e.g., two) WTRUs when the eNB / gNB / TRP transmits (e.g., transmits simultaneously) to both an eMBB WTRU and a URLLC WTRU. The eNB / gNB / TRP may change the beamforming.

[0091] Beamforming may include one or more parts. For example, beamforming may include digital beamforming and / or analog beamforming. Analog beams may be configured to different sizes. For example, analog beams may be configured to be wide. Analog beams may be configured to be wide to cover multiple WTRUs. The eNB / gNB / TRP may form digital beams (e.g., separate digital beams). The eNB / gNB / TRP may form digital beams to multiple WTRUs. The WTRU may identify an aggregate beam. For example, the aggregate beam identified by the WTRU may be the product of an analog beam modulated by a digital beam. Multiple WTRUs may be covered. Multiple WTRUs may be covered without sacrificing energy efficiency.

[0092] Downlink beamforming with URLLC can be performed. Hybrid beamforming can provide increased frequency transmission. Hybrid beamforming can combine analog RF beamformers and digital baseband beamformers.

[0093] The transmitted signal can be described by Equation 1:

[0094] x=B 模拟 B数字 s Equation 1

[0095] Among them B 模拟 It can be an analog beamforming matrix, B 数字 may be a digital beamforming matrix, and / or s may be an information vector.

[0096] The eNB / gNB may change the analog beamforming. For example, the eNB / gNB may change the analog beamforming when URLLC data insertion occurs. The eNB / gNB may change the analog beamforming when URLLC data insertion occurs so that the analog beamforming can cover the eMBB WTRU and / or URLLC WTRU.

[0097] Figure 11 is an example of dynamically changing analog beamforming when URLLC data insertion occurs.

[0098] In the example (e.g., Figure 11 As shown), the ellipse can represent the simulated beam B 模拟 For example, analog beams may be formed over time. For example, analog beams may be formed dynamically over time. The eNB / gNB may apply different precoders (e.g., digital beamforming) to multiple WTRUs (e.g., eMBB WTRUs and URLLC WTRUs). For example, the eNB / gNB may apply different precoders to multiple WTRUs so that the total beam may point in different directions. For example, a beam (e.g., a total beam) may point to a URLLC WTRU and / or another beam (e.g., another total beam) may point to an eMBB WTRU. The total beam may be composed of analog beams (e.g., Figure 11 ) and / or digital or baseband beamforming.

[0099] Figure 12 is an example of dynamically changing the total beam when URLLC data insertion occurs.

[0100] In the example (e.g., Figure 12 As shown), the ellipse may represent the total beam B formed over time (eg, dynamically formed). 模拟 B 数字 .

[0101] Figure 13 is an example of dynamically changing the total beam when URLLC data insertion occurs. Figure 13 As shown, the URLLC WTRU may use (e.g., may only use) analog beams. For example, the URLLC WTRU may use (e.g., may only use) analog beams to reduce the need for feedback. The URLLC beams may not have digital beamforming.

[0102] Analog beam switching may embody one or more implementation choices. For example, analog beam switching may embody one or more implementation choices related to beam scanning, digital precoding feedback, blind decoding, and / or reference symbols.

[0103] For beam scanning, (e.g., each) WTRU may (e.g., may need to) identify multiple simulated beams. For example, during L1 / L2 beam management (e.g., each) WTRU may (e.g., may need to) identify multiple simulated beams. L1 / L2 beam management may include beam searching. For (e.g., each) predefined traffic type, the WTRU may perform beam management and / or may identify predefined simulated uplink / downlink beam pairs. In an example (e.g., Figure 11-13 In the example shown in FIG, simulated beam 1 can be an eMBB beam and / or simulated beam 2 can be a URLLC insertion beam for eMBB and URLLC transmission. The results obtained from P-1 level beam management (e.g., coarse beam scanning) can be used for URLLC transmission / reception. The results obtained from P-2 / P-3 beam management (e.g., beam refinement) can be used for eMBB transmission.

[0104] For digital precoding feedback, (e.g., each) WTRU may (e.g., may need to) send feedback required for a digital baseband precoder for (e.g., each) analog beam type. Sending feedback required for a digital baseband precoder for (e.g., each) analog beam type may involve feedback for (e.g., each) precoder (e.g., separate feedback). One or more parameters may (e.g., may also) be provided. The one or more parameters may include MCS supportable and / or transmit power. For eMBB WTRUs, one or more feedback may be required (e.g., may only be required). For example, for non-precoded URLLC (e.g., such as Figure 13 (as shown in ) the eMBB WTRU may require (eg, may only require) one or more feedbacks.

[0105] Precoder changes may be considered in blind decoding. Signaling (e.g., explicit signaling) may be used. For example, signaling (e.g., explicit signaling) may be used to reduce the complexity of blind decoding. Signaling (e.g., explicit signaling) may be used to reduce the complexity of blind decoding when one or more eMBB (e.g., single eMBB) transmissions are affected by URLLC traffic.

[0106] Reference symbols (RS) may be modified. For example, reference symbols may be modified to account for beam changes. RS signals may be used (e.g., may be required). For example, RS signals may be used (e.g., may be required) when there is a beam and / or traffic type switch. RS1 may be the RS for eMBB beam 1. RS2 may be the RS for eMBB beam 2 and / or URLLC beam 2. RS3 may be the RS for URLLC in-band control. RS signals (e.g., without beamforming) may be used for in-band control information. For example, if the URLLC WTRU and / or eMBB WTRU can (e.g., must) decode in-band control information, RS signals (e.g., without beamforming) may be used for in-band control information. Figure 14 This is an example of RS positioning using front-loaded RS. In this example (e.g., front-loaded RS signals), the eMBB WTRU may use additional RS signals during (e.g., the first) beam switch and not after (e.g., the first) beam switch. The RS signals may be used for active URLLC control and / or data regions.

[0107] The TRP may be configured (e.g., statically and / or dynamically). For example, the TRP may be configured (e.g., statically and / or dynamically) to allow or deny URLLC transmissions. The configuration of no URLLC transmission may disable one or more traffic scans, blind decoding, and / or reference symbol changes.

[0108] One or more control regions may be used. The one or more control regions may follow a pattern that is known to the eNB / gNB / TRP and the WTRU. The pattern may be periodic or pseudo-random. Figure 15

[0066] This is an example of using an additional control region. A potential control region may be allocated. For example, a potential control region may be allocated to notify URLLC WTRUs and eMBB WTRUs of URLLC data insertion.

[0109] The device may provide uplink hybrid URLLC-eMBB transmission. The PHY layer of the WTRU may receive URLLC data. For example, the PHY layer of the WTRU may receive URLLC data sent from the application layer of the WTRU. When the WTRU is transmitting eMBB data or mMTC data, the PHY layer of the WTRU may receive URLLC data sent from the application layer of the WTRU for uplink transmission. The WTRU may insert URLLC data into the transmission of eMBB data (e.g., an ongoing transmission). For example, the WTRU may insert URLLC data into the ongoing transmission of eMBB data to reduce the waiting time of the serving URLLC data.

[0110] A downlink transmission may be applicable to (eg, used for) an uplink transmission.

[0111] The receive beam at the eNB / gNB / TRP may be switched to a URLLC analog beam. For example, the receive beam at the eNB / gNB / TRP may be switched to a URLLC analog beam for the duration of a determined possible reception period of uplink URLLC traffic.

[0112] Uplink ungranted (e.g., random access) URLLC transmissions may be multiplexed. For example, uplink ungranted (e.g., random access) URLLC transmissions may be multiplexed with (e.g., scheduled) uplink eMBB transmissions (e.g., from other WTRUs). The eMBB uplink transmission(s) may be (e.g., may have been) scheduled. For example, the eMBB uplink transmission may be a grant-based transmission. The WTRU may transmit (e.g., may need to transmit) a URLLC packet without a grant from the eNB / gNB and / or without knowledge of a scheduled uplink transmission from the eMBB WTRU. The URLLC uplink transmission may be performed in a time / frequency zone (e.g., a portion of a time / frequency zone). For example, the URLLC uplink transmission may be performed in a time / frequency zone (e.g., a portion of a time / frequency zone) designated for uplink eMBB transmissions. The eNB / gNB may detect (e.g., blindly detect) the URLLC WTRU and / or may separate the data of the URLLC WTRU from the data of the scheduled eMBB WTRU.

[0113] Figure 16 This is an example of a URLLC transmission with an increased power level that overlaps with an existing eMBB transmission in the uplink. The URLLC transmission may overlap an mMTC resource region. The frequency range may be divided into multiple (e.g., two) frequency bands. For example, the frequency range may be divided into a frequency band for eMBB and a frequency band for mMTC.

[0114] (e.g., each) URLLC WTRU may be assigned a subset (e.g., a small subset) of the zone that may be assigned for eMBB transmission. A sub-zone (e.g., a small sub-zone) may be a portion of a time slot / frame on a frequency sub-band (e.g., a small frequency sub-band). In a sub-zone (e.g., a small sub-zone), the URLLC WTRU may boost the power of the URLLC WTRU. For example, the URLLC WTRU may boost the power of the URLLC WTRU to overwhelm the power of uplink transmissions from possible scheduled eMBB WTRUs. In an example, the transmit power of the eMBB transmission in the sub-zone may be reduced by a factor of X dB (e.g., X=10 dB). The transmit power of the eMBB transmission in the sub-zone may be reduced by a factor of X dB so that the URLLC power can overwhelm the eMBB power. The URLLC WTRU may not boost the power of the URLLC WTRU. The eMBB WTRU may use a reduced channel decoding rate to make the transmission of the eMBB WTRU more robust. A receiver (e.g., a receiver at an eNB / gNB) may detect transmissions from URLLC users. For example, the receiver (e.g., a receiver at an eNB / gNB) may detect transmissions from URLLC users by detecting high power density in a particular sub-zone of the WTRU and / or may use successive interference cancellation (SIC) to detect data from the URLLC WTRU, remove data from the URLLC WTRU, and / or detect eMBB data.

[0115] In an example, low-rate CDMA technology can be used. For example, low-rate CDMA technology can be used to spread the data of a URLLC user to a zone (e.g., part or all of a zone). Low-rate CDMA technology can be used to spread the data of a URLLC user to a zone (e.g., part or all of a zone) based on a signature assigned to the URLLC user. The decoding-based spreading can be in frequency (e.g., to limit latency) or in frequency and time. A receiver (e.g., at an eNB / gNB) can monitor (e.g., blindly monitor) CDMA transmissions. For example, a receiver (e.g., at an eNB / gNB) can monitor (e.g., blindly monitor) CDMA transmissions using different signatures (e.g., corresponding to different potential URLLC uplink transmissions) and / or can detect (e.g., blindly detect) URLLC users. The receiver can use successive interference cancellation (SIC) to detect its data, remove data, and / or detect eMBB data.

[0116] The gNB may indicate resources that are safe to use. For example, the gNB may indicate resources that are safe to use to prevent preemptive UL URLLC transmissions from interrupting transmission of resources allocated for certain purposes (e.g., critical purposes such as UL DMRS and / or other URLLC UL transmissions). The resources may include unallocated resources and / or resources allocated for eMBB.

[0117] The gNB may aggregate (e.g., combine) unallocated resources and / or resources allocated to one or more (e.g., all) eMBB WTRUs. For example, to limit signaling overhead, the gNB may aggregate (e.g., combine) unallocated resources and resources allocated to one or more (e.g., all) eMBB WTRUs. The gNB may select a subset of resources and / or provide a descriptor for the subset. The gNB may specify a maximum power boost factor Y dB to limit the interference generated by URLLC WTRUs (e.g., Y = 23).

[0118] The gNB may send information about a subset of resources in a common search space in downlink control information (DCI). For example, to limit signaling overhead, the gNB may send information about a subset of resources in a common search space in the DCI. URLLC WTRUs (e.g., all URLLC WTRUs) may read the information in the common search space. For example, URLLC WTRUs (e.g., all URLLC WTRUs) may read the information in the common search space to avoid signaling overhead associated with sending information individually to the URLLC WTRUs. In an example, the common search space may be used for one or more (e.g., all) WTRUs.

[0119] The URLLC WTRU may search a search space in the DCI. For example, the URLLC WTRU may search a common search space in the DCI. The URLLC WTRU may identify resources on which the URLLC WTRU may be overlaid. The URLLC WTRU may increase the transmit (TX) power of the URLLC WTRU. For example, the URLLC WTRU may increase the TX power of the URLLC WTRU by X dB (e.g., X=20), where X≤Y.

[0120] Uplink eMBB and license-based URLLC multiple access can be provided. In the uplink, eMBB transmissions can use normal slots. Normal slots can be M OFDM symbols long, where M can be an integer. URLLC transmissions can use mini slots. For example, URLLC transmissions can use mini slots to achieve shorter latency. Mini slots can be N OFDM symbols long, where N can be an integer and / or N <M。

[0121] Canceling a grant and / or transmission may be costly. For example, if the gNB schedules resources for an eMBB WTRU to use for an UL transmission, then cancelling a grant and / or transmission may be costly. Canceling may be achieved if the eMBB WTRU monitors transmissions from the gNB in ​​the DL during one or more (e.g., every) mini-slots. Monitoring may increase the energy consumption of the eMBB WTRU.

[0122] If a URLLC WTRU requests a grant for UL transmission and the grant arrives after some eMBB WTRUs are scheduled, it is advantageous (eg, advantageous for the URLLC WTRU) to transmit on the resources allocated for eMBB transmission (eg, preemptively transmit). Figure 17 This is an example of a URLLC transmission scheduled on a mini-timeslot preempting an eMBB transmission scheduled on a normal time slot. Figure 17 , M = 7 and N = 3. The URLLC WTRU and the eMBB WTRU may transmit in three OFDM symbols (eg, transmit simultaneously).

[0123] Figure 18 is an example of a gNB handling a grant request from a URLLC WTRU. Figure 18 In

[15] , the gNB may perform resource allocation that may allow preemptive URLLC transmissions.

[0124] At 1802, a URLLC WTRU may request an UL grant. At 1804, a determination may be made as to whether sufficient unallocated resources are available. For example, the gNB may determine whether sufficient unallocated resources are available for the URLLC WTRU. At 1806, for example, if sufficient unallocated resources are available, the gNB may allocate the unallocated resources to the URLLC WTRU. At 1808, a grant may be sent to the URLLC WTRU. At 1810, for example, if sufficient unallocated resources are available, the gNB may allocate the unallocated resources and / or resources already allocated to the eMBB WTRU. For example, the gNB may allocate the unallocated resources and / or resources already allocated to the eMBB WTRU to the URLLC WTRU. At 1812, a grant may be sent. In the grant, the gNB may specify a configuration (e.g., a configuration for eMBB resources) to the URLLC WTRU. The gNB may specify a configuration (e.g., a configuration for eMBB resources) to the URLLC WTRU to allow a preemptive transmission (e.g., a valid preemptive transmission) from the URLLC WTRU.

[0125] Preemptive transmission may be achieved through power boosting. For example, the gNB may instruct the URLLC WTRU to boost the transmit power of the URLLC WTRU. The gNB may instruct the URLLC WTRU to boost the transmit power of the URLLC WTRU to perform overlay on a scheduled eMBB transmission. The gNB may perform successive interference cancellation (SIC) on the received overlaid signal. For example, the gNB may perform successive interference cancellation (SIC) on the received overlaid signal to separate the URLLC signal and the eMBB signal. The gNB may send a power control command. For example, the gNB may send a power control command to request the URLLC WTRU to boost power by X dB (e.g., X=20). The value of X may be determined based on one or more of: the received power of the eMBB transmission, the path loss of the URLLC WTRU, and / or considerations for controlling interference caused by the URLLC WTRU to other WTRUs or nearby cells. The gNB may include the suggested power boost factor in the grant. The URLLC WTRU may increase the transmit power of the URLLC WTRU by a factor of X dB.

[0126] The gNB may send an indication in the DCI. For example, the gNB may send an indication in the DCI to the URLLC WTRU to indicate that the resources allocated to the URLLC WTRU are being used for eMBB transmission. The URLLC WTRU may determine a power boost factor for the URLLC WTRU. For example, the URLLC WTRU may determine a power boost factor for the URLLC WTRU based on information such as its remaining battery energy level, path loss, and / or interference.

[0127] The gNB may send a precoding matrix index (PMI) to the URLLC WTRU. For example, the gNB may send a precoding matrix index (PMI) to the URLLC WTRU so that the URLLC transmission and the eMBB transmission may be in orthogonal subspaces at the gNB. The URLLC WTRU may apply the precoding indicated by the PMI for the URLLC WTRU's UL transmission.

[0128] Sub-slot MU / SU MIMO switching may be performed. The eNB / gNB / TRP may precode multiple (e.g., two) transmissions in an orthogonal manner. For example, the eNB / gNB / TRP may precode multiple (e.g., two) transmissions in an orthogonal manner to ensure that the eMBB transmission is orthogonal to the URLLC transmission. The channel from the eNB / gNB / TRP to the URLLC WTRU may be H1, and / or the channel from the eNB / gNB / TRP to the eMBB WTRU may be H2. Precoders (digital beamforming matrices) V1 and V2 may be selected for the URLLC WTRU and the eMBB WTRU, respectively. An analog beamforming matrix (e.g., a generic analog beamforming matrix) B may be selected. For example, the analog beamforming matrix (e.g., a generic analog beamforming matrix) B may be selected such that (H1BV1) T H1BV2=0, where the column space of H1BV1 and the column space of H1BV2 may be orthogonal. The URLLC WTRU may extract the desired signal of the URLLC WTRU. For example, the URLLC WTRU may extract the desired signal of the URLLC WTRU by projecting the received signal y1 into the subspace covered by H1BV1. The received signal may be given, for example, by Equation 2:

[0129] y1=H1B(V1s1+V2s2) Equation 2

[0130] Different (e.g., two different) analog beamforming matrices B1 and B2 can be created. For example, different (e.g., two different) analog beamforming matrices B1 and B2 can be created so that H1B1 can be orthogonal to H1B1. Precoders V1 and V2 can be selected. For example, precoders V1 and V2 can be selected to maximize other criteria. Precoders V1 and V2 can be selected to maximize other criteria without considering the constraint that the column space of H1B1V1 is orthogonal to the column space of H1B2V2. Orthogonality between H1B1 and H1B1 can ensure orthogonality between H1B1V1 and H1B2V2.

[0131] The selection of the precoding matrix and the beamforming matrix may be targeted at optimizing the performance of both the URLLC WTRU and the eMBB WTRU. Weights (e.g., different weights) may be applied to the objective functions. The overall objective function may be a linear combination of the two objective functions for each of the two WTRUs, e.g., according to Equation 3.

[0132]

[0133] where α can be a weight ranging from 0 to 1 and / or can be the complex conjugate transpose operator and / or ‖‖ can be the Frobenius norm.

[0134] The eNB / gNB / TRP may use the channel state information and / or handle the lack of channel state information in one or more (e.g., one or more different) ways, which may include one or more of the following. For example, the eNB / gNB / TRP may use the channel state information obtained from the WTRU in a time slot (e.g., the previous time slot). The eNB / gNB / TRP may use a transmit diversity scheme, such as cyclic delay diversity (CDD). For example, when the channel state information is not available, the eNB / gNB / TRP may use a transmit diversity scheme, such as cyclic delay diversity (CDD). The eNB / gNB / TRP may initiate channel measurements and CSI feedback from the URLLC WTRU. Initiating channel measurements and CSI feedback from the URLLC WTRU may improve the quality of CSI measurements and may transition to better performance. When the URLLC traffic is predictable (e.g., arrives periodically), the eNB / gNB / TRP may initiate channel measurements and CSI feedback from the URLLC WTRU.

[0135] Signaling can be provided for URLLC and eMBB multiplexing. Mini-slots can be used to provide multi-granularity indication. Mini-slots can be used for URLLC as the smallest scheduling resource unit. For example, mini-slots can be used for URLLC as the smallest scheduling resource unit in the time domain. A normal time slot can be X OFDM symbols. A mini-slot can be Y OFDM symbols, where Y < X (e.g., X = 7 and Y = 2). For example, for a 7-symbol time slot, Y ∈ {1, 2, …, 6}, and for a 14-symbol time slot, Y ∈ {1, 2, …, 13}. When the URLLC traffic is multiplexed (e.g., pre-emptively multiplexed) with an eMBB transmission (e.g., an ongoing eMBB transmission), the URLLC traffic may occupy (e.g., may need to occupy, e.g., only occupy) a portion of the normal time slot. The URLLC traffic that occupies (e.g., may need to occupy, e.g., only occupy) a portion of the normal time slot may leave resources (e.g., remaining resources) in the normal time slot.

[0136] Figure 19This is an example of a preemption indication when mini-slots are present. Preemption resources may be within the current normal slot and / or may be outside of and into the next normal slot. For example, if URLLC data cannot be served (e.g., fully served) in the current normal slot, preemption resources may be within the current normal slot and / or may be outside of the current normal slot and into the next normal slot. The gNB may be able (e.g., may need to be able) to describe resource usage at the mini-slot level. For example, the gNB may be able (e.g., may need to be able) to describe resource usage at the mini-slot level to enable the eMBB WTRU to use the remaining resources. The gNB may be able (e.g., may need to be able) to describe resource usage at multiple mini-slot levels (e.g., not just at the normal slot level). The smallest scheduled resource unit in the frequency domain may be (e.g., one) RB. URLLC traffic may be multiplexed in the frequency domain across one RB, multiple RBs, and / or subbands.

[0137] The indication may be at the end of a time slot (e.g., the current normal time slot). Figure 19 The indicator rectangle indicated by the slashed line indicates that the indicator may be at the end of the time slot (e.g., the current normal time slot). The indicator may provide one or more of the following information. The indicator may provide information about the existence of URLLC data packet transmission. The indicator may provide information about the affected normal time slot. For example, the current normal time slot may be assigned the number 0, the next normal time slot may be assigned the number 1, and so on. The indicator may provide information about the mini-time slot time unit. The mini-time slot time unit may be a multiple of an OFDM symbol. For (e.g., each) normal time slot, the indicator may provide information about one or more of the following. For (e.g., each) normal time slot, the indicator may provide information about the start time of the first mini-time slot used by the URLLC traffic. The start time may be a multiple of an OFDM symbol. For example, the start time may be a multiple of an OFDM symbol and / or may be measured from the start time of the current normal time slot. For (e.g., each) normal time slot, the indicator may provide information about the end time of the analog time slot in the current normal time slot. For (e.g., each) normal slot, the indicator may provide information about the number of mini-slots. For example, if multiple mini-slots are scheduled, the indicator may provide information about the number of mini-slots. For (e.g., each) normal slot, the indicator may provide information about the starting frequency and / or ending frequency within the current normal slot. The frequency may be a multiple of a frequency unit. For example, the frequency may be a multiple of a resource element, a resource block (RB), and / or a resource block (RB) group.

[0138] Hybrid signaling with a CRC (cyclic redundancy check) may be performed. An indication (e.g., an indication as a whole) may be explicitly represented by modulating a subset of resources. The selection of resources may convey information and / or may provide explicit signaling. CRC check bits may be included in the indication. For example, the CRC check bits may be included in the indication to enable the eMBB WTRU to determine whether the eMBB WTRU has received the indication (e.g., a correct indication). The CRC check bits may take into account additional information. For example, the CRC check bits may take into account additional information by using resource selection to convey the additional information.

[0139] Figure 20 This is an example of using an offset of an indicator to convey information. For example, the offset of the indicator in frequency can indicate resource selection. The offset can be the difference between a reference frequency (e.g., the lower frequency of the frequency band under consideration) and the starting frequency of the indicator. The offset can be a multiple of the base frequency unit. For example, the offset can be a multiple of 15 kHz. The length of the indicator can be fixed.

[0140] The indicator offset can be 2 M There may be L message bits and / or K CRC bits. A portion of the L+K bits may be mapped to the offset. The remaining bits may be used for modulation resources.

[0141] Figure 21 is an example of mapping bits to resource offsets and resources, for example without channel coding. M ) can be mapped to the offset of the indicator. The remaining bits (eg, bit b M+1 ,…,b L ,c1…,c K ) can be mapped to a resource and / or a signal on a resource can be determined. The CRC can be calculated using the bits carried by the modulated signal on the selected resource and / or the bits conveyed by the offset. For example, (c1, ..., c K )=f(b1,b2,…,b M ,b M+1 ,…,b L ,), where f() can be a function to construct CRC bits. If the RNTI has less than f(b1,b2,…,b M ,b M+1 ,…,b L ,), then the bits of (c1,…,c K )=f(b1,b2,…,b M ,b M+1 ,…,b L,)XOR R to construct a CRC, where R can be an extended RNTI (Radio Network Temporary Identifier) ​​by adding zeros as a prefix to the RNTI.

[0142] The eMBB WTRU may try values ​​of the offset (e.g., possible values). For example, when receiving and / or processing a DL transmission, the eMBB WTRU may try values ​​of the offset (e.g., possible values) and / or may use an inverse mapping to obtain the corresponding bits b1, b2, ..., b M The eMBB WTRU may process the resources. The eMBB WTRU may obtain the bit b M+1 ,…,b L ,c1,…,c K The eMBB WTRU can check b1, b2, ..., b M with b M+1 ,…,b L Does it give the correct CRC bits (c1,…,c K For example, without using extended RNTI, the eMBB WTRU may check b1, b2, ..., b M with b M+1 ,…,b L Does it give the correct CRC bits (c1,…,c K ). The eMBB WTRU may check b1, b2, …, b M with b M+1 ,…,b L For example, in the case of using extended RNTI, the eMBB WTRU may check b1, b2, ..., b M with b M+1 ,…,b L Also, whether to provide extended RNTI.

[0143] The indicator information may be channel-coded. For example, the indicator information and the CRC may be channel-coded. The indicator information and the CRC may be channel-coded to prevent channel errors. The channel-coded bits may represent an offset and / or may be communicated (e.g., implicitly). For example, the first M bits of the channel-coded bits may represent an offset and / or may be communicated (e.g., implicitly). The remaining bits may be transmitted (e.g., explicitly) by modulating the selected time-frequency resource.

[0144] Figure 22 is an example of using channel coding to map bits to resource offsets and resources. Channel coding can be used to encode information bits b1, ..., b L and CRC bits c1,…,c k The output can be N bits: d1,…,dN Of these N bits, the first M bits d1, d2, ..., d M The CRC bits may be mapped to an offset of the indicator. The remaining NM bits may be mapped to the allocated time-frequency resources. If the channel coding has parity check capability, the CRC bits may be removed (e.g., to save resources). For example, if the channel decoding has parity check capability, such as LDPC code, the CRC bits may be removed, for example, to save resources.

[0145] An indicator may be sent in the downlink. For example, an indicator may be sent in the downlink to ensure that the eMBB and / or URLLC receiver is aware that eMBB data may be preempted (e.g., by puncturing and / or by superposition). The indicator may add overhead to the system and / or may result in poor performance. For example, if not correctly decoded, the indicator may add overhead to the system and / or may result in poor performance. A semi-persistent URLLC indication may be provided. In situations where persistent URLLC data insertion is possible and / or where a URLLC transmission (e.g., a specific URLLC transmission) may be transmitted on one or more time resources (e.g., time slots / mini-time slots), a semi-persistent URLLC indicator may be used to indicate that URLLC data may be inserted in a predefined number of resources for a predefined amount of time. The semi-persistent URLLC indication may be effective for n time slots. n may be configurable. The indicator may reduce overhead and / or the probability of false positives. The indicator may reduce the processing required by the eMBB receiver (e.g., total processing). The receiver may determine the amount of URLLC traffic to accommodate. For example, the receiver may determine the amount of URLLC traffic to accommodate a priori.

[0146] One or more search spaces may be provided for blind decoding of DCI. For example, one or more search spaces may be provided for blind decoding of DCI for URLLC and eMBB multiplexing. Details of preemptive multiplexing of URLLC with eMBB may be sent to the eMBB WTRU. For example, details of preemptive multiplexing of URLLC with eMBB may be sent to the eMBB WTRU to optimize the performance of the eMBB WTRU. The eMBB WTRU may perform per-slot DCI monitoring. If the eMBB WTRU performs per-slot DCI monitoring, the preemptive multiplexing information may be sent in the DCI of the next slot.

[0147] Figure 23is an example of preemptive multiplexing information provided in the DCI of the next timeslot. A DCI format with preemptive multiplexing (e.g., a possible DCI format) may be different from a DCI format without preemptive multiplexing. For example, a DCI format may be provided when there is preemptive multiplexing and another DCI format may be provided when there is no preemptive multiplexing. The WTRU may search (e.g., may always search) for a predefined dedicated DCI format. For example, the WTRU may search (e.g., may always search) for a predefined dedicated DCI format that may carry information about overlapping eMBB / URLLC resources in a previous timeslot / minislot / subframe. As described herein, one or more of the following may apply. A predefined DCI format for overlapping eMBB / URLLC resources may carry a smaller payload size. A predefined DCI format for eMBB / URLLC multiplexing may carry a larger payload size. The WTRU may identify whether the DCI belongs to a previous timeslot and / or a current timeslot. The WTRU may use one or more (e.g., different) CRC masks.

[0148] The predefined DCI format for overlapping eMBB / URLLC resources may carry a payload size. For example, the predefined DCI format for overlapping eMBB / URLLC resources may carry a smaller (e.g., much smaller) payload size than the DCI format that carries information about the ongoing eMBB traffic in the current time slot. The short predefined DCI format may carry (e.g., may only carry) information about frequency and / or time resources (e.g., PRBs, OFDM symbols, mini-indexes, etc.). For example, the short predefined DCI format may carry (e.g., may only carry) information about frequency and / or time resources (e.g., PRBs, OFDM symbols, mini-indexes, etc.) allocated for overlapping URLLC / eMBB transmissions in the previous time slot. The short DCI format for eMBB / URLLC multiplexing may be used for puncturing. For example, the short DCI format for eMBB / URLLC multiplexing may be used for puncturing, where the eMBB resources are partially punctured and / or replaced by URLLC transmissions.

[0149] The predefined DCI format for eMBB / URLLC multiplexing may carry a larger payload size. For example, the predefined DCI format for eMBB / URLLC multiplexing may carry a larger payload size, which may include information and / or frequency-time allocation, such as modulation and coding schemes, transmission mode, MIMO precoding, power allocation, etc. The long DCI format may be used for an overlay scheme. The WTRU may use the long DCI format. For example, the WTRU may use the long DCI format, which determines detection and / or cancellation of interference from a co-scheduled WTRU on overlapping eMBB / URLLC resources. The WTRU may obtain information about the modulation, coding, power and / or MIMO precoding of the interfering WTRU. The WTRU may reconstruct the transmit signal for the co-scheduled WTRU. The WTRU may cancel the transmit signal from the receive signal. For example, the WTRU may cancel the transmit signal from the receive signal to extract the desired signal.

[0150] The WTRU may identify whether the DCI belongs to the previous time slot or the current time slot. For example, the WTRU may identify whether the DCI belongs to the previous time slot or the current time slot by detecting a bit (e.g., one bit) flag. The bit flag may be included in the payload of the DCI. The DCI format may be the same or identical (e.g., substantially the same or identical) for eMBB / URLLC multiplexing and eMBB traffic. If the flag bit is one, the WTRU may determine that the DCI message may include information. For example, the WTRU may determine that the DCI message may include information about overlapping eMBB / URLLC resources from the previous time slot. If the flag bit is zero, the WTRU may determine that the DCI message may include information. The WTRU may determine that the DCI message may include information about assignments / grants for the WTRU in the current time slot.

[0151] The WTRU may use one or more (e.g., different) CRC masks (e.g., RNTIs). For example, the WTRU may use one or more (e.g., different) CRC masks (e.g., RNTIs) to identify (e.g., implicitly identify) whether the DCI belongs to a timeslot. The WTRU may use one or more (e.g., different) CRC masks (e.g., RNTIs) to identify (e.g., implicitly identify) whether the DCI belongs to a previous timeslot or a current timeslot (e.g., eMBB / URLLC multiplexing in a previous timeslot or eMBB traffic in a current timeslot). The WTRU may be assigned two RNTIs. For example, the WTRU may be assigned RNTI1 and RNTI2. The WTRU may use the RNTI (e.g., the assigned RNTI) to check the CRC. If the check of the CRC using RNTI1 succeeds (e.g., the CRC bits carried in the transmission match the CRC bits calculated based on the data), the WTRU may determine that the DCI message may include information about overlapping eMBB / URLLC resources from a timeslot (e.g., a previous timeslot). For example, if the WTRU determines that the CRC bits carried in the transmission match the CRC bits calculated from the data using RNTI1, then the WTRU may determine that the DCI message includes information about overlapping eMBB / URLLC resources from a previous timeslot. If the CRC check using RNTI2 succeeds, then the WTRU may conclude that the DCI message includes information about an assignment / grant for the WTRU in the current timeslot.

[0152] The possible DCI formats with preemptive multiplexing may be different from the DCI formats without preemptive multiplexing.If the eMBB WTRU searches through the DCI formats (eg, all DCI formats), it is an inefficient use of time and / or power.

[0153] Two search spaces may be provided. For example, a search space (e.g., S1) may be provided for a case without preemptive multiplexing. A search space (e.g., S2) may be provided for a case with preemptive multiplexing.

[0154] Figure 2424 is an example of an eMBB WTRU using multiple search spaces (e.g., S1, S2) for DCI. Search spaces S1 and S2 may overlap on physical resources or PDCCH candidates for the WTRU. At 2402, the eMBB WTRU may attempt to search for S1. At 2404, it may be determined whether the search for S1 is successful. At 2406, if the search for S1 is successful, eMBB data may be processed. At 2408, if the eMBB WTRU fails to search for S1, the eMBB WTRU may attempt to search for S2. At 2410, it may be determined whether the search for S2 is successful. At 2412, if the search for S2 is successful, URLLC data may be identified and / or eMBB WTRU data may be processed. If the search for S2 is unsuccessful, no further action may be taken. For example, no further action may be taken for the current timeslot.

[0155] The search space for a normal slot may overlap with the search space for a mini-slot. For example, if mini-slots are present, the search space for a normal slot may overlap with the search space for the mini-slot. The search space for a normal slot may overlap with the search space for the mini-slot to reduce the computational complexity associated with blind decoding. The WTRU may be configured to perform blind decoding on the search space for slots and / or mini-slots.

[0156] Figure 25 An example is shown in which an eMBB WTRU may search one or more of three search spaces. The three search spaces may be labeled as follows. S2 may be the search space used for URLLC and eMBB preemptive multiplexing. S1 may be a WTRU-specific search space. S0 may be a common search space.

[0157] Figure 25 Example behavior of an eMBB WTRU may be shown in FIG. The eMBB WTRU may attempt to decode (e.g., detect) data (e.g., data of a PDSCH). For example, the eMBB WTRU may attempt to decode (e.g., detect) a PDSCH in a previous slot. If the eMBB cannot decode (e.g., cannot detect) the PDSCH in the previous slot, the eMBB may search a search space (e.g., S2) for preemptive multiplexing of URLLC and eMBB. For example, in a current slot (e.g., the current slot), the eMBB WTRU may search (e.g., may start searching) for new radio PDCCH (NR-PDCCH) candidates from the search space (e.g., S2). The PDCCH (NR-PDCCH) may include DCI. The eMBB WTRU may search the search space (e.g., S2) using RNTI2. The search space (e.g., S2) may include preemptive multiplexing of URLLC / eMBB in a previous slot (e.g., the previous slot).

[0158] If the eMBB WTRU detects (e.g., decodes) the PDSCH in the previous slot, the WTRU may not search the search space (e.g., S2) in the current slot that carries the NR-PDCCH candidates that were preempted for URLLC / eMBB in the previous slot. If the WTRU decodes (e.g., successfully decodes) the PDCCH of the previous slot, the WTRU may blind decode (e.g., continue to blind decode) one or more (e.g., other) PDCCH candidates. The WTRU may blind decode (e.g., continue to blind decode) one or more (e.g., other) PDCCH candidates of the current slot in the same control region. For example, the WTRU may blind decode (e.g., continue to blind decode) one or more (e.g., other) PDCCH candidates of the current slot in the common search space (e.g., S0) and / or the WTRU-specific search space (e.g., S1). For example, the WTRU may continue to blind decode one or more (e.g., other) PDCCH candidates for the current time slot in the common search space (e.g., S0) and / or the WTRU-specific search space (e.g., S1) to determine whether there is an assignment for the WTRU in the current time slot.

[0159] If the eMBB WTRU cannot detect (e.g., cannot decode) the PDSCH in the previous timeslot, the eMBB WTRU may determine whether the S2 search using RNTI2 is successful. If the S2 search using RNTI2 is successful, the WTRU may identify the resources affected by URLLC preemptive multiplexing in the previous timeslot. The WTRU may process the soft buffer that includes the soft bits of the previous timeslot. For example, if the preemptive multiplexing scheme is puncturing, the WTRU may ignore the affected soft bits. If the preemptive multiplexing scheme is overlay, the WTRU may perform overlay decoding.

[0160] The search spaces may be overlapping. For example, if the eMBB WTRU's search for search space S2 using RNTI2 is unsuccessful, the search spaces may be overlapping. One or more of the common search spaces (e.g., S0) may carry preemptive URLLC / eMBB multiplexing information. For example, one or more of the common search spaces (e.g., S0) may carry preemptive URLLC / eMBB multiplexing because (e.g., each) WTRU (e.g., eMBB WTRU) may search (e.g., may always search) the common search space (e.g., S0). The eMBB WTRU may attempt (e.g., may first attempt) to use the RNTI used to obtain the preemptive URLLC / eMBB multiplexing information in the common search space (e.g., S0). For example, the eMBB may attempt to search the common search space (e.g., S0) using RNTI2, as Figure 25If the eMBB WTRU successfully searches for S0 using RNTI2, the eMBB WTRU may process the soft buffer of the previous timeslot. For example, if the eMBB WTRU successfully searches for S0 using RNTI2, the eMBB WTRU may identify resources affected by URLLC (e.g., resources affected by URLLC in the previous timeslot) and / or process the soft buffer.

[0161] If the eMBB WTRU does not successfully search the common search space (e.g., S0) using RNTI2, the eMBB WTRU may search (e.g., continue searching) the common search space (e.g., S0). For example, if the eMBB WTRU does not successfully search S0 with RNTI2, the eMBB WTRU may search (e.g., continue searching) the common search space (e.g., S0) using RNTI0. The eMBB WTRU may continue searching the common search space (e.g., searching for S0 using RNTI0) regardless of the search result. Figure 25 As shown, the eMBB WTRU may obtain system information, etc. The eMBB WTRU may search a WTRU-specific search space (e.g., S1). For example, the eMBB WTRU may search a WTRU-specific search space (e.g., S1) using RNTI1.

[0162] The WTRU may search (e.g., may only search) a predefined search space that may be configured to carry a preemptive NR-PDCCH for URLLC / eMBB. For example, to reduce the number of blind decodes, the WTRU may search (e.g., may only search) a predefined search space that may be configured to carry a preemptive NR-PDCCH for URLLC / eMBB in the previous slot on a timeslot / minislot / subframe that may be configured via higher layer signaling for eMBB / URLLC multiplexing. The gNB may restrict eMBB / URLLC multiplexing. For example, the gNB may restrict eMBB / URLLC multiplexing to predefined timeslots / minislots / subframes. The gNB may restrict eMBB / URLLC multiplexing to predefined timeslots / minislots / subframes via semi-static configuration.

[0163] The search space may be a common search space. For example, the search space carrying the NR-PDCCH candidates for preemptive multiplexing of URLLC and eMBB in the previous slot may be a common search space. The search space carrying the NR-PDCCH candidates for preemptive multiplexing of URLLC and eMBB in the previous slot may be a common search space required by (e.g., each, all) WTRUs in order to monitor NR-PDCCH candidates (e.g., all NR-PDCCH candidates) within the search space. The WTRU may monitor fixed NR-PDCCH candidates. For example, the WTRU may monitor fixed NR-PDCCH candidates within the DL control region in a slot / mini-slot / subframe (e.g., all slots / mini-slots / subframes) that may be dedicated to eMBB / URLLC multiplexing. The NR-PDCCH candidates may not be used to transmit the DCI format of the current slot.

[0164] The search space that carries preemptive NR-PDCCH candidates for URLLC and / or eMBB in a previous timeslot may be a group-common search space. For example, the search space that carries preemptive NR-PDCCH candidates for URLLC and / or eMBB in a previous timeslot may be a group-common search space, where a group of WTRUs (e.g., only a group of WTRUs) may monitor (e.g., may need to monitor) in (e.g., every) timeslot / mini-slot / subframe (e.g., configured timeslots / mini-slots / subframes). A WTRU group is a subset of WTRUs. For example, for the group-common search space, a group of WTRUs that may monitor (e.g., may need to monitor) the search space may be WTRUs that may have PDSCH assignments that may overlap with resources used for URLLC transmission in a previous timeslot. The WTRU may receive a group ID from the gNB. The WTRU may use the group ID. For example, the WTRU may use the group ID to determine NR-PDCCH candidates for overlapping resources in a previous timeslot.

[0165] The search space may carry NR-PDCCH candidates. For example, the size of the search space carrying NR-PDCCH candidates for preemptive multiplexing of URLLC and / or eMBB in the previous slot may be designated. The size of the search space carrying NR-PDCCH candidates for preemptive multiplexing of URLLC and / or eMBB in the previous slot may be designated so that blocking may be minimized. There may be enough NR-PDCCH candidates in the search space. For example, there may be enough NR-PDCCH candidates in the search space so that the WTRU can find (e.g., can always find) the NR-PDCCH corresponding to the overlapping URLLC / eMBB resources in the previous slot. The WTRU may find (e.g., can always find) the NR-PDCCH corresponding to the overlapping URLLC / eMBB resources in the previous slot, regardless of whether the WTRU managed to detect and decode (e.g., successfully detected and decoded) the PDSCH in the previous slot. The gNB may determine the size of the search space. The gNB may designate the size of the search space. For example, the gNB may designate the size of the search space based on the amount of URLLC traffic. URLLC traffic may include the number of URLLC users that need to be served in (e.g., each) time slot. The search space carrying the preemptive multiplexing NR-PDCCH candidates for URLLC and / or eMBB in the previous time slot may overlap with the common search space and / or the WTRU-specific search space of the current time slot. The overlap may increase the PDCCH candidate pool for the WTRU and / or reduce the blocking probability. The overlap (one or more) between search spaces may vary on a per-time slot basis. For example, the overlap (one or more) between search spaces may vary on a per-time slot basis according to a predefined pattern. The overlap (one or more) between search spaces may vary on a per-time slot basis according to a predefined pattern to reduce the blocking probability. The WTRU may follow the characteristics (e.g., the same characteristics) of the NR-PDCCH candidates for monitoring the WTRU-specific search space and / or the common search space. For example, the WTRU may follow the same characteristics of the NR-PDCCH candidates for monitoring the WTRU-specific search space and / or the common search space when there is an overlap in the search spaces for URLLC / eMBB multiplexing.

[0166] UL resource reservation may be based on the URLLC UL load ratio. Resources may be reserved for URLLC UL preemptive transmission based on the URLLC load ratio. As the URLLC load ratio increases, the amount of resources reserved for URLLC UL transmission may increase.

[0167] The gNB may estimate the URLLC resources to be reserved. The amount of URLLC UL resources (e.g., required URLLC UL resources) may be estimated semi-statically. The amount of URLLC UL resources (e.g., required URLLC UL resources) may be estimated semi-statically based on the URLLC WTRU initial access. For example, the WTRU may signal (e.g., explicitly signal) the delay and / or reliability (e.g., expected delay and / or reliability). The WTRU may signal (e.g., explicitly signal) the delay and / or reliability (e.g., expected delay and / or reliability) at initial access. The WTRU may signal a predetermined URLLC traffic type. For example, the WTRU may signal (e.g., implicitly indicate) a predetermined URLLC traffic type that indicates (e.g., implicitly indicates) the required delay and / or reliability at initial access.

[0168] The eNB may signal the amount and / or location of resources statically, semi-statically, and / or dynamically. For example, the eNB may signal the amount and / or location of resources statically, semi-statically, and / or dynamically as immediate or semi-persistent signaling. This information may be signaled in the DCI. For example, the PDCCH may be used to signal this information in the DCI. A dedicated URLLC / gNB resource indicator channel may be used to signal this information.

[0169] eMBB UL transmissions and / or URLLC UL transmissions may occur. A URLLC WTRU may be scheduled with resources (e.g., time and frequency) reserved for the URLLC WTRU. The URLLC WTRU may, for example, access resources allocated to the eMBB WTRU in an unlicensed manner. The eMBB WTRU may avoid resources reserved for the URLLC WTRU. The eMBB WTRU may transmit within resources reserved for the URLLC WTRU, for example, in a manner that may accommodate URLLC WTRU preemption. Figure 26is an example of decoding and transmit power for an eMBB transmission using URLLC UL preemption. Transmitting in a manner that accommodates URLLC WTRU preemption may include one or more of the following. For example, transmitting in a manner that accommodates URLLC WTRU preemption may include transmitting at a robust (e.g., more robust) decoding rate in predefined URLLC resources (e.g., to protect eMBB transmissions). Transmitting in a manner that accommodates URLLC WTRU preemption may include transmitting at a robust (e.g., more robust) decoding rate in the symbol / frame (e.g., the entire symbol / frame) that contains the resources (e.g., to protect eMBB resources). Transmitting in a manner that accommodates URLLC WTRU preemption may include transmitting at a lower power than non-URLLC resources (e.g., to protect possible URLLC transmissions). Transmitting in a manner that accommodates URLLC WTRU preemption may include avoiding transmitting in URLLC resources (e.g., to protect possible URLLC transmissions).

[0170] The gNB may estimate the URLLC resources to be reserved. For example, the gNB may estimate the URLLC resources to be reserved based on URLLC WTRU performance signaling. The URLLC WTRU may inform the gNB of the performance of the URLLC WTRU compared to the requirements of the URLLC WTRU. For example, the signaling may not be required to be ultra-reliable and / or low latency. The amount of URLLC UL resources (e.g., required URLLC UL resources) may be dynamically estimated as the URLLC WTRU makes traffic / service requests (e.g., in a scheduled case). The amount of URLLC UL resources required may be estimated based on the success rate and / or URLLC WTRU transmission delay and in the signaling (e.g., explicit signaling) between the URLLC WTRU and the gNB (e.g., explicit signaling) (e.g., in a scheduled and / or unlicensed case). The WTRU may send information about the experienced URLLC reliability and / or delay. For example, the WTRU may send information about the experienced URLLC reliability and / or delay compared to the requested URLLC reliability and / or delay. The comparison may be different (e.g., actually different) and / or may be based on a predetermined set of parameters that may indicate the type of service experienced. For example, a set (e.g., a finite set) of URLLC reliability and delay categories may be defined. The URLLC WTRU may indicate the expected URLLC reliability and / or delay category of the URLLC WTRU upon initial access. The URLLC WTRU may indicate the URLLC reliability and / or the type of delay experienced by the URLLC WTRU to the gNB (e.g., during a service request) using a transmission (e.g., an explicit transmission). The URLLC WTRU may indicate the number of NAKs and / or the ACK / NAK ratio to the gNB. For example, the URLLC WTRU may indicate the number of NAKs and / or the ACK / NAK ratio to the gNB to signal the reliability to the URLLC WTRU.

[0171] Figure 27 is an example of URLLC UL transmission with resource reservation and URLLC capability signaling.

[0172] Figure 28This is an example of UL resource reservation based on URLLC UL load ratio and URLLC performance signaling. At 2802, the gNB may estimate resources. For example, the gNB may estimate resources based on initial access and / or URLLC performance signaling. At 2804, the gNB may signal resources. For example, the gNB may signal allocated resources. At 2806, the gNB may signal eMBB uplink (UL) transmissions. For example, the gNB may signal eMBB UL transmissions in DCI. One or more eMBB WTRUs may use URLLC resource information. For example, one or more eMBB WTRUs may use URLLC resources to adjust transmissions. At 2808, the gNB may signal URLLC UL transmissions and / or one or more URLLC WTRUs may send unlicensed UL transmissions. At 2810, one or more URLLC WTRUs may send information. For example, one or more URLLC WTRUs may send URLLC performance information.

[0173] exist Figures 29A-29D A device comprising one or more of the functions and / or components described in this application is provided.

[0174] Figure 29A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may utilize one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tailing unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and the like.

[0175] like Figure 29AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, devices operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0176] The communication system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112, by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, and 102d. 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 gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0177] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In another embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. Beamforming, for example, may be used to transmit and / or receive signals in a desired spatial direction.

[0178] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0179] More specifically, as described above, the communication system 100 may be a multiple access system and may utilize 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 104 / 113 and the WTRUs 102a, 102b, and 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may utilize Wideband CDMA (WCDMA) to establish the air interface 116. 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).

[0180] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0181] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0182] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0183] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio access technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, 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), etc.

[0184] As an example, Figure 29AThe base station 114b in the may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any appropriate RAT to facilitate wireless connectivity in a local area, such as a place of business, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As Figure 29A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b may not necessarily need to access the Internet 110 via the core network 106 / 107 / 109.

[0185] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. For example, the CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although in Figure 29A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 employing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMax, E-UTRA, or WiFi radio technology.

[0186] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that uses common communication protocols, such as TCP, User Datagram Protocol (UDP), and IP from the Transmission Control Protocol (TCP) / Internet Protocol (IP) suite of internet protocols. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 / 113 or a different RAT.

[0187] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). Figure 29A The WTRU 102c shown may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0188] Figure 29B is a system diagram illustrating an example WTRU 102. Figure 29B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing components while remaining consistent with an embodiment.

[0189] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 29B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated into an electronic package or chip.

[0190] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0191] Although Figure 29B 1 as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals over the air interface 116.

[0192] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0193] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any suitable memory, such as non-removable memory 130 and / or 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. In other embodiments, 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 or a home computer (not shown).

[0194] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control 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 (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0195] 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 from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable positioning method while remaining consistent with an embodiment.

[0196] The processor 118 may also 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 an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, an FM radio unit, a digital music player, a media player, a video game console module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0197] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may occur simultaneously and / or be simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via hardware (e.g., a blocking device) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may occur simultaneously.

[0198] Figure 29C 1 is a system diagram showing the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0199] The RAN 104 may include eNode-Bs 160a, 160b, 160c, however, it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0200] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 29C As shown, the eNode-Bs 160a, 160b, and 160c may communicate with each other via an X2 interface.

[0201] Figure 29C The illustrated CN 106 may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the above components is depicted as being part of the CN 106, it should be understood that entities other than the operator of the CN 106 may also own and / or operate any of these components.

[0202] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide control plane functions to facilitate handover between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0203] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0204] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 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.

[0205] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. By way of example, the CN 106 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the CN 106 and the PSTN 108. The CN 106 may also provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0206] Although Figures 29A-29D While the WTRU is described in the IEEE 802.11 specification as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

[0207] In a representative embodiment, the other network 112 may be a WLAN.

[0208] A WLAN in infrastructure-based service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating from outside the BSS to a STA may pass through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be routed through the AP, e.g., where a source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as end-to-end traffic. End-to-end traffic may be routed between (e.g., directly between) a source and destination STA using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0209] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (e.g., a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0210] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, formed by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0211] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two discontinuous 80 MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, the data can be passed through a segment parser after channel coding, which can separate the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing separately. The stream can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0212] 802.11af and 802.11ah support sub-1GHz operating modes. The channel operating bandwidth and carrier used in 802.11n and 802.11ac are reduced in 802.11af and 802.11ah. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices can have certain capabilities, for example, including limited capabilities to support (e.g., only support) certain and / or limited bandwidths. MTC devices can include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0213] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode from all STAs operating in the BSS. In the example of 802.11ah, the primary channel can be 1 MHz wide for STAs that support (e.g., only) 1 MHz mode (e.g., MTC-type devices), even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (that supports only 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if a large portion of the frequency band is still idle and available.

[0214] In the United States, 802.11ah can be used in the available frequency band from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. The total available bandwidth of 802.11ah is 6MHz to 26MHz, depending on the country code.

[0215] Figure 29D 1 is a system diagram of the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the control interface 116. The RAN 113 may also be in communication with the CN 115.

[0216] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. Each of the gNBs 180a, 180b, 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the control interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may use beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0217] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable length (including a varying number of OFDM symbols and / or a persistently varying absolute time length).

[0218] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connected to another RAN (e.g., the eNode-Bs 160a, 160b, 160c). For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0219] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, and the like. Figure 29D As shown in , gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

[0220] Figure 29DThe CN 115 shown in FIG1 may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one Session Management Function (SMF) 183 a, 183 b, and possibly Data Networks (DNs) 185 a, 185 b. Although each of the above elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0221] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions for different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services targeting machine-type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0222] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure traffic routing through them. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0223] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as Ethernet, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0224] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Furthermore, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0225] Given that Figures 29A-29D as well as Figures 29A-29D

[0015] As described herein, one or more or all of the functionality described herein with respect to one or more of the following may be performed by a simulated device (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. A simulated device may be one or more devices configured to simulate one or more or all of the functionality described herein. For example, a simulated device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0226] The emulation device can be designed to perform one or more tests on other devices in a lab environment and / or in a carrier network environment. For example, one or more emulation devices can perform one or more or all functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices can perform one or more or all functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device can be directly coupled to another device for testing and / or can perform testing using over-the-air wireless communications.

[0227] One or more emulated devices can perform one or more (including all) functions when not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulated device can be used in a test scenario to test an experimental and / or non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulated devices can be test devices. The emulated device can use direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0228] The above process may be implemented in a computer program, software, and / or firmware incorporated into a computer-readable medium executed by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electrical signals (transmitted via a wired or wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROMs and digital versatile discs (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

[0229] Systems, methods, and tools for shared data channels are disclosed. The functional blocks and processing flows of 5G data channels can be implemented using a unified architecture for uplink and downlink. Information carrying filler bits can be used in code blocks. The uplink and downlink signal processing chains can be variable to accommodate various optional channel codes, URLLC data insertion and traffic prioritization, hybrid beamforming, and waveform selection. Data (e.g., low latency data, such as URLLC) can be inserted into ongoing transmissions (e.g., low priority, such as eMBB). Low latency traffic can take over resources allocated for other traffic, for example, by one or more of puncturing, superposition, and multi-user MIMO transmission. eMBB WTRUs and URLLC WTRUs can implement blind decoding. Uplink unlicensed (e.g., random access) URLLC transmissions can be multiplexed with (e.g., scheduled) uplink eMBB transmissions (e.g., from other WTRUs). Sub-slot MU / SU MIMO switching can be provided.

Claims

1. A wireless transmit-receive unit (WTRU), the WTRU comprising a processor and a transmit-receive unit, the WTRU configured to: receiving information indicative of a grant allocating a region of a time slot for data transmission, wherein the data transmission is scheduled for a scheduled time period in the region of the time slot allocated by the grant; receiving downlink control information (DCI) using a radio network temporary identifier (RNTI), the RNTI being used to demask a portion of the received DCI, the received DCI including information indicating one or more transmission regions for the time slot, and determining, based on whether the RNTI belongs to a first type of RNTI or a second type of RNTI, that the DCI includes information indicating the one or more transmission regions for a current time slot or for a previous time slot; as well as In case one or more of the transmission areas overlaps with the area of ​​the time slots allocated by the grant in the scheduled time period, only a portion of the scheduled data transmission is sent in the scheduled time period according to the information in the received DCI.

2. The WTRU of claim 1 , wherein the one or more transmission regions of the time slot indicated by the information in the received DCI are transmission regions to be preempted in the time slot.

3. The WTRU of claim 1 , wherein the processor is further configured to cancel or truncate the scheduled data transmission in an area of ​​the time slot allocated by the grant that corresponds to one or more of the indicated transmission areas.

4. The WTRU of claim 1 , wherein the processor and the transmit-receive unit are further configured to transmit the portion of the scheduled data transmission in the scheduled time period from a start of the region of the time slots allocated by the grant to a start of a time overlap of the region of the time slots allocated by the grant with a first transmission region in time of the indicated one or more transmission regions.

5. The WTRU of claim 1 , wherein the processor and the transmit-receive unit are further configured to transmit the portion of the scheduled data transmission in the scheduled time period from an area of ​​the time slots allocated by the grant that overlaps with an end of a temporally last transmission area of ​​the indicated one or more transmission areas to an end of the area of ​​the time slots allocated by the grant.

6. The WTRU of claim 1 , wherein the processor is further configured to: generating the scheduled data transmission; and Based on the information in the received DCI, the scheduled data transmission is canceled or truncated in one or more of the transmission areas that overlap with the area of ​​the time slots allocated by the grant in the scheduled time period to generate the portion of the scheduled data transmission for transmission in the scheduled time period.

7. The WTRU of claim 1 , wherein the processor is further configured to: monitoring the DCI in a search space of a current time slot; and monitoring another DCI in another search space of the current time slot, wherein the another DCI is masked using the second type of RNTI, and wherein the another DCI includes preemptive multiplexing information, the preemptive multiplexing information indicating that an area in a previous allocation to the WTRU does not carry data for the WTRU, wherein the previous allocation is associated with a previous data transmission to the WTRU.

8. The WTRU of claim 7, wherein the search space and the another search space are one of: (1) overlapping or (2) non-overlapping.

9. The WTRU of claim 7, wherein the first type of RNTI and the second type of RNTI are different.

10. A method implemented in a wireless transmit-receive unit (WTRU), the method comprising: receiving information indicative of a grant allocating a region of a time slot for data transmission, wherein the data transmission is scheduled for a scheduled time period in the region of the time slot allocated by the grant; receiving downlink control information (DCI) using a radio network temporary identifier (RNTI), the RNTI being used to demask a portion of the received DCI, the received DCI including information indicating one or more transmission regions for the time slot, and determining, based on whether the RNTI belongs to a first type of RNTI or a second type of RNTI, that the DCI includes information indicating the one or more transmission regions for a current time slot or for a previous time slot; In case one or more of the transmission areas overlaps with the area of ​​the time slots allocated by the grant in the scheduled time period, only a portion of the scheduled data transmission is sent in the scheduled time period according to the information in the received DCI.

11. The method of claim 10, wherein the one or more transmission regions of the time slot indicated by the information in the received DCI are transmission regions to be preempted in the time slot.

12. The method according to claim 10, further comprising: The scheduled data transmission is canceled or punctured in a region of the time slot allocated by the grant corresponding to one or more of the indicated transmission regions.

13. The method according to claim 10, further comprising: The portion of the scheduled data transmission is transmitted in the scheduled time period from a start of the region of the time slots allocated by the grant to a start of an overlap of the region of the time slots allocated by the grant with a temporally first transmission region of the indicated one or more transmission regions.

14. The method according to claim 10, further comprising: The portion of the scheduled data transmission is transmitted in the scheduled time period from an area of ​​the time slots allocated by the grant that overlaps with the end of the temporally last transmission area of ​​the indicated one or more transmission areas to the end of the area of ​​the time slots allocated by the grant.

15. The method according to claim 10, further comprising: generating the scheduled data transmission; as well as Based on the information in the received DCI, the scheduled data transmission is canceled or truncated in one or more of the transmission areas that overlap with the area of ​​the time slots allocated by the grant in the scheduled time period to generate the portion of the scheduled data transmission for transmission in the scheduled time period.

16. The method according to claim 10, further comprising: Monitoring the DCI in a search space of a current time slot; as well as monitoring another DCI in another search space of the current time slot, wherein the another DCI is masked using the second type of RNTI, and wherein the another DCI includes preemptive multiplexing information, the preemptive multiplexing information indicating that an area in a previous allocation to the WTRU does not carry data for the WTRU, wherein the previous allocation is associated with a previous data transmission to the WTRU.

17. The method according to claim 16, wherein The search space and the another search space are one of: (1) overlapping or (2) non-overlapping.

18. The method according to claim 16, wherein The first type of RNTI and the second type of RNTI are different.