Method and system for system information transmission for beamforming

Abstract

Methods and apparatuses for receiving system information used in a wireless transmit receive unit (WTRU). The WTRU can receive a broadcast signal from a gNB, wherein the broadcast signal includes system information. The WTRU can determine configuration information associated with the received system information and transmit a signal to the gNB using the determined configuration information associated with the received system information. The configuration information includes an indication of whether the WTRU is able to include any one or a combination of a request signal or a feedback signal in the signal transmitted to the gNB. The signal transmitted to the gNB can include a preamble indicating system information block (SIB) request information. The signal transmitted to the gNB can include a control field indicating additional SIB request information. The transmitted signal can provide feedback for the received system information. The WTRU then receives system information from the gNB in response to the transmitted signal. The received system information in response to the transmitted signal is one or more SIBs.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201780070066.X, filed on September 28, 2017, entitled “Method and System for System Information Transmission in Beamforming”, the contents of which are incorporated herein by reference.

[0002] Cross-reference to related applications

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 401,094, filed September 28, 2016, and U.S. Provisional Application Serial No. 62 / 416,557, filed November 2, 2016, the contents of which are incorporated herein by reference. Background Technology

[0004] A wide range of use cases for emerging 5G New Radio (NR) systems include, but are not limited to, enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable and low latency communications (URLLC). These use cases are based on general requirements outlined by ITU-R, NGMN, and 3GPP. Different use cases can focus on different requirements, such as higher data rates, higher spectral efficiency, low power and high capability efficiency, lower latency, and higher reliability. A wide frequency band, ranging from 700MHz to 80GHz, is considered for various deployment scenarios.

[0005] It is known that as carrier frequency increases, severe path loss becomes a significant limitation to ensuring sufficient coverage. Transmission in millimeter-wave systems may suffer additional non-line-of-sight losses (e.g., diffraction loss, penetration loss, oxygen absorption loss, leaf loss, etc.). During initial access, the base station and the wireless transmit / receive unit (WTRU) need to overcome these high path losses and discover each other. Generating beamforming signals using dozens or even hundreds of antenna elements is an effective way to compensate for severe path losses by providing sufficient beamforming gain. Beamforming techniques can include digital, analog, and hybrid beamforming. After initial access, the WTRU receives system information from the base station via the Logical Channel Broadcast Control Channel (BCCH). Summary of the Invention

[0006] A method and apparatus for receiving system information in a wireless transmit-receive unit (WTRU). The WTRU receives a broadcast signal from a gNB, wherein the broadcast signal includes system information. The WTRU determines configuration information associated with the received system information, and the WTRU uses the determined configuration information associated with the received system information to transmit a signal to the gNB. The configuration information includes an indication of whether the WTRU can include either a request signal or a feedback signal, or a combination thereof, in the signal transmitted to the gNB. The signal transmitted to the gNB may include a preamble indicating System Information Block (SIB) request information. The signal transmitted to the gNB may include a control field indicating additional SIB request information. The transmitted signal may provide feedback on the received system information. The WTRU then receives system information from the gNB in ​​response to the transmitted signal. The received system information in response to the transmitted signal is one or more SIBs. The received system information in response to the transmitted signal is received periodically or aperiodically at a defined location.

[0007] A preamble can be associated with one or more SIBs. A preamble can indicate SIB request information. A preamble can be associated with one or more SIB groups, each SIB group being associated with a priority level. Configuration information can include mapping information that provides the association between preambles and one or more SIBs.

[0008] The WTRU can receive broadcast signals in one or more directional beams, and the feedback signal included in the transmitted signal provides feedback for the one or more directional beams. This feedback includes either or a combination of beam information associated with the WTRU and an indication of whether the received first system information meets reception criteria. Reception criteria include the detected first system information energy being higher than a predetermined threshold. Reception criteria also include the passing of a cyclic redundancy check (CRC) associated with the first system information. Attached Figure Description

[0009] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which the same reference numerals denote the same elements, as shown in the drawings:

[0010] Figure 1A This is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments can be implemented;

[0011] Figure 1B This illustrates the implementation method. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system is shown;

[0012] Figure 1C This illustrates the implementation method. Figure 1AThe system diagram shown illustrates an example radio access network (RAN) and an example core network (CN) used within a communication system.

[0013] Figure 1D This illustrates the implementation method. Figure 1A The system diagram shown is of another example RAN and another example CN used within the communication system;

[0014] Figure 2 A flowchart of system information transmission based on selective beam scanning is shown;

[0015] Figure 3 A flowchart is shown showing the system information transmission based on selective beam scanning using updated beam states;

[0016] Figure 4 This is a beam state transition table showing the beam state when selective beam scanning is used;

[0017] Figure 5 This is a beam state transition table that shows the beam state based on the data detection state;

[0018] Figure 6 It is a beam state transition table showing the beam state based on the data detection state and energy;

[0019] Figure 7 A flowchart is shown showing the system information transmission based on selective beam scanning for data detection status and energy of a WTRU-based system.

[0020] Figure 8 The timing diagram for the ACK for the SIB process is shown.

[0021] Figure 9 A timing diagram of an example non-spontaneous HARQ process for SIB transport is shown;

[0022] Figure 10 A timing diagram is shown for another example of a non-spontaneous HARQ process used to request SIB transfers;

[0023] Figure 11 A timing diagram showing an example of an ACK used to request the next SIB transmission;

[0024] Figure 12 A flowchart illustrating an example of a method used in a gNB and one or more WTRUs to transmit system information via signals to achieve effective beam scanning;

[0025] Figure 13 A flowchart illustrating an example of a method used in gNB for dynamically determining the polar coding scheme for SIB;

[0026] Figure 14 A diagram illustrating an example of a polarization mapping function that maps SIBs to an input bit channel of multiple polar codes;

[0027] Figure 15 A flowchart illustrating an example of system information transmission and processing in a gNB;

[0028] Figure 16 The signaling diagram shows an example message flow between a gNB and multiple WTRUs for SIB transmissions;

[0029] Figure 17 A flowchart illustrating the use of predefined time positions for SIB transmission is shown;

[0030] Figure 18 A flowchart illustrating the use of periodic time positions for SIB transmission is shown; and

[0031] Figure 19 A flowchart is shown illustrating an example method for transmitting system information using signals in a gNB and one or more WTRUs. Detailed Implementation

[0032] Figure 1A This is an illustration of an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 can use 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-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DTS-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, and Filter Bank Multicarrier (FBMC), etc.

[0033] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any WTRU 102a, 102b, 102c, or 102d may be referred to as a "station (STA)" and may be configured to transmit and / or receive wireless signals. It may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics, and devices operating on commercial and / or industrial wireless networks, etc. Any of WTRU 102a, 102b, 102c, or 102d may be interchangeably referred to as a UE.

[0034] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to enable access to one or more communication networks (e.g., CN 106, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, and 102d. For example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, e-node Bs (eNBs), home node Bs, home e-node Bs, next-generation node Bs such as g-node Bs (gNBs), new radio (NR) node Bs, site controllers, access points (APs), and wireless routers, etc. Although each of base stations 114a and 114b is described as a single component, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network components.

[0035] Base station 114a may be part of RAN 104, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies called cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals can be transmitted and / or received in a desired spatial direction.

[0036] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, wherein the air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0037] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, and 102c can implement a certain radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), wherein the radio technology can use 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 (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0038] In implementation, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), wherein the technology may use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish air interface 116.

[0039] In an implementation, base station 114a and WTRUs 102a, 102b, 102c may implement a certain radio technology, such as NR radio access, wherein the radio technology may use NR to establish air interface 116.

[0040] In the implementation, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access (e.g., using the dual connectivity (DC) principle). Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0041] In other implementations, base station 114a and WTRUs 102a, 102b, 102c may implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN), etc.

[0042] Figure 1ABase station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as business premises, residences, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), and roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless local area network (WLAN) by implementing radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d can establish a wireless personal area network (WPAN) by implementing radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b does not need to access the Internet 110 via CN106.

[0043] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. The data can have different Quality of Service (QoS) requirements, such as different throughput requirements, low latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or can perform advanced security functions such as user authentication. While in Figure 1A While not shown, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT or a different RAT as RAN 104. For example, in addition to connecting to RAN 104 which uses NR radio technology, CN 106 can also communicate with other RANs (not shown) that use GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technologies.

[0044] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global network of interconnected computer equipment systems using common communication protocols, such as TCP, UDP, and / or IP from the Transmission Control Protocol / Internet Protocol (TCP / IP) suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT or a different RAT as RAN 104.

[0045] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links). For example... Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.

[0046] Figure 1B This is a system diagram illustrating an example of WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitter / receiver unit 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138. It should be understood that, while remaining consistent with the implementation, WTRU 102 may also include any sub-combination of the foregoing components.

[0047] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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), and a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving unit 122. Although Figure 1B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 may also be integrated together in a single electronic component or chip.

[0048] Transmitter / receiver 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitter / receiver 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in one embodiment, transmitter / receiver 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitter / receiver 122 may be configured to transmit and / or receive RF and optical signals. It should be understood that transmitter / receiver 122 may be configured to transmit and / or receive any combination of wireless signals.

[0049] Although Figure 1B While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals via the air interface 116.

[0050] Transceiver 120 can be configured to modulate signals to be transmitted by transmitter / receiver 122 and demodulate signals received by transmitter / receiver 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs (e.g., NR and IEEE 802.11).

[0051] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these components. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information and store data in any suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 can include a subscriber identity module (SIM) card, memory stick, secure digital card (SD) memory card, etc. In other embodiments, the processor 118 can access information and store data in memory that is not actually located in WTRU 102; for example, such memory could be located in a server or home computer (not shown).

[0052] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, and fuel cells, etc.

[0053] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable positioning method.

[0054] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth. Modules, FM radio units, digital music players, media players, video game console modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0055] WTRU 102 may include a full-duplex wireless device, wherein the reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous for the wireless device. The full-duplex wireless device may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., choke coils) or by means of a processor (e.g., a separate processor (not shown) or by means of processor 118) for signal processing. In an embodiment, WTRU 102 may include a half-duplex wireless device that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0056] Figure 1C This is a system diagram showing RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 113 can also communicate with CN 115.

[0057] RAN 113 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 113 may include any number of eNodeBs while maintaining compliance with the implementation. Each of eNodeBs 160a, 160b, and 160c may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0058] Each of the eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. For example... Figure 1C As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0059] Figure 1C The CN 115 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing components is described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by an entity other than the CN operator.

[0060] The MME 162 can connect to each eNodeB 160a, 160b, and 160c in RAN 113 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, performing bearer activation / deactivation processes, and selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 113 and other RANs (not shown) using other radio technologies (such as GSM and / or WCDMA).

[0061] The SGW 164 can connect to each eNodeB 160a, 160b, and 160c in RAN 113 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Furthermore, the SGW 164 can perform other functions, such as anchoring the user plane during handover between eNBs, triggering paging processes when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0062] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to a packet-switched network (e.g., the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0063] CN 115 can facilitate communication with other networks. For example, CN 115 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0064] Although Figure 1A-1D The WTRU is described as a wireless terminal; however, it should be understood that in some typical implementations, such a terminal may use a wired communication interface (e.g., temporary or permanent) with the communication network.

[0065] In a typical implementation, the other network 112 may be a WLAN.

[0066] A WLAN employing an Infrastructure Basic Services Set (BSS) model may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access or interface with a Distributed System (DS) or other type of wired / wireless network that sends traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP; for example, a source STA can send traffic to the AP, and the AP can 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 can be sent between the source and destination STAs (e.g., directly therebetween) using Direct Link Establishment (DLS). In some typical implementations, the DLS may use 802.11e DLS or 802.11z Channelized DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode is sometimes referred to as an "ad-hoc" communication mode.

[0067] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., 20 MHz bandwidth) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some typical implementations, this can be implemented as Carrier-Sensed Multiple Access with Collision Avoidance (CSMA / CA) (e.g., in an 802.11 system). For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can fall back. Within a given BSS, only one STA (e.g., only one station) can be transmitting at any given time.

[0068] High-throughput (HT) STAs can communicate using channels with a width of 40 MHz (e.g., by combining a 20 MHz main channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz channel).

[0069] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (this combination may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is transmitted and passed through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed individually on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0070] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. In a typical implementation, 802.11ah can support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include a battery with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0071] For WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah), the WLAN system includes a channel that can be designated as the primary channel. The bandwidth of the primary channel can be 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 STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the width of the primary channel can be 1MHz for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices). Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy (e.g., because an STA (which only supports the 1MHz operating mode) is transmitting to the AP), then the entire available band can be considered busy even if most of the frequency band remains idle and available.

[0072] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0073] Figure 1D This is a system diagram illustrating a communication system 100 including RAN 117 and CN 119 according to an embodiment. As described above, RAN 117 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 117 can also communicate with CN 119.

[0074] RAN 117 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 117 may include any number of gNBs while maintaining compliance with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit and / or receive signals to and / or from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In another implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In implementations, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0075] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter configurations. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0076] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can use signals in unlicensed frequency bands to communicate with gNBs 180a, 180b, and 180c. In a non-standalone configuration, WTRUs 102a, 102b, and 102c communicate / connect with gNBs 180a, 180b, and 180c simultaneously with other RANs (e.g., eNodeBs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNodeBs 160a, 160b, and 160c, by implementing DC principles. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRUs 102a, 102b, and 102c.

[0077] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, DC, implement NR and E-UTRA interoperability, route user plane data to User Plane Functions (UPF) 184a and 184b, and route control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0078] Figure 1DThe CN 119 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data network (DN) 185a, 185b. While each of the foregoing components is described as part of CN 119, it should be understood that any of these components may be owned and / or operated by entities other than CN operators.

[0079] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 117 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. AMF 182a and 1823b can use network slicing to customize the CN support provided to WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and / or services for MTC access, etc. AMF 182a and 182b can provide control plane functions for handover between RAN117 and other RANs (not shown) using other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0080] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 119 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 119 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and can configure traffic routing through UPFs 184a and 184b. 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, etc. PDU session types can be IP-based, non-IP-based, and Ethernet-based, etc.

[0081] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 117 via the N3 interface. This provides WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring processing, etc.

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

[0083] In view of Figure 1A-1D And about Figure 1A-1D The corresponding descriptions herein refer to one or more of the following functions, which can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other devices (one or more) described herein. These emulation devices can be one or more devices configured to simulate one or more of the functions described herein. For example, these emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0084] The simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, the one or more simulation devices can perform one or more functions while being implemented and / or deployed, wholly or partially, as part of a wired and / or wireless communication network, to test other devices within the communication network. The one or more simulation devices can perform one or more functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform tests, and / or can use over-the-air wireless communication to perform tests.

[0085] The one or more simulation devices can perform one or more functions, including all functionalities, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be used in test laboratories and / or test scenarios where wired and / or wireless communication networks are not deployed (e.g., under test) to perform tests on one or more components. The one or more simulation devices can be test equipment. The simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (which, as an example, may include one or more antennas).

[0086] In LTE systems, the eNB broadcasts System Information (SI) via the logical channel BCCH. This logical channel information is also carried via transport channels (e.g., the broadcast channel (BCH)) or the downlink shared control channel (DL-SCH). The SI has two parts: a static part and a dynamic part. The static part, called the Main Information Block (MIB), is transmitted every 40ms using the BCH and carried once via the Physical Broadcast Channel (PBCH). The MIB carries useful information, including channel bandwidth, Physical Hybrid ARQ Indicator Channel (PHICH) configuration details, transmit power, number of antennas, and System Information Block (SIB) scheduling information, which is transmitted along with other information on the DL-SCH. The dynamic part, also called the SIB, is mapped to Radio Resource Control (RRC) SI messages (e.g., SI-1, SI-2, SI-3, etc.) via the DL-SCH and transmitted at periodic intervals using the Physical Downlink Shared Channel (PDSCH). For example, SI-1 is transmitted every 80ms, SI-2 every 160ms, and SI-3 every 320ms.

[0087] In LTE systems, there are 13 System Information Blocks (SIBs) that help the WTRU access the cell and perform cell reselection, including intra-frequency, inter-frequency, and inter-RAT cell reselection. Each SIB has its own task (i.e., each SIB carries information related to performing its assigned task). After initial cell synchronization and reading the MIB, the WTRU continues to read SIBs to obtain important cell access parameters. For example, SIB1 broadcasts common information related to cell access parameters and scheduling information with other SIBs to all WTRUs within the cell. In the following text, the terms System Information Transmission and SIB Transmission are used interchangeably.

[0088] The following properties need to be considered when designing the initial access signal for an NR system.

[0089] The initial access signal design in an NR system should minimize the always-on signal for system information. This improves network energy efficiency because it transmits system information signals only when needed. Furthermore, it supports forward compatibility, allowing for flexible resource allocation for both legacy and new signals.

[0090] Initial access-related signals in NR systems should also be transmitted using beam-based transmission schemes. Due to coverage loss caused by severe path loss at high frequencies, beamforming may be required to compensate for path loss, even for initial access signals (e.g., PBCH and SIB).

[0091] The initial access signal design in NR systems also requires efficient transmission of system information to reduce beam scanning overhead and conserve energy. Beam scanning mechanisms should be used for coverage cells where all beams are scanned to transmit signals. However, this can lead to unnecessary energy consumption. Energy loss or resource waste due to beam scanning should be minimized.

[0092] The initial access signal design in an NR system should also enhance SIB performance for critical information (e.g., by using one or more SIBs or each SIB having a different priority level).

[0093] In NR systems, broadcast channels can be always-on signals, which can be transmitted periodically at predefined time / frequency locations. If no WTRU requires a broadcast signal, this always-on signal may unnecessarily waste time / frequency resources and network resources in the NR system. Therefore, broadcast signal transmission based on WTRU requests can be used to minimize always-on signals in the network.

[0094] In beam-based systems, it may be necessary to support all beam scans used in the system for broadcast signal transmission, where each beam can cover a specific location within the cell coverage area. In this case, scanning all beams when a broadcast signal is requested for a subset of beams can lead to a loss of system throughput and wasted network energy.

[0095] A beam scanning mechanism, or beam scanning, refers to the use of a beam set to transmit or transmit signals, where the beam set can be used, selected, determined, or transmitted in different time and / or frequency domains. In the example, beam scanning describes the use of a beam set to transmit signals using continuous time resources. Subsequently, full beam scanning can be a beam scan using the entire beam set (e.g., all beams used for signal transmission), and partial beam scanning can be a beam scan using a subset of beams (e.g., a subset of beams used for signal transmission). Partial beam scanning, selective beam scanning, subset beam scanning, and active beam scanning are used interchangeably.

[0096] NR systems can use selective beam scanning with periodic broadcast signals. For example, broadcast signals can be periodically transmitted in predefined or configured time / frequency resources, and beam sets can be used for each period of the broadcast signal, where the beam sets can be determined dynamically or semi-statically. Using periodic broadcast signals can reduce the always-on signal in the system.

[0097] Beams that can be used for broadcast signals during a period (e.g., beams in a beam set used for beam scanning) can be referred to as active beams and / or active states. Beams that are not used for broadcast signals during a period (e.g., beams not in a beam set used for beam scanning) can be referred to as inactive beams and / or inactive states.

[0098] Broadcast signals can be transmitted using beam sets within a period (e.g., the period could be N TTIs), and the amount of time or frequency resources available for broadcast signals can be determined based on the number of beams in the set (e.g., the same as the number of beams in the set). For example, if M beams are used in the set, then M times the time resources can be used for beam scanning.

[0099] Time / frequency resources associated with a beam can be predefined or configured within a period. The following describes the predefined or configured time / frequency resources associated with a beam within a period.

[0100] The time / frequency resources associated with an inactive beam can be used for other signal transmissions. For example, the WTRU can attempt to receive or monitor downlink signals (e.g., control channels, reference signals, and / or data channels) in the time / frequency resources associated with the inactive beam, while attempting to receive or monitor broadcast signals in the time / frequency resources associated with the active beam.

[0101] The WTRU can receive an indication of the beam status for time / frequency resources associated with the beam, which can be implicitly or explicitly transmitted via a signal. For example, the WTRU can receive the beam status indication based on a reference signal used or transmitted in the time / frequency resources. If the WTRU receives a first type of reference signal, the beam status is active. If the WTRU receives a second type of reference signal, the beam status is inactive. The first and second types of reference signals can be determined based on at least one of a reference signal mode, a scrambling sequence, and a scrambling sequence ID, etc.

[0102] The time / frequency resources associated with a beam can be dynamically determined. For example, time / frequency resources can be pre-configured or predefined within a period, and the beam associated with the time / frequency resources can be dynamically determined based on the beam set used for beam scanning within the period. An example of dynamically determining the time / frequency resources associated with a beam is described below.

[0103] The WTRU can be used to indicate the set of beams used in a period. For example, if M beams are used in a period, the WTRU can be used to indicate the number of beams in the set and which beams are in the set. A signal transmission bitmap can be used to indicate which beams are active. Continuous time resources can be used for beam scanning and the amount of continuous time resources can be determined based on the number of active beams. When an associated beam is active, the WTRU can receive or attempt to decode broadcast signals. Otherwise, the WTRU can skip receiving broadcast signals in a period.

[0104] In the initial beam state, all beams can be active, and the initial beam state can be reset every N transmission time intervals (TTIs). Alternatively, the initial beam state can be assumed to be active, and can be reset every X TTIs. Between resets, the beam state can remain the same.

[0105] During each cycle of a broadcast signal, the gNB can transmit the active beams and can turn off inactive beams or use them for other purposes. A new radio physical downlink control channel (NR-PDCCH) with a new radio system information radio network temporary identifier (NR-SI-RNTI) can be used to schedule a new radio physical downlink shared channel (NR-PDSCH) for active beams.

[0106] Subsequently, the broadcast signal may include any one or a combination of the following: Master Information Block (MIB), one or more System Information Blocks (SIB), and / or Cell ID, etc.

[0107] Selective beam scanning can continue transmitting system information based on the same determined beam state until the next beam state reset. During a beam state reset, the beam state can change in the next cycle. A beam state reset can occur first, followed by a reporting cycle, and then one or more selective beam scanning cycles.

[0108] Figure 2 A flowchart illustrating system information transmission based on selective beam scanning is shown. As shown in flowchart 200, the gNB performs initialization or beam state reset 210. One or more WTRUs then respond to the beam transmitted from the gNB 220, and the gNB receives beam state information associated with the beam 230. The gNB performs selective beam scanning based on the beam state to transmit system information 240. The gNB continues selective beam scanning based on the beam state to transmit system information 250. The gNB then resets the beam state 260.

[0109] Figure 3 A flowchart illustrating system information transmission based on selective beam scanning using updated beam states is shown. As shown in flowchart 300, the gNB performs initialization or beam state reset 310. One or more WTRUs then respond to the beam transmitted from the gNB 320, and the gNB receives beam state information associated with the beam 330. The gNB performs selective beam scanning based on the beam state to transmit system information 340. Next, the WTRU sends a request signal to request the beam from the gNB 350 and for the gNB to update the beam state at the gNB 360. The gNB performs selective beam scanning based on the updated beam state to transmit system information 370. The gNB then resets the beam state 380.

[0110] Figure 4 This is a beam state transition table showing the beam states when selective beam scanning is used. In the example, a beam is established between the gNB and the WTRU. As shown in state transition table 400, if the gNB receives an acknowledgment (ACK) from the WTRU, the beam in the inactive state can transition back to the active state. If the gNB receives a discontinuous transmission (DTX) indication (hereinafter referred to as DTX) from the WTRU, the beam in the inactive state can remain inactive. In response to DTX, the beam in the active state can transition to the inactive state. In response to an ACK from the WTRU, the beam in the active state can remain active.

[0111] In implementation, the NR system can use selective beam scanning with a non-periodic broadcast signal. The WTRU can measure one or more signals associated with one or more beams (e.g., always-on signals, such as synchronization signals (e.g., primary and secondary synchronization sequences (PSS and SSS)), PBCH, beam-specific reference signal (BRS), and always-on SIB, etc.), and the WTRU can determine at least one beam to indicate to the gNB or transmit receiver point (TRP).

[0112] For example, the WTRU can measure downlink signals (e.g., beam-specific reference signals or BRS) associated with one or more beams, and the WTRU can determine at least one of the beams to indicate to the gNB. The WTRU can then transmit or report indications related to the determined beam and / or desired broadcast information at a certain time location (e.g., subframe n), and the WTRU can begin monitoring the downlink control channel (e.g., downlink control information (DCI)) for information within a time window, where the time window can be determined, configured, or indicated.

[0113] When selective beam scanning with a non-periodic broadcast signal is present, the DCI scrambled with RNTI (e.g., SI-RNTI) for the broadcast signal can be monitored within the downlink control channel search space within the time window. Note that any one or a combination of the following can be applied.

[0114] The DCI scrambled with RNTI for broadcast signals (e.g., SI-RNTI) can be monitored in the downlink control channel search space within the time window.

[0115] When the WTRU transmits a request indication (or REQ) for beam and / or broadcast signals in subframe n, the time window may begin in subframe n+k and end in subframe n+k+s.

[0116] The downlink control channel search space can be a common search space that is shared by all downlink beams or a beam-specific search space. For example, one or more beam-specific search spaces can be used, and the WTRU can monitor beam-specific search spaces that can be associated with beams indicated or determined for broadcast signaling.

[0117] DCI may include beam-related information (e.g., beam ID), broadcast signal type (e.g., MIB, SIB, SIB-x), broadcast signal set (e.g., one or more SIBs), and / or broadcast signal transmission period (e.g., 50 TTIs).

[0118] DCI can include the scheduling of PDSCHs that can carry one or more broadcast signals.

[0119] DCI can include value tags that indicate changes in the state of broadcast signals.

[0120] If the WTRU is in an RRC idle state, the WTRU can monitor the DCI in the common search space, while if the WTRU is in an RRC connected state, the WTRU can monitor the DCI in its own search space.

[0121] When selective beam scanning with a non-periodic broadcast signal exists, a DCI without PDSCH scheduling information can carry broadcast information and its search space (or DL ​​control channel candidate) can be beam-specific. Note that any one or a combination of the following can be applied.

[0122] One or more DL control channel search spaces can be configured, and each DL control channel can be associated with a beam. The WTRU can monitor the beam-specific search space within a time window for broadcast signal reception.

[0123] One or more DL channel candidates can be used, and a subset of the DL control channel candidates can be associated with a beam. The WTRU can monitor a subset of the DL control channel candidates that can be associated with a beam reported or indicated by the WTRU.

[0124] In another embodiment, selective beam scanning can be used in conjunction with periodic broadcast signals for a first set of SIBs and aperiodic broadcast signals for a second set of SIBs. For example, selective beam scanning can be used to periodically transmit higher priority SIBs (e.g., SIB-1 / 2) and selective beam scanning can be used to aperiodically transmit lower priority SIBs (e.g., SIBs other than SIB-1 / 2).

[0125] Selective beam scans for higher priority SIBs (or the first set of SIBs) can be periodically transmitted, and the beam set used for selective beam scans in each period can be dynamically determined, while selective beam scans for lower priority SIBs (or the second set of SIBs) can be transmitted non-periodically, and the WTRU can monitor the associated DCI in the beam-specific search space (or DL ​​control candidate) during a time window. For example, the higher priority SIB can be a MIB, and the lower priority SIB can be other SIBs.

[0126] In this implementation, the WTRU can indicate, report, or request preferred, selected, or determined beams for receiving broadcast signals. The WTRU can measure one or more downlink signals for measurements of beam quality, signal strength, preferred beams, and / or preferred beam sets, and can report, request, provide feedback, or indicate one or more beams (e.g., one or more preferred beams or one or more determined beams). The WTRU can then attempt to receive the broadcast signal based on the reported or indicated one or more beams. Note that any one or a combination of the following can be applied.

[0127] The WTRU can report request bits or indication bits, which may be referred to as a beam request signal (or REQ). The terms beam request signal, feedback, ACK for beam, beam indication signal, and beam request indication are used interchangeably. The beam request signal can be transmitted to the gNB on a common or dedicated channel.

[0128] Beam request signals, beam-specific ACKs, beam indication signals, or beam request indication reports can be based on the energy or power level of the downlink signal associated with the beam. The WTRU can measure the downlink signal associated with the beam, and the WTRU can report ACKs for beams that are above a predefined or predetermined threshold. Otherwise, the WTRU may not send a beam-specific ACK (e.g., DTX).

[0129] The downlink signal associated with the beam can be at least one of the following: BRS, a subset of broadcast signals (e.g., MIB), or a necessary part of broadcast signals (e.g., SIB-1).

[0130] When a beam is ACKed, it is active, which may mean that a WTRU is camped on the beam; otherwise, the beam is inactive. Selective beam scanning is performed only on these active beams.

[0131] DTX can refer to the absence of a WTRU within the beam or the WTRU being outside the beam coverage.

[0132] The beam can be active if the gNB receives an ACK or if the WTRU sends an ACK. The beam can be inactive if the gNB detects that the DTX or the WTRU has not sent an ACK.

[0133] In another implementation, a first portion of the broadcast signal can be transmitted periodically using full-beam scanning, and a second portion of the broadcast signal can be transmitted on demand using selective beam scanning. The WTRU can report a beam request indication to activate the beam associated with the second portion of the broadcast signal based on the reception of the first portion of the broadcast signal. Note that any one or a combination of the following can be applied.

[0134] The first part of the broadcast signal may include at least one of MIB, SIB1, and SIB2.

[0135] The second part of the broadcast signal may include all SIBs except those in the first part of the broadcast signal.

[0136] The WTRU can receive the first part of a broadcast signal using all beams that can be scanned in each cycle. The WTRU can assume that the same broadcast signal is being repeatedly transmitted in all beams scanned in the cycle, and the WTRU can combine signals received from one or more beams at the receiver.

[0137] During the reception of the first part of the broadcast signal, the WTRU may determine one or more beams (or one or more preferred beams) for the second part of the broadcast signal and the WTRU may report the determined one or more beams and / or request the second part of the broadcast signal, wherein the second part of the broadcast signal may include a set of SIBs or one or more subsequent SIBs.

[0138] The first part of the broadcast signal may include any one or a combination of the following information: the number of beams for the broadcast signal (e.g., a single beam or multiple beams); uplink resources for the determined beam indication (or reporting) and / or requests for the second part of the broadcast signal; and time / frequency resource configuration or allocation for the second part of the broadcast signal. Note that any one or a combination of the following may be applied.

[0139] Separate uplink resources can be configured for one or more SIBs in the second part of the broadcast signal.

[0140] One or more groups can be configured for or for a second part of a broadcast signal, and each group can have an associated uplink resource to indicate. For example, if two broadcast signal groups are used, the first group (e.g., SIB-3 to SIB-7) can have its associated uplink resource and the second group (e.g., SIB-7 to SIB-12) can have another uplink resource to indicate.

[0141] Time / frequency resources can be configured separately for each beam in the second part of the broadcast signal.

[0142] The period of the first part of the broadcast signal can be indicated from the synchronization signal.

[0143] In another implementation, the WTRU can receive, attempt to receive, or monitor downlink signals that may indicate the transmission of broadcast signals in a certain beam. The terms indicating the transmission of broadcast signals in a certain beam, beam activation signal, beam activation indication, ACK acknowledgment indication, and ACK-to-ACK signal can be interchanged. Note that any one or a combination of the following may be applied.

[0144] One or more downlink signals can be reserved in predefined time / frequency resources or pre-configured control channel resources, and these downlink signals can be used for beam activation indication. For example, one or more downlink signals can be associated with one or more beam request indications, and if the gNB receives a beam request indication, the gNB can use the associated downlink signal for beam activation indication.

[0145] The number of beam activation indication resources can be determined based on the number of beam request indication resources. For example, the number of beam activation indication resources can be the same as the number of beam request indication resources. After sending or transmitting a beam request indication, the WTRU can receive, attempt to receive, or monitor the associated beam activation resources. Beam activation indications can be signaled via at least one of higher-layer signaling, DCI, and HARQ-ACK resources for uplink signaling (e.g., PHICH).

[0146] The WTRU can determine beam activity status based on the signal strength of a time / frequency resource. For example, if the received signal strength of a first time / frequency / sequence resource is higher than a predefined threshold, the WTRU can consider the associated beam to be active. Otherwise, the WTRU can consider the associated beam to be inactive. It is also noted that one or more time / frequency / sequence resources can be pre-configured for one or more beams in use, and the WTRU can detect or monitor the received signal strength of the pre-configured resources to determine the beam activation status.

[0147] A common control channel can be used to indicate a beam set that may be active during a given time period.

[0148] WTRUs can use downlink signals to minimize the number of beams used to transmit always-on signals for beam scanning. Therefore, WTRU direction information may be required, energy-based ACK reporting schemes can be implemented, and selective beam scanning can be used.

[0149] It may be necessary to know the directional or beam information of the WTRU to enable selective beam scanning for system information. An ACK reporting scheme can be implemented to determine the WTRU's directional or beam information. The ACK reporting scheme can be based on energy or power level. Energy or power level can be measured via BRS, etc. For example, when the WTRU detects that the beam energy is higher than a predetermined threshold, the WTRU can report ACK. Otherwise, the WTRU can report DTX. As mentioned above, DTX can mean that the WTRU is not in the beam or that the WTRU is outside the beam coverage.

[0150] When the WTRU reports an ACK and the beam is acknowledged, the beam enters an active state, indicating that the WTRU is camping the beam. If the WTRU does not report an ACK and the beam is not acknowledged, the beam enters an inactive state. As described above, selective beam scanning is performed only for the active beam.

[0151] All beams are associated with a beam state. The initial beam state of each beam is considered active. The beam state remains the same between resets. The initial beam state can be reset every N TTIs. The beam state can be obtained during a reporting period. During a reporting period, if the energy or power measured for a beam, such as by BRS, is higher than a predetermined threshold, the WTRU can report an ACK in response to the beam. The WTRU can measure one or more signals associated with one or more beams (e.g., one or more always-on signals, such as synchronization (e.g., PSS, SSS), PBCH, BRS, and always-on SIB, etc.), and the WTRU can determine that at least one beam should be directed to the gNB or TRP. Otherwise, the WTRU can report DTX.

[0152] If an ACK is received, the gNB or TRP determines that the beam is active. If a DTX is detected, the gNB or TRP determines that the beam is inactive.

[0153] During a beam scan cycle, the gNB or TRP can transmit system information in the active beam. The gNB or TRP can also shut down the beam for the inactive beam during a beam scan cycle.

[0154] Non-essential system information can be transmitted using beam-specific common control channels. However, the use of WTRU common signaling in all directions and across all beams results in high system information transmission overhead due to the need for beam scan coverage across the entire service area. This overhead can also lead to high latency or delays.

[0155] In this implementation, selective beam scanning is used to deliver non-essential system information based on the direction or beam information of one or more WTRUs. Since there are no WTRUs with resident beams in one or more directions or beams, the gNB or TRP uses only selective beam scanning to deliver non-essential system information. For example, an NR-PDCCH with NR-SI-RNTI can be used to schedule NR-PDSCHs for these beams. The gNB or TRP can then use selective beam scanning to request the transmission of the system information.

[0156] As described above, the initial beam state of all beams is assumed to be active. The initial beam state can be reset every N TTIs. Beam state transitions can occur between resets. An energy-based ACK reporting scheme can provide the beam state transitions. Beam request scans can then be performed from this information.

[0157] During the reporting period, if the energy or power measured for a beam, such as BRS, exceeds a predetermined threshold and the beam is active, the WTRU may report an ACK in response to the beam. During the reporting period, if the beam is inactive, the WTRU may report an ACK to request the beam. During the reporting period, the WTRU may measure one or more signals associated with one or more beams (e.g., one or more always-on signals, such as synchronization (e.g., PSS, SSS), PBCH, BRS, always-on SIB, etc.), and the WTRU may identify at least one of the beams to indicate to the gNB or TRP. Otherwise, the WTRU may report DTX.

[0158] During a beam scan cycle, if at least one ACK is received from a WTRU in the beam, the gNB or TRP can keep the beam active. If at least one ACK is received from one or more WTRUs in the beam (on request), the gNB or TRP can switch the beam to active. If a DTX is detected in the beam for all WTRUs, the gNB or TRP can switch the beam to inactive.

[0159] The gNB or TRP can use single-beam or multi-beam mode for system information transmission. The WTRU can receive beam mode (e.g., single-beam or multi-beam mode) before receiving system information (e.g., via synchronization signals and / or initial broadcast signals, including MIB).

[0160] In implementation, the WTRU process for supporting on-demand system information transmission can be determined based on either single-beam or multi-beam mode. There is a need to convert periodic system information transmissions into non-periodic transmissions via a request or request command (REQ) from the WTRU. The gNB or TRP then transmits the system information to the WTRU during the system information transmission. System information transmission can also be referred to as SIB transmission. If the WTRU receives the system information correctly, it may not need to be transmitted until the next request from the WTRU.

[0161] For example, a WTRU can request system information via a common channel. Beam-specific common control can be used for system information transmission. Here, the system information requested by the WTRU can also be shared with other WTRUs in the same beam. The beam can be a beam in a single-beam or multi-beam system. In a single-beam system, the system information requested by the WTRU can also be shared by other WTRUs in the same TRP or cell within the single-beam system. In a multi-beam system, this is called the beam-specific request method.

[0162] In another example, the WTRU can request system information via a dedicated channel. Beam-specific dedicated control can be used for system information transmission. Here, the system information requested by the WTRU is not shared with other WTRUs.

[0163] The WTRU process, used to support on-demand system information transmission, can also support request-based and cyclic redundancy check (CRC) based ACK reporting schemes.

[0164] When single-beam mode is used for system information transmission, the WTRU can decode one or more SIBs during the SIB transmission (TX) timing symbol (or SIB TX period). If the detection of one or more SIBs is successful, the WTRU can generate an ACK; otherwise, the WTRU generates a NACK. The WTRU sends an ACK or NACK based on the detection status. The WTRU can also send DTX for the TRP or indicate whether the cell can be turned on / off and enter an inactive or active state.

[0165] When multi-beam mode is used for system information transmission, the WTRU can decode one or more SIBs within a beam-associated SIB TX timing symbol (or SIB TX period) (e.g., a beam-specific SIB TX period). If detection of one or more SIBs in the beam is successful, the WTRU can generate an ACK; otherwise, the WTRU can generate a NACK. The WTRU can send an ACK or NACK in a resource that can be associated with the beam based on the detection status. The WTRU can also send a DTX for one or more beams to be turned on / off and enter an inactive or active state.

[0166] If an ACK is detected, the gNB may stop transmitting system information (or system information in a specific beam), and the WTRU may or may instruct the gNB to stop transmitting system information (or system information in a specific beam).

[0167] If a NACK is detected, the gNB can retransmit the system information (or the system information in a specific beam), and if the WTRU sends a NACK, the WTRU can assume, expect, or attempt to receive a retransmission of the system information (or the system information in a specific beam).

[0168] Figure 5 This is a beam state transition table showing the beam state based on the data detection status. After setting the initial beam state, a beam state transition can occur if the gNB receives an SIB request from the WTRU. Beam transitions can also occur in response to the data detection status of one or more WTRUs' SIBs. The data detection status can generate ACK or NACK. The data detection status can be based on a CRC test. The data detection status can be pass or fail.

[0169] like Figure 5 As shown, if the gNB receives an SIB request from the WTRU, an inactive beam can transition to an active state. If a DTX is detected, an inactive beam remains inactive. An active beam can transition to an inactive state due to CRC-based ACK. An active beam can remain active due to CRC-based NACK.

[0170] Figure 6 This is a beam state transition table showing the beam state based on data detection state and energy. For example... Figure 6 As shown, if the gNB receives an SIB request from the WTRU, an inactive beam can transition to an active state. If a DTX is detected, an inactive beam remains inactive. An active beam can transition to an inactive state because its energy drops below a predetermined threshold. For example, an active beam can transition to an inactive state due to a WTRU DTX for the measured power or because the signal strength of the BRS (etc.) is below a predetermined threshold. An active beam can transition to an inactive state due to a CRC-based ACK (ACK_D) or if a DTX is detected. An active beam can remain active due to a CRC-based NACK (NACK_D) or an energy-based ACK (ACK_E).

[0171] Figure 7A flowchart illustrating the transmission of system information based on selective beam scanning for data detection status and energy of WTRUs is shown. As shown in flowchart 700, the gNB performs initialization or beam state reset 710. One or more WTRUs then respond to beams transmitted from the gNB 720, and the gNB receives beam state information associated with the beams 730. The gNB performs selective beam scanning based on the beam state to transmit system information 740. One or more WTRUs then respond to beams transmitted from the gNB based on the detection status of the system information of one or more WTRUs 750. Next, one or more WTRUs send request signals to request beams to be transmitted from the gNB 760, and the gNB updates the beam state based on one or more request signals received from one or more WTRUs 770. The gNB performs selective beam scanning based on the updated beam state to transmit system information 780. The gNB then resets the beam state 790.

[0172] For energy-based beam state transitions, detecting DTX means that the WTRU is not present. For data-based beam state transitions and energy-based transitions, detecting DTX means that the WTRU is not present or that the WTRU exists but has not requested SIB transmissions or system information in the beam.

[0173] As described above, a WTRU can send an ACK to acknowledge receipt of a SIB transmission. For example, if the gNB receives an ACK in a beam, it means that there is at least one WTRU in that beam. If no ACK is received, the gNB can assume that there is no WTRU in the beam and that selective beam scanning can exclude that beam from the beam scan.

[0174] Figure 8 A timing diagram for the ACK of the SIB process used for SIB transmission is shown. Figure 8 As shown, the WTRU receives and measures one or more DL synchronization signals, PBCH, and SIB transmissions. The WTRU can then send an ACK in response to the SIB transmission.

[0175] Energy-based ACKs for SIB transmissions can be used to establish the WTRU's direction profile during the initial state. During beam state transitions, sending ACKs for SIB transmissions can be used to track the WTRU's direction profile. For example, if a CRC-based ACK is received, one or more beams participating in a beam scan can stop SIB transmissions. In the next beam scan, a beam can change from an active beam state to an inactive beam state. If at least one NACK is received, SIB transmissions can be sent again for that beam. If a beam becomes silent due to the absence of a WTRU in the beam and DTX is detected, the active beam can transition to an inactive state for the next beam scan.

[0176] For beams not participating in the beam scan, if a REQ is received, the gNB begins retransmitting SIB transmissions. Therefore, ACK and DTX can transition an active beam to an inactive state. NACK can keep an active beam active. For the next beam scan, REQ can transition an inactive beam to an active state. The gNB can receive any one or a combination of ACK, NACK, DTX, and REQ in the corresponding time symbol for a beam.

[0177] In this implementation, the WTRU procedure supporting beam-specific requests for SIB transmissions is used to minimize always-on signal. In a beam-specific request for SIB transmission, the WTRU can request one or more SIBs via the beam in which the WTRU resides. When the WTRU needs one or more SIBs, it can execute a non-spontaneous HARQ process for the one or more SIBs to initiate the request for SIB transmission.

[0178] In implementation, the WTRU can use a non-spontaneous HARQ process to request SIB transfers. Figure 9 A timing diagram of an example non-spontaneous HARQ process for SIB transmission is shown. Figure 9 Initially, SIB transmissions can be carried out in all directions and in all beams (e.g., beams 1, 2, 3...M) at time symbols 1, 2, 3...M. When a WTRU detects an SIB transmission, it can report an ACK to the gNB. One or more WTRUs can attempt to detect SIB transmissions in all beams and in all directions. Note that WTRUs in different beams can report ACKs back to the gNB. When the gNB or TRP receives an ACK, SIB transmissions can be stopped because one or more WTRUs may have already received system information. Figure 9 The diagram shows beams 1, 2, 3...M that are all ACKed in the next transmission time.

[0179] When needed, the WTRU can request SIB transmissions. The WTRU can send a REQ to the gNB or TRP for the beam corresponding to its location. For example... Figure 9 As shown, one or more WTRUs can send a REQ for the SIB to the gNB for beams 1 and 3. The gNB then receives the REQ from the WTRU and transmits the SIB in the corresponding beams (i.e., beams 1 and 3) in the next transmission opportunity.

[0180] Figure 10 A timing diagram of another example non-spontaneous HARQ process for requesting SIB transfers is shown. Figure 10In the process, SIB transmissions are first transmitted in all beams (e.g., beams 1, 2, 3...M) and in all directions, according to time symbols 1, 2, 3...M. When a WTRU detects an SIB transmission, it can report an ACK to the gNB. One or more WTRUs can detect SIB transmissions in all beams and in all directions. WTRUs in different beams can report ACKs back to the gNB. For beams that have already been ACKed, the gNB or TRP can stop SIB transmissions because one or more WTRUs may have already received system information. When a WTRU does not detect an SIB transmission for a particular beam, it can NACK or DTX for that beam, and SIB transmissions can continue in that beam because one or more WTRUs may not have received system information. WTRUs can request SIB transmissions when needed.

[0181] In this implementation, the WTRU can use a combination of CRC-based and energy-based methods to perform a non-spontaneous HARQ process to request SIB transmissions. In this implementation, energy or power can be measured via a beam-specific reference signal (BRS). If the detected energy is above a predetermined threshold but the CRC test fails, the WTRU can report a NACK. A NACK can provide an indication that the energy of one or more beams is above a predetermined threshold but the CRC test for one or more beams has failed. Therefore, the gNB can then retransmit the SIB transmission or system information. A NACK used in this way can be called a smart NACK. If the detected energy is below a predetermined threshold, the WTRU can report a DTX. A DTX can also indicate that no WTRU is residing in the beam. If the detected energy is above a predetermined threshold and the CRC passes, the WTRU can report an ACK.

[0182] In this implementation, the WTRU can use an energy-based method to perform a non-spontaneous HARQ process to request SIB transmissions. Similar to the implementation described above, energy or power can be measured via the BRS. If the detected energy is above a predetermined threshold, the WTRU can report an ACK. If the detected energy is below the predetermined threshold, the WTRU can report a DTX.

[0183] exist Figure 10 In the next transmission time, beam 1 will be ACKed. Figure 10It is also shown that one or more WTRUs did not detect SIB transmissions for beams 2 and M. The one or more WTRUs then reported NACKs for beams 2 and M. Since one or more WTRUs may not have received system information, SIB transmissions continue in beams 2 and M. For beam 3, one or more WTRUs did not detect SIB transmissions for beam 3, and one or more WTRUs could report DTXs for beam 3. Alternatively, the gNB or TRP could continue transmitting SIBs within a preset timer before stopping the transmission. As a result, the gNB or TRP could continue SIB transmissions in beams 2 and M but stop SIB transmissions in beam 3.

[0184] During the next uplink time opportunity, the WTRU can request system information when needed. The WTRU can send a REQ (Request for Query) to the gNB for the corresponding beam it is camped on. For example... Figure 10 As shown, one or more WTRUs can send REQs to the gNB via beams 1 and 3. When the gNB receives these requests or REQs from one or more WTRUs, it can perform an SIB transmission in the corresponding beams (i.e., beams 1 and 3) during the next SIB transmission time opportunity. Figure 10 Since beam 2 has been acknowledged, it can choose not to transmit an SIB during the next SIB transmission opportunity. Beam M has been rejected and can transmit an SIB again during the next SIB transmission opportunity. As a result, the gNB or TRP can continue SIB transmission in beams 1 and 3 due to requests from one or more WTRUs, and can continue SIB transmission in beam M because beam M has been rejected. Since beam 2 has been acknowledged, the gNB or TRP can stop SIB transmission in beam 2.

[0185] Since DTX can mean there is no WTRU in the beam, a timer can be set for SIB transmission when the gNB detects DTX. A NACK response can mean that the SIB was not received correctly but there is a WTRU in the beam. A timer can also be set for the SIB when the gNB detects a NACK response. Since energy can exceed a threshold but data cannot be decoded correctly, this can mean there is no WTRU camped in the beam and the energy could come from interference or noise. If the timer expires, the gNB can stop SIB transmission.

[0186] When the gNB receives feedback from a WTRU for a given beam, the gNB can receive all ACKs from all WTRUs in that beam. The gNB can then stop SIB transmission. If the gNB receives at least one NACK response from a WTRU in that beam, it can continue SIB transmission, as some WTRUs may not have received SIB transmissions.

[0187] As described above, the WTRU can send an ACK to indicate the WTRU beam position. In this implementation, in addition to responding to the WTRU's beam position, the ACK can also carry information. The information carried in the ACK can be used to request the next SIB transmission. More specifically, the WTRU can send an ACK to indicate whether one or more SIBs should be transmitted next based on the WTRU's request. The ACK sent from the WTRU can also indicate how many SIBs should be transmitted next based on the WTRU's request. The WTRU can also indicate the duration before the next SIB transmission is due.

[0188] After L time intervals of SIB transmissions for a given beam, an ACK can be used to request the next SIB transmission. A BPSK-modulated ACK can carry 1 bit to indicate the L time intervals of the SIB transmissions. For example, L could be L = {1, 4} or L = {1, 8}. Note that other sets of values ​​for L are possible. A QPSK-modulated ACK can carry 2 bits to indicate the L time intervals of the SIB transmissions. For example, L could be L = {1, 2, 3, 4} or L = {2, 4, 6, 8}. Note that other sets of values ​​for L are possible.

[0189] Figure 11 A timing diagram illustrating an example of an ACK used to request the next SIB transmission is shown. Figure 11 As shown, ACK can be used to request the next SIB transmission during HARQ processing. Figure 11 In the process, SIB transmissions are first transmitted in all beams (i.e., beams 1, 2, 3...M) and in all directions, respectively, according to time symbols 1, 2, 3...M. When a WTRU is present in all beams, the gNB can receive ACKs for all beams. The WTRU can use the ACK, which can carry additional request information to request the next SIB transmission for the WTRU in order to receive another SIB.

[0190] Figure 12 A flowchart illustrating an example of a method for transmitting system information via signals to achieve effective beam scanning, used in gNBs and one or more WTRUs.

[0191] As described in process 1200, the gNB can transmit a broadcast signal 1210 including system information. The broadcast signal can be transmitted in one or more directional beams. The broadcast signal can be an always-on signal. The broadcast signal can be transmitted via the PBCH or a similar channel. It can also be transmitted via a channel carrying residual minimum system information. The system information included in the broadcast signal can provide configuration information, including any one or a combination of resource allocation, mapping information, resource indication, and mode indication guiding WTRU behavior. The configuration information can include indications of whether the WTRU can transmit request signals, feedback signals, or any one or a combination of neither to the gNB. The configuration information can allow the WTRU to provide feedback associated with the system information. The configuration information can be part of or different from the RACH configuration. The configuration information can be carried or included in the broadcast signal or channel, such as a synchronization signal (SS), residual minimum system information (RMSI), NR-PBCH, or other system information (OSI). The system information can be referred to as first system information or residual minimum system information.

[0192] The WTRU can receive system information in broadcast signals and determine whether the received system information meets reception criterion 1220. The reception criterion may include any one or a combination of the following: CRC indicating that the WTRU has successfully received the system information, or the WTRU determines that the beam energy is above a threshold.

[0193] The WTRU uses broadcast signals to determine configuration information to provide feedback 1230 associated with system information included in one or more directional beams. The WTRU then uses the configuration information associated with the received system information to transmit signals 1240 on the one or more beams. The transmitted signals may be feedback signals providing feedback associated with the system information included in one or more directional beams. Feedback may be transmitted for each of the one or more directional beams. The feedback provided in the transmitted signals may include any one or a combination of the following: beam information associated with the WTRU and an indication of whether the received system information meets reception criteria.

[0194] The gNB can receive signals 1250 from the WTRU for each of one or more directional beams, and the gNB then sets the beam state 1260 for system information transmission based on feedback included in the transmitted signals. The beam state can be an active state or an inactive state.

[0195] The gNB then performs selective beam scanning to transmit system information 1270. Selective beam scanning to transmit system information can be based on any one or a combination of the following: including feedback and beam state in the transmitted signal. The transmitted system information can be referred to as second system information or other system information transmission (SIB).

[0196] In this implementation, a fixed preamble sequence can be used for the feedback signals (e.g., ACK and DTX) for the initial beam state. For example, if such a preamble is detected, the WTRU generates an ACK. Otherwise, DTX is detected.

[0197] In this implementation, fixed preamble sequences are used for feedback signals (e.g., ACK and NACK) indicating beam state transitions. Three fixed preamble sequences can be used for ACK, NACK, and REQ. For example, when the WTRU reports ACK, it can transmit preamble sequence 1. When the WTRU reports NACK, it can transmit preamble sequence 2. When the WTRU sends REQ, it can transmit preamble sequence 3. Otherwise, DTX is detected.

[0198] When a gNB receives the corresponding preamble sequence, it can determine whether to transmit an SIB. For example, if the gNB receives only preamble sequence 1 for a given beam, it can stop SIB transmission for that beam. If the gNB receives both preamble sequences 2 and 3, it can continue or begin SIB transmission for that beam.

[0199] In this implementation, preamble groups are used for feedback signals of beam state transitions. Three fixed preamble groups can be used for ACK, NACK, and REQ. For example, when the WTRU reports ACK, it can transmit preamble group 1. When the WTRU reports NACK, it can transmit preamble group 2. When the WTRU sends a request command (REQ), it can transmit preamble group 3. Otherwise, DTX is detected.

[0200] When the WTRU reports an ACK, it can select a preamble sequence from preamble group 1. When the WTRU reports a NACK, it can select a preamble sequence from preamble group 2. When the WTRU sends a REQ, it can select a preamble sequence from preamble group 3.

[0201] In this implementation, a reduced preamble sequence is used for the feedback signal of beam state transition, with two preamble sequences used for ACK and REQ. For example, when the WTRU reports ACK, it may transmit preamble sequence 1. When the WTRU sends REQ, it may transmit preamble sequence 2. Otherwise, DTX is detected.

[0202] When the WTRU reports an ACK, it can transmit preamble sequence 1. When the WTRU sends a REQ, it can transmit preamble sequence 2.

[0203] When a gNB receives the corresponding preamble sequence, it knows whether to transmit an SIB. For example, if the gNB receives only preamble sequence 1 for a given beam, it can stop SIB transmission for that beam. If the gNB receives preamble sequence 2, it can continue SIB transmission for that beam regardless of whether it received preamble 1. If at least one WTRU in a given beam requests an SIB, the gNB can transmit the SIB in that beam. WTRUs that have already received an SIB in that beam do not need to decode it.

[0204] In this implementation, a reduced preamble sequence is used for the feedback signal of beam state transition, with two preamble sequences used for ACK, NACK, and REQ. For example, when the WTRU reports ACK, it can transmit preamble sequence 1. When the WTRU reports ACK or sends REQ, it can transmit preamble sequence 2. Since NACK is used for the active state and REQ is used for the inactive state, there is no confusion. Otherwise, DTX is detected. This implementation reduces the number of preambles used.

[0205] When a gNB receives the corresponding preamble sequence, it can determine whether to transmit an SIB. For example, if the gNB receives only preamble sequence 1 for a given beam, it can stop SIB transmission for that beam. If the gNB receives preamble sequence 2, it can continue or begin SIB transmission for that beam regardless of whether it received preamble 1. If at least one WTRU in a given beam requests an SIB, the gNB can transmit the SIB in that beam. WTRUs that have already received an SIB in that beam do not need to decode it.

[0206] When the beam is active, the WTRU can send ACK or NACK using either preamble sequence 1 or preamble sequence 2. When the beam is inactive, the WTRU can send REQ to request SIB transmission. Since NACK and REQ are used in two different beam states, they do not overlap. Alternatively, in the active state, the WTRU can send either NACK or REQ. However, it is not necessary for the WTRU to request the same SIB, as the SIB has already been transmitted by other WTRUs. If a WTRU has already requested the same SIB, that same SIB can be shared and received by all WTRUs residing in the same beam.

[0207] Different SIBs may be expected for a WTRU. In this case, even in the active state, the gNB may send different SIBs based on a WTRU request command. For example, there may be some SIBs that are always online, some SIBs on demand before the RACH procedure, and some SIBs on demand after the RACH procedure. Each ACK may be time and beam synchronized with each SIB. For example, any one of the following or a combination thereof may occur: The MIB is always online; SIB1 / SIB2 is on demand at the beam level (each beam may serve multiple WTRUs) and may be executed before and after the RACH; SIB3 - SIB20 is on demand at the WTRU level and always after the RACH.

[0208] The use of on demand may not always be beneficial because the common control information is backed up for each WTRU. However, when the number of WTRUs is small, the use of on demand is beneficial. The switch between always online and on demand can be made based on the number of WTRUs in the TRP or cell.

[0209] In LTE, multiple types of system information can be included in different SIBs, and different resources can be used to send these SIBs. In NR, multiple SIBs can be jointly processed before multiple SIB transmissions. For example, the gNB can jointly broadcast multiple SIBs simultaneously. In another example, the WTRU can request some SIBs or all SIBs, and the gNB can transmit all the requested SIBs to the WTRU at once.

[0210] In NR, the channel coding of these SIBs can be based on polar codes. There are two rate matching schemes for polar codes to achieve the desired code block size. The first scheme is based on puncturing of large - size polar codes. The second scheme is based on the combination of multiple smaller - size polar codes. The flexible polar coding scheme can switch between these two schemes based on the number of SIBs to be jointly encoded and the decoding rate associated with the SIBs. A flexible polar coding scheme is needed to support encoding a variable number of SIBs at their associated decoding rates.

[0211] When jointly processing multiple SIBs, each component SIB may have a different priority. For example, SIB1 may be more important than other SIBs and it should have the highest priority. Generally, if X < Y, SIB_X is more important than SIB_Y. Therefore, SIB_X should have a higher priority than SIB_Y. However, this condition may not always be true. In the case of on - demand SIBs (i.e., the WTRU requests some SIBs from the gNB), the WTRU can provide the priority order of the SIBs it needs.

[0212] Polar codes are known to have different reliability levels for their bit channels. When these reliability levels are associated with the priority order of SIBs, higher-priority SIBs are more likely to be successfully decoded. This association can also be integrated into flexible polar coding schemes.

[0213] In the implementation, the NB dynamically determines the polarization coding scheme for the SIB. Figure 13 A flowchart illustrating an example of a method for dynamically determining a polarization coding scheme for SIBs used in gNBs is shown.

[0214] As shown in process 1300, in response to the gNB having multiple SIBs to broadcast, or the gNB receiving an on-demand SIB request, the gNB decides to jointly encode multiple SIBs 1310. Next, the gNB decides to jointly encode multiple SIBs 1320. The gNB first calculates the total information block size of these SIBs and their associated decoding rate. This information is used to fix the target encoded block size.

[0215] Based on the number of bits in the coded block and the decoding rate, the gNB determines the rate matching scheme 1330. The gNB needs to determine whether it will use a single polar code with some perforations or whether it will combine multiple polar codes to achieve the target coded block size.

[0216] For a single polar code application, the gNB determines the priority order of the jointly encoded SIBs 1340 and then maps the SIBs to different input bit channels of the polar code based on these priority levels 1350. The gNB then follows a default (i.e., for X)<Y,SIB_X> The priority order of the jointly encoded SIBs can be determined by either SIB_Y or the SIB request message from the WTRU.

[0217] For multiple polar code applications, the gNB determines the priority order 1360 of the jointly encoded SIBs and then maps the SIBs to the input bit channels 1370 of the multiple polar codes. First, the gNB aligns the bit channel reliability levels across the different component polar codes. Then, the gNB maps the SIBs to the different input bit channels of these polar codes based on their priority levels. Some XOR operations on the SIB bits can be applied before mapping. Specifically, some XORed bits can also be mapped to some input bit channels of these polar codes. The gNB knows the priority order of the jointly encoded SIBs either by default or according to the SIB request message from the WTRU.

[0218] gNB then applies the polarization coding process to SIB 1380.

[0219] Figure 14 A diagram illustrating an example of a polarization mapping function that maps SIBs to an input bit channel of multiple polar codes is shown. More specifically, Figure 14 It shows in Figure 13 A detailed example of element 1370 found. As shown in example 1400, M SIBs X1, ..., X M It needs to be jointly encoded. This can be based on the information block size. The code block size is calculated using the expected decoding rate R. Bit. In Figure 14 In China, due to The decision is made to use L polar codes, each with a block size of n1,…,n. L Bit.

[0220] Since the priority order of the SIBs is known, the priority order of the input bits can also be determined. Based on this information, the joint polarization mapping function is designed to have a size of... The binary mapping matrix J. The output of the joint polarization mapping function can be calculated as:

[0221]

[0222] The design of J involves priority levels and the size of multiple polar codes.

[0223] Figure 15 A flowchart illustrating an example of system information transmission and processing in a gNB is shown. As shown in flowchart 1500, the gNB determines whether it has multiple SIBs to broadcast 1510. The gNB can also receive on-demand SIB requests from one or more WTRUs 1520. The gNB determines the priority order of the system information payload 1530.

[0224] When one or more SIBs are transmitted simultaneously in the system information payload, a CRC can be attached to one or more SIBs. Based on the priority of the system information, the gNB can assign a CRC to each SIB or a class of SIBs. High-priority CRCs can be assigned to high-priority SIBs or SIB classes, while low-priority CRCs can be assigned to low-priority SIBs or SIB classes. The priority of the system information can be predefined or based on the needs of the WTRU. When the WTRU requests system information, it can provide a priority list of the system information.

[0225] The gNB then concatenates the payload and CRC 1550 according to priority order, mapping different SIBs to...

[0226] The input bit channel 1560 consists of multiple polar codes, as well as the encoded payload and CRC 1570.

[0227] Figure 16A signaling diagram showing an example message flow between a gNB and multiple WTRUs for SIB transmission. As shown in process 1600, the gNB can broadcast multiple SIBs simultaneously, and these SIBs are encoded based on single or multiple polar codes 1610. The selection of the polar coding scheme can depend on the Figure 13 above process described in

[0228] WTRU1 can send a SIB request message 1620 to the gNB. WTRU1 can request some SIBs with a priority order. For example, WTRU1 can request three SIBs with a priority order SIB_x > SIB_y > SIB_z. If no priority order information is provided, the gNB can consider the SIBs to be in the default priority order (i.e., if x < y, then SIB_x > SIB_y). The gNB uses the Figure 13 method described in

[0229] to select a polar coding scheme based on the SIB request. The gNB then sends a SIB response message 1630 to WTRU1.

[0230] The gNB can also receive a SIB request 1640 from WTRU2 and send a SIB response message 1650 to WTRU2. The gNB can also broadcast multiple SIBs simultaneously again 1660.

[0230] In an embodiment, the WTRU can request system information via a common control channel. For example, the WTRU can request system information via SI-RNTI PDCCH / PDSCH and scheduling request (SR), etc.

[0231] In another embodiment, the WTRU can request system information via a dedicated channel. For example, the WTRU can request system information via C-RNTI PDCCH / PDSCH and dedicated UL control, etc.

[0232] There are two schemes that can be used for WTRU-specific requests for SIB transmission.

[0233] According to the first scheme, a predefined time position is used for SIB transmission. SIBs may not always be transmitted. However, when SIBs are transmitted, they are transmitted at the predefined time position. This can improve energy efficiency because the beam energy for SIBs caused by transmitting all SIBs at the predefined time according to the request is low.

[0234] In the first scheme, when the WTRU requests an SIB transmission, the gNB can transmit the SIB based on the request from the WTRU. If the WTRU requests the SIB at a time x time units prior to the predefined SIB time position, the gNB can transmit the SIB at the next immediate SIB transmission time position. Otherwise, the gNB can wait until the next SIB transmission opportunity in the following predefined SIB time position. The time unit x can be an OFDM symbol, a time symbol, a TTI, etc. The value of x can depend on the system and design, and the value of x can be configurable or predefined. For example, x can be some OFDM symbols or one TTI. If the SIB time position is TTI#n, then x can be TTI#nk, where k = 1 or k > 1. In this example, a common control channel can be used, and the SI-RNTI can be masked using the PDCCH to schedule the SIB via the PDSCH.

[0235] Figure 17 A flowchart is shown using a predefined time position for SIB transmission. As shown in flowchart 1700, the WTRU sends a request for system information to the gNB 1710. The WTRU then waits for the next predefined time position to receive the requested system information 1720. The WTRU then receives the system information 1730 at the predefined time position.

[0236] In the second scheme, aperiodic timing is used for SIB transmission. The aperiodic timing is determined based on when the WTRU requests the SIB transmission. This scheme can have higher energy consumption because transmitting the SIB at any time consumes beam energy if many WTRUs request the SIB at different times. This scheme does not have a predefined timing for SIB transmission. The second scheme can be partially WTRU-specific (via SI-RNTI) or fully WTRU-specific (via C-RNTI).

[0237] In the second scheme, when the WTRU requests an SIB transmission, the gNB can transmit the SIB based on the request from the WTRU. Since the second scheme does not have a predefined time position for SIB transmission, the gNB can transmit the SIB immediately without waiting for the transmission opportunity. The gNB can use the PDCCH with the cell RNTI (C-RNTI) mask to schedule SIB transmissions for the WTRU.

[0238] Figure 18 A flowchart illustrating the use of periodic time positions for SIB transmissions is shown. As shown in flowchart 1800, the WTRU sends a request for system information to the gNB 1810. The WTRU then waits for a predefined fixed or variable number of TTIs to receive the requested system information 1820. The WTRU then receives the system information at the predefined time position 1830.

[0239] The first option is partially WTRU-specific. The second option is WTRU-specific.

[0240] Although the first approach is based on a WTRU-specific request for SIB transmissions, SI-RNTI can be used. Therefore, other WTRUs can still use SI-RNTI to receive and decode PDCCH as well as decode PDSCH for SIB transmissions.

[0241] According to the first scheme, when the WTRU needs an SIB, it can first attempt to decode the SIB at a predefined time position. Different SIBs can have the same or different predefined time positions. The WTRU can wait for these corresponding time positions to receive the SIB it needs. If the WTRU can decode the required SIB, it does not need to request the SIB. If the WTRU cannot decode the SIB, it can request the SIB if it needs it.

[0242] WTRUs may be unable to decode SIBs due to their on-demand requesting nature. If a WTRU does not request an SIB needed by another WTRU, that particular SIB may not be transmitted at those time points, and the WTRU may not discover and decode the SIB because it does not exist.

[0243] Using a common control channel can reduce SIB overhead. Since both using a common control channel and using a dedicated WTRU-specific control channel for SIB delivery have their own advantages and disadvantages in terms of signaling overhead and SIB reception latency, depending on the number of WTRUs in the system, the system can use a switching mechanism between using a common control channel and using a WTRU-specific control channel.

[0244] In this implementation, the gNB uses a common control channel and a WTRU-specific control channel for SIB transmission. When the number of WTRUs communicating with the gNB exceeds a threshold and signaling overhead is high, the gNB switches to a common control channel scheme using predefined time positions for SIB transmission. Otherwise, the gNB switches to a dedicated WTRU-specific control channel scheme using non-periodic time positions for SIB transmission.

[0245] In this implementation, system information can be transmitted before and after the random access procedure. More specifically, non-essential system information can be transmitted in the random access channel and in the random access response channel. This implementation can be combined with selective beam scanning.

[0246] When a small number of WTRUs access a cell or carrier, random access response control signaling can be used to reduce overhead. Since system information transmission overhead due to beam scanning can be high, system information responding to requests from WTRUs is sent via RACH Random Access Response (RAR) during RACH to reduce transmission overhead. This is advantageous when the number of WTRUs is small for the cell or beam.

[0247] The WTRU can use a preamble or RACH resource to request a SIB transmission. Subsequently, the terms preamble and RACH resource are used interchangeably. When the gNB receives the preamble, it can use a random access response in response to the SIB transmission (or system information). The preamble contains system information or SIB request information.

[0248] WTRUs can detect random access responses to obtain SIB transmissions. A PDCCH masked with a RA-RNTI can be used to schedule PDSCHs for SIB transmissions. When multiple WTRUs use the same time and frequency resources, the same RA-RNTI can be used by the WTRUs when transmitting PDCCHs. Therefore, multiple WTRUs can receive the same PDCCH with the same RA-RNTI. The WTRU requesting SIB transmission can attempt to decode the PDCCH with the RA-RNTI. Although the SIB is also transmitted to other WTRUs with the same RA-RNTI, other WTRUs can ignore the SIB by not decoding it. If other WTRUs also need the same SIB, system information can be shared among these WTRUs using random access responses.

[0249] In this implementation, the WTRU can request system information using only a preamble (e.g., preamble resources, preamble sequences, etc.). The requested system information is any one or a combination of the following: system information, system information set, SIB, and SIB set, etc. The system information is received during SIB transmission.

[0250] A preamble can carry or contain SIB request information, where different preambles (e.g., resources or sequences) can indicate different SIB requests. For example, a preamble #x can be used to indicate or request SIB #x. As described herein, a preamble can be a preamble sequence, a preamble resource, or a combination of a preamble sequence and a preamble resource. A preamble resource can be any one of a preamble time resource, a preamble frequency resource, and a preamble spatial resource, or a combination thereof.

[0251] One or more preambles (e.g., one or more preamble sequences or preamble resources) can be used to indicate different SIB requests. For example, a preamble sequence #x can correspond to SIB#x, and the WTRU can use the preamble sequence #x to request SIB#x. When the WTRU wants to request SIB#x, the WTRU can select the preamble sequence #x and transmit the selected preamble sequence #x.

[0252] In another example, the preamble time resource #x can correspond to SIB#x, and the WTRU can use the preamble time resource #x to request SIB#x. When the WTRU wants to request SIB#x, it can select the preamble time resource #x and transmit the preamble sequence in the preamble time resource #x.

[0253] In another example, the preamble frequency resource #x can correspond to SIB#x, and the WTRU can use the preamble frequency resource #x to request SIB#x. When the WTRU wants to request SIB#x, it can select the preamble frequency resource #x and transmit the preamble sequence in the preamble frequency resource #x.

[0254] The terms preamble, preamble resource, PRACH resource, and RACH resource are used interchangeably.

[0255] There can be a correlation between the preamble and the SIB. There can also be a correlation between the preamble resource and the SIB. The preamble resource can be any one or a combination of the preamble time resource, the preamble frequency resource, and the preamble sequence.

[0256] Associations between preamble sequences and SIBs can be used. In one example association, a preamble can be associated with one SIB. A preamble sequence #x can be associated with SIB #x. When the WTRU wants to request SIB #x, it can select preamble sequence #x and transmit the selected preamble sequence. In another example association, a preamble can be associated with multiple SIBs. A preamble sequence #x can be associated with both SIB #x and SIB #y. When the WTRU wants to request either SIB #x or SIB #y, it can select preamble sequence #x and transmit the selected preamble sequence. In yet another example association, multiple preamble sequences can be associated with one SIB. Preamble sequences #x and #y can be associated with SIB #x. When the WTRU wants to request SIB #x, it can select either preamble sequence #x or #y and transmit either preamble sequence #x or #y. When using or implementing multiple preamble sequence transmissions, the WTRU can transmit both preamble sequences #x and #y.

[0257] Associations can be used between preamble time resources and SIBs. In one example association, a preamble time resource can be associated with one SIB. Preamble time resource #x can be associated with SIB #x. When the WTRU wants to request SIB #x, it can select preamble time resource #x and transmit it. In another example association, a preamble time resource can be associated with multiple SIBs. Preamble time resource #x can be associated with both SIB #x and SIB #y. When the WTRU wants to request either SIB #x or SIB #y, it can select preamble time resource #x and transmit it. In yet another example association, multiple preamble time resources can be associated with one SIB. Preamble time resources #x and #y can be associated with SIB #x. When the WTRU wants to request SIB #x, it can select either preamble time resource #x or #y and transmit it. When using or implementing multiple preamble time resource transmissions, WTRU can transmit the selected preamble in preamble time resources #x and #y.

[0258] Similarly, the association between preamble frequency resources and SIBs can be used. Likewise, the association between preamble time resources, preamble frequency resources, and preamble sequences and SIBs can be used.

[0259] If the WTRU is indicated to have a preamble (e.g., sequence, resource, etc.) associated with the SIB, the WTRU can use the preamble to request the SIB. If the WTRU is not indicated to have a preamble associated with the SIB, the WTRU can use the control field in the payload (e.g., RACH message 3) to request the SIB.

[0260] A single association or mapping can be used to indicate the association between the preamble and the SIB. A 1-bit association indicator can be used. The WTRU can indicate whether there is an association or not. For example, "1" can indicate "association" and "0" can indicate "no association".

[0261] Alternatively, more than one association or mapping can be used to indicate the association between the preamble and the SIB. An N-bit association indicator can be used. Two options are available. In one option, two indicators can be used: a first indicator (e.g., 1 bit) indicates "yes" or "no" association, and a second indicator (e.g., N bits) indicates which association should be used if the WTRU receives the first indicator indicating "yes" association. In another option, a single indicator (e.g., N bits) uses a combined encoding of "yes" and "no" associations with multiple associations. For example, a 2-bit single indicator can be used to indicate 3 associations. In the example, "00" can indicate "no" association, "01" can indicate "association 1", "10" can indicate "association 2", and "11" can indicate "association 3".

[0262] The association indication can be part of the RACH configuration and can be carried or included in broadcast signals or channels, such as synchronization signals (SS), residual minimum system information (RMSI), NR-PBCH, or other system information (OSI).

[0263] In one implementation, the WTRU may use a preamble with an additional control field, which is used to request additional system information or an SIB. The control field may or may not be attached to the preamble.

[0264] The control field can be sent separately from the preamble. The control field can be included in the payload (e.g., RACH message 3). For example, the preamble can be in one RACH message (e.g., RACH message 1) and the control field can be sent in another RACH message (e.g., RACH message 3).

[0265] Control fields can contain REQ or SIB request commands. One or more bits can be used in a control field (e.g., the SIB_REQ_ field (SIB_REQ_FIELD)) to indicate the number of SIBs. For example, a 5-bit control field can be used to indicate 20 SIBs. In another example, a preamble can be used to request system information or one or more SIBs, and the control field can be used to request additional system information or one or more additional SIBs.

[0266] In implementation, the WTRU can use a preamble with an attached control field, where the combined preamble and control field are used to request system information or SIB transmissions. The preamble can be divided into M preamble groups, each group indicating an SIB or SIB category. SIB categories can be based on priority or importance. For example, preamble group 1 can be used for necessary or urgent SIBs, and preamble group 2 can be used for SIBs in categories that are no longer necessary or urgent. In another example, preamble group 1 can be used for the most critical or urgent SIBs, preamble group 2 can be used for moderately critical or less urgent SIBs, and preamble group 3 can be used for the least critical or low-priority SIBs. After indicating the SIB category, a control field can be used to indicate a specific SIB. One or more bits in the preamble can be used as control fields (e.g., the SIB_REQ_ field) to indicate the number of SIBs. For example, to indicate 18 SIBs across 3 preamble groups, where each preamble group has three SIB categories and each category has 6 SIBs, a 3-bit control field can be used to indicate the 6 SIBs in each category. Alternatively, the preamble and preamble group can be used together to indicate the SIBs.

[0267] In implementation, the WTRU may use SR, MAC control element (CE), PUCCH, PUSCH or another UL signal to request system information or SIB transmission.

[0268] In this implementation, system information is multiplexed before being transmitted by signal. For example, necessary and unnecessary system information can be multiplexed together with other signals (such as a synchronization (SYCH) signal).

[0269] Since the information on different beams is identical, the broadcast channel (BCH) can use transmit or beam diversity. For example, cyclic delay diversity (CDD), STBC, SFBC, etc., can be used. Furthermore, gNB or TRP can use a combination of transmit diversity in different subbands to transmit different broadcast beams.

[0270] After the WTRU obtains synchronization and the NR cell ID, it can decode the PBCH to obtain necessary system information. To support fast access, the same PBCH can be repeated on multiple beams. Within the same beam, the time-frequency resources used for the PBCH can be linked with the SS. The PBCH and SS can be within the same SS / PBCH block. The PBCH and SS can be multiplexed in either FDM or TDM. In the TDM scheme, the frequency resources used to carry the PBCH and SS can be minimized to support WTRUs with narrow bandwidth. In the FDM scheme, access latency can be reduced, but a larger minimum bandwidth may be required for the WTRU.

[0271] In this implementation, if there is no scheduled UL control channel, the periodic SR is used to request SIB transmissions. For example, in an SR with QPSK, the first bit indicates the SR and the second bit indicates SIB_REQ.

[0272] In this implementation, if a UL control channel is scheduled, WTRU-specific uplink control signals are used to request SIB transmission. For example, a PUCCH can be used to transmit the SIB request. PUCCH format X can be used for the SIB request, and PUCCH format X includes a control field (i.e., SIB_REQ) for the SIB request. The control field can be a 1-bit control field. If a PUSCH is scheduled in the same time slot in the uplink, the control field for the SIB request can be piggybacked in the data channel and transmitted in the PUSCH instead of in the PUCCH.

[0273] Figure 19 A flowchart illustrating an example of a method for sending system information via signals in response to a request from a WTRU, used in a gNB and one or more WTRUs.

[0274] As described above and in procedure 1900, the gNB can broadcast a signal 1910 including system information. The broadcast signal can be transmitted in one or more directional beams. The broadcast signal can be an always-on signal. The broadcast signal can be transmitted on the PBCH or a similar channel. The broadcast signal can also be transmitted on a channel carrying residual minimum system information (e.g., NR-PDSCH). The system information included in the broadcast signal can provide configuration information, including any one or a combination of resource allocation, mapping information, resource indication, and mode indication guiding WTRU behavior. The configuration information can include indications of whether the WTRU can transmit a request signal, a feedback signal, or neither, or a combination thereof, to the gNB. The configuration information can allow the WTRU to request system information or one or more SIB transmissions. The configuration information can be part of or different from the RACH configuration. The configuration information can be carried or included in the broadcast signal or channel, such as a synchronization signal (SS), residual minimum system information (RMSI), NR-PBCH, or other system information (OSI). The system information can be referred to as first system information or residual minimum system information.

[0275] The WTRU can receive system information 1920 from the broadcast signal. The WTRU then uses the broadcast signal to determine configuration information to request system information 1930. In the example, the WTRU determines whether it transmits a request signal, a feedback signal, or neither, or a combination thereof, to the gNB in ​​the signal.

[0276] The WTRU uses configuration information associated with the received system information to transmit signal 1940. In one implementation, the transmitted signal is a request signal. The transmitted signal may include a preamble. The preamble may be referred to as a preamble sequence or a preamble time / frequency resource. The preamble in the transmitted signal may contain or indicate system information request information. The preamble may be associated with one or more SIBs. In one implementation, the preamble is associated with one or more SIB groups, and each SIB group may be associated with a priority level. In one implementation, the transmitted signal includes a control field indicating additional SIB request information. The transmitted signal may include either a preamble or a control field, or a combination thereof.

[0277] The gNB receives a signal from the WTRU at 1950 and then transmits system information to the WTRU at 1960. System information received in response to the transmitted signal can be received periodically at predefined time locations. Alternatively, system information received in response to the transmitted signal can be received non-periodically based on the transmitted signal. The transmitted system information can be referred to as second system information or other system information transmissions (SIB).

[0278] Although the features and elements have been described above in specific combinations, each feature or element can be used alone without other features or elements, or in various combinations with or without other features and elements. For example, in an implementation, the WTRU can be configured to transmit to the gNB any one or a combination of feedback signals, request signals, and preambles to request system information transmission or SIB.

[0279] Although the solutions described in this application take into account LTE, LTE-A, NR or 5G specific protocols, it is understood that the solutions described in this application are not limited to this scenario and can also be applied to other wireless systems.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: selecting a beam from a plurality of beams from a base station; receiving periodically transmitted broadcast information using the selected beam, the periodically transmitted broadcast information comprising a first information block and a second information block; transmitting a random access preamble based on information in the received second information block; receiving a random access response after the transmitting of the random access preamble; transmitting a message comprising control information based on information in the received random access response, the control information indicating an additional information block that the WTRU requests to receive; and receiving the additional information block after the transmitting of the transmitted message. The transmitted first information block is transmitted with a primary synchronization signal and a secondary synchronization signal.

2. The method of claim 1, wherein, The first information block is a master information block (MIB), the second information block is a system information block (SIB) type 1 (SIB 1), the additional information block is an additional SIB, and the transmitted message is a message 3 (MSG 3).

3. The method of claim 1, wherein, The transmitted message is transmitted to the base station to request the additional information block on demand.

4. The method of claim 1, wherein, 5. The method of claim 1 wherein the base station transmits using the plurality of beams and the WTRU searches the plurality of beams to select the beam and the transmitted random access preamble is associated with the selected beam.

6. The method of claim 5 further comprising: transmitting information requesting a beam and receiving data using one of the requested beams. At least the first information block is scanned on the plurality of beams.

7. The method of claim 5, wherein, 8. A wireless transmit / receive unit (WTRU) comprising: a transceiver; and a processor operably coupled to the transceiver; wherein: the transceiver and the processor are configured to select a beam from a plurality of beams from a base station; the transceiver is configured to receive periodically transmitted broadcast information using the selected beam, the periodically transmitted broadcast information comprising a first information block and a second information block; the transceiver and the processor are configured to transmit a random access preamble based on information in the received second information block; the transceiver is configured to receive a random access response after the transmitting of the random access preamble; the transceiver and the processor are configured to transmit a message comprising control information based on information in the received random access response, the control information indicating an additional information block that the WTRU requests to receive; and the transceiver is configured to receive the additional information block after the transmitting of the transmitted message.

9. The WTRU of claim 8 wherein the transmitted first information block is transmitted with a primary synchronization signal and a secondary synchronization signal.

10. The WTRU of claim 8 wherein the first information block is a master information block (MIB), the second information block is a system information block (SIB) type 1 (SIB 1), the additional information block is an additional SIB, and the transmitted message is a message 3 (MSG 3). ​ ​ ​ 11. The WTRU of claim 8 wherein the transmitted message is transmitted to the base station to request additional blocks of information on demand.

12. The WTRU of claim 8 wherein the base station transmits using the plurality of beams and the WTRU searches the plurality of beams to select the beam and the transmitted random access preamble is associated with the selected beam.

13. The WTRU of claim 12 wherein the transceiver and the processor are further configured to transmit information requesting beams and the transceiver is further configured to receive data using one of the requested beams.

14. The WTRU of claim 12 wherein at least the first block of information is scanned on the plurality of beams.

Images