Method and apparatus for performing a physical layer mobility procedure

Abstract

Methods are described herein for performing, maintaining, and reporting measurements about a Transmission-Receiving Point (TRP) using limited reference signal transmissions. Mobile measurement reports may utilize physical channels. Also described herein are methods for obtaining measurements about neighbor TRPs using limited RS transmissions. Also described herein are random access procedures that may enable the addition or switching of neighbor TRPs without the need for higher layer signaling (and potentially without the need for an interface between the source TRP and the target TRP). Also described herein are new triggers for performing RAs, thereby reducing switching latency. Also described herein are wireless transmit / receive unit (WTRU) behavior when receiving RARs from multiple possible TRPs. For example, the WTRU may store the RAR information and use it later in an interrupted RA process.

Description

[0001] This application is a divisional application of Chinese patent application 201780031361.4, entitled “Method and device for performing physical layer mobility process”, filed on March 30, 2017.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 315,080, filed on March 30, 2016, and U.S. Provisional Application No. 62 / 334,630, filed on May 11, 2016, the contents of both of which are hereby incorporated by reference herein in their entirety. Background Art

[0004] Mobile communications technology is evolving and is on the eve of its fifth generation, 5G. As with previous generations, new use cases contribute primarily to setting requirements for new systems. It is expected that the 5G air interface will enable at least the following use cases: (1) improved broadband performance (IBB); (2) industrial control and communications (ICC) and vehicle-to-everything (V2X); and (3) massive machine-type communications (mMTC). The above use cases translate into a number of requirements on the 5G interface that should be balanced and optimized. Summary of the invention

[0005] A method and wireless transmit / receive unit (WTRU) for performing switching between multiple coordinated transmission-reception points (TRPs) are disclosed. The method begins by measuring a first reference signal (RS) of a first TRP of the multiple coordinated TRPs and a second RS of a second TRP of the multiple coordinated TRPs. Thereafter, the WTRU receives permission to transmit to the coordinated TRP. Next, the WTRU transmits to the first TRP of the multiple coordinated TRPs; and based on the first RS, the second RS, and environmental changes, determines whether to transmit to the second TRP of the multiple coordinated TRPs instead of the first TRP of the multiple coordinated TRPs.

[0006] A method and WTRU for performing a random access procedure are also disclosed. The method begins by performing a random access procedure for a plurality of coordinated TRPs using the same resources for each TRP. Thereafter, the WTRU receives at least one random access response (RAR). Based on the received responses, the WTRU selects a random access response of a particular TRP among the plurality of coordinated TRPs to continue the random access procedure and stores the contents of the remaining access responses. Thereafter, the WTRU continues the random access procedure with the particular TRP. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0008] Figure 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

[0009] Figure 1B Yes, you can Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0010] Figure 1C Yes, you can Figure 1A A system diagram of an example radio access network and an example core network used within the communication system shown;

[0011] Figure 2 is a block diagram of examples of different transmission bandwidths;

[0012] Figure 3 is a block diagram of a system bandwidth utilizing flexible spectrum allocation;

[0013] Figure 4 It is a block diagram about the frame structure and timing relationship of TDD duplex;

[0014] Figure 5 It is a block diagram about the frame structure and timing relationship of TDD duplex;

[0015] Figure 6 A flow chart showing a move process; and

[0016] Figure 7 is a schematic diagram of the architecture of TRP mobile with different steps in the mobile process. DETAILED DESCRIPTION

[0017] Figure 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may allow multiple wireless users to access the content by sharing system resources including wireless bandwidth. As an example, the communication system 100 may 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), etc.

[0018] 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 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, however, it should be understood that the disclosed embodiments may 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, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and the like.

[0019] The communication system 100 may also include a base station 114a and a base station 114b. The base stations 114a, 114b may each be any type of device configured to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and / or other networks 112, by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. The base stations 114a, 114b may be, by way of example, a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0020] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area called a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and thus multiple transceivers may be used for each sector in the cell.

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

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

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

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio access technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0025] As an example, Figure 1AThe base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area such as a business location, a residence, a vehicle, a campus, or the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the core network 106.

[0026] The RAN 104 may be in communication with a core network 106, which may be any type of network configured to provide voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although Figure 1A Although not shown, it will be appreciated that the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs, and that these RANs may employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may employ E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing GSM radio technology.

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

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

[0029] Figure 1B is a system diagram of an example WTRU 102. Figure 1B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0030] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which in turn may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into an electronic package or chip.

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

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

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

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

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

[0036] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable positioning method while remaining consistent with an embodiment.

[0037] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game console module, an Internet browser, and the like.

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

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

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

[0041] Figure 1C The illustrated core network 106 may include a mobile management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing components are depicted as being part of the core network 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the core network operator.

[0042] The MME 142 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processing, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

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

[0044] The serving gateway 144 may also be connected to a PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0045] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks such as the PSTN 108 to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include or be in communication with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, which may serve as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0046] The other networks 112 may also be connected to a wireless local area network (WLAN) 160 based on IEEE 802.11. The WLAN 160 may include an access router 165. The access router 165 may include a gateway function. And the access router 165 may communicate with multiple access points (APs) 170a, 170b. The communication between the access router 165 and the APs 170a, 170b may be carried out via wired Ethernet (IEEE 802.3 standard) or any type of wireless communication protocol. The AP 170a wirelessly communicates with the WTRU 102d over an air interface.

[0047] The following abbreviations and acronyms are set forth for reference.

[0048] ∆f subcarrier spacing

[0049] 5gFlex 5G Flexible Radio Access Technology

[0050] 5gNB 5GFlex Node B

[0051] ACK

[0052] BLER Block Error Rate

[0053] BTI Basic TI (an integer multiple of one or more symbol durations)

[0054] CB contention-based (e.g. access, channel, resource)

[0055] CoMP coordinated multi-point transmission / reception

[0056] CP cyclic prefix

[0057] CP-OFDM Conventional OFDM (depends on cyclic prefix)

[0058] CQI Channel Quality Indicator

[0059] CN core network (e.g. LTE packet core)

[0060] CRC Cyclic Redundancy Check

[0061] CSI channel state information

[0062] D2D device-to-device transmission (e.g. LTE sidelink)

[0063] DCI downlink control information

[0064] DL Downlink

[0065] DM-RS Demodulation Reference Signal

[0066] DRB Data Radio Bearer

[0067] EPC Evolved Packet Core

[0068] FBMC filter bank multi-carrier

[0069] FBMC / OQAM uses FBMC technology with offset quadrature amplitude modulation

[0070] FDD Frequency Division Duplex

[0071] FDM Frequency Division Multiplexing

[0072] ICC Industrial Control and Communications

[0073] ICIC Inter-Cell Interference Cancellation

[0074] Internet Protocol (IP)

[0075] LAA Authorization Assisted Access

[0076] LBT listens first and speaks later

[0077] LCH logical channel

[0078] LCP logical channel prioritization

[0079] LTE long-term evolution, such as 3GPP LTE R8 and above

[0080] MAC Media Access Control

[0081] NACKNegative ACK

[0082] MC Multi-Carrier

[0083] MCS modulation and coding scheme

[0084] MIMO Multiple Input Multiple Output

[0085] MTC Machine Type Communication

[0086] NAS non-access layer

[0087] OFDM Orthogonal Frequency Division Multiplexing

[0088] OOB Out-of-Band (Radiated)

[0089] P cmax Total available WTRU power in a given TI

[0090] PHY physical layer

[0091] PRACH Physical Random Access Channel

[0092] PRB Physical Resource Block

[0093] PRG Precoding Resource Group

[0094] PDU protocol data unit

[0095] PER Packet Error Rate

[0096] PLR Packet Loss Rate

[0097] PMI precoding matrix indicator

[0098] PTI precoding type indicator

[0099] QoS Quality of Service (from the perspective of the physical layer)

[0100] RAB Radio Access Bearer

[0101] RACH Random Access Channel (or process)

[0102] RF Radio Front End

[0103] RNTI Radio Network Identifier

[0104] RRC Radio Resource Control

[0105] RRM Radio Resource Management

[0106] RS reference signal

[0107] RTT Round Trip Time

[0108] SCMA Single Carrier Multiple Access

[0109] SDU Service Data Unit

[0110] SOM spectrum working mode

[0111] SS sync signal

[0112] SRB Signalling Radio Bearer

[0113] SWG switching gap (in self-contained subframe)

[0114] TB transfer block

[0115] TDD Time Division Duplex

[0116] TDM Time Division Multiplexing

[0117] TI time interval (one or more integer multiples of BTI)

[0118] TTI transmission time interval (one or more integer multiples of TI)

[0119] TRx transceiver

[0120] UFMC Universal Filtered Multi-Carrier

[0121] UF-OFDM Universal Filtering OFDM

[0122] UL Uplink

[0123] V2V vehicle-to-vehicle communication

[0124] V2X vehicle communication

[0125] WLAN Wireless Local Area Network and related technologies (IEEE 802.xx field)

[0126] In LTE, the WTRU may be configured to perform higher layer measurements that may initiate mobility. The WTRU may perform measurements on a cell-specific reference signal (CRS) that is within a discovery reference signal (DRS) or that is periodically transmitted. In addition, the WTRU may perform measurements on symbols within a DRS or symbols of a CRS. The WTRU may be configured to obtain the measurements and report the results.

[0127] The WTRU may be configured to report measurements based on one or more measurement-based triggers. The WTRU may be configured to obtain and report reference signal received power (RSRP) measurements. To obtain RSRP, the WTRU may measure the received power on the CRS. The WTRU may also be configured to obtain and report CSI-RSRP measurements. To obtain CSI-RSRP, the WTRU may be configured to measure the received power on the CSI-RS resources. The WTRU may be configured to obtain and report reference signal strength indicator (RSSI) measurements. The RSSI may be a measure of the total power observed on a complete symbol. The complete symbol may be a symbol with a CRS, or may be all symbols of a subframe containing a CRS. The WTRU may be configured to obtain and report reference signal received quality (RSRQ) measurements. The RSRQ may be obtained based on RSRP and RSSI measurements. If the RSRQ is based on RSRP and RSSI, the RSSI may be used as a proxy for determining the average amount of interference on a frequency.

[0128] In LTE, the WTRU can blindly detect the PSS / SSS to determine the presence of a cell. Based on the PSS / SSS, the WTRU can obtain frequency and symbol synchronization of the cell, obtain the frame timing of the cell, and determine the physical layer cell identity. Based on the physical layer cell identity, the WTRU can determine the CRS configuration. The CRS enables the WTRU to perform measurements on the cell and also demodulate transmissions from the cell.

[0129] The WTRU may also obtain system information from the cell. The system information may be divided into several parts, which may include a master information block (MIB) and a system information block (SIB). The MIB may be transmitted using a broadcast channel (BCH). The SIB may be transmitted using a downlink shared channel (DL-SCH).

[0130] Based on the MIB, the WTRU may determine information about the DL bandwidth of the cell, information about the PHICH configuration, and the system frame number (SFN). Based on the SIB, the WTRU may determine whether it can access the cell. The WTRU may also obtain information for accessing the cell from the SIB. The information for accessing the cell may include UL cell bandwidth, random access parameters, and parameters related to UL power control.

[0131] A WTRU may perform a random access (RA) to a cell for different purposes. A RA may be used for initial access, such as when establishing a radio link to a cell. A RA may also be used to reestablish a radio link with the cell after an initial link failure. A RA may also be used to establish UL synchronization or for handover, such as when UL synchronization is required. A RA may also be used for positioning, or a RA may be used as a scheduling request.

[0132] Random access may be performed by the WTRU, which may start a RA session by transmitting a preamble on a PRACH resource to the cell. The cell may detect the preamble transmission. If detected, the cell transmits a random access response (RAR). The RAR may contain an index to the RA preamble, the detected network, a timing correction, a scheduling grant to be used by the WTRU, and a temporary identifier for further communication between the WTRU and the network. The WTRU may then transmit the necessary messages to the eNB by using the UL-SCH resources assigned within the RAR. The UL-SCH resources may contain a terminal identifier, which may be used to initiate contention resolution that may be required. Contention resolution may then occur, which may include sending a message on the PDCCH using the WTRU's identifier, or may include a DL-SCH with a terminal identifier.

[0133] The 5G air interface may need to support improved bandwidth performance (IBB) over previous generation networks. The 5G air interface may also need to support industrial control and communications (ICC) or vehicle-to-everything (V2X). The 5G air interface may also be expected to support massive machine-type communications (mMTC).

[0134] The 5G air interface may also need to support baseband filtering of frequency domain waveforms. When designing the interface for this potential need, baseband filtering of frequency domain waveforms may be beneficial in enabling the ability to achieve efficient aggregation of up to 150-200MHz of total spectrum within a given RF transceiver path without relying on a redesign of the front end of the interface.

[0135] The 5G interface may be implemented using spectrum with very sparse operating bands (e.g., 900 MHz and 3.5 GHz), which may require multiple RF transceiver chains. This may be necessary due to antenna size requirements and amplifier optimization design constraints (which may be different for different operating bands). This may result in the need for multiple antennas within the WTRU device. For example, a WTRU designed to operate within a 5G network at different frequencies may require 3 different RF transceiver paths: for example, 1 below 1 GHz, another for the 1.8-3.5 GHz frequency range, and another covering the 4-6 GHz frequency range. Native built-in support for massive MIMO antenna configurations is also a very important secondary requirement.

[0136] 5G systems may also support ultra-low transmission latency, such as air interface latency as low as 1 ms RTT. Latency requirements like this may require support for TTIs between 100 microseconds and 250 microseconds. In addition, support for ultra-low access latency (which may be the time from initial system access to the completion of the first user plane data unit transmission) may also be needed or desired. For example, end-to-end (e2e) latency of less than 10 milliseconds may be required.

[0137] 5G systems may also support transmission reliability that is lower (perhaps significantly lower) than that achievable by LTE systems. 99.999% transmission success rate and service availability may be required or desired. In addition, support for mobility in the speed range of 0-500 km / h may be required, along with a reduced packet loss rate, such as less than 10e -6 The packet loss rate.

[0138] 5G systems may also support MTC operations (including narrowband operations). 5G networks may also support narrowband operations (e.g., using bandwidths less than 200KHz). Extended battery life (potentially extending to years) may also be supported. Reduced communication overhead for small and infrequent data transmissions (potentially including low data rates in the range of 1-100kbps with access delays of seconds to hours) may also be supported.

[0139] mMTC will likely require the system to support narrowband operation. The resulting link budget should be comparable to that of LTE extended coverage, but the system will support a very large number of MTC devices (potentially up to 200,000 devices per square kilometer) without adversely affecting the spectral efficiency of other supported services.

[0140] The above requirements can be met by designing a 5G network according to the design features described herein. For example, a 5G system can be designed to enable flexible spectrum utilization, deployment strategies, and operations. The system can be designed to support spectrums of variable sizes (which can be achieved by using multiple frequency ranges simultaneously or by rapidly alternating multiple frequency ranges), and can include the use of multi-carrier networks in the same and / or different frequency bands (for example, frequency bands that can be licensed, unlicensed, or a mixture of the two). The system can also support narrowband and broadband operations, different duplexing methods, dynamically variable DL / UL allocations, variable TTI lengths, scheduled and unscheduled transmissions, synchronous and asynchronous transmissions, separation of the user plane from the control plane, and multi-node connections.

[0141] The 5G system may also be designed to integrate with aspects of the legacy (E-)UTRAN and EPC / CN. While the system may not need to be backward compatible, the system may be required to integrate and / or interwork with legacy interfaces or evolutions of legacy interfaces (which may include legacy CNs, such as the SI interface or NAS, and eNBs, such as dual connectivity and X2 interfaces with LTE). The system may also need to enable legacy aspects of previous generations of networks, such as support for existing QoS and security mechanisms.

[0142] Some elements of the 5G design may be retrofitted in LTE evolution, which may allow backward compatibility for some or all components. For example, TTIs shorter than the 0.5 ms LTE slots may be used (by using different waveforms to enable ultra-low latency). Support for D2D / sidelink operation may also be implemented. Support for LAA operation using LBT and support for relaying may also be implemented.

[0143] OFDM is the basic signal format used for data transmission in LTE and IEEE 802.11 networks. OFDM effectively divides the spectrum into multiple parallel orthogonal sub-bands. Each sub-carrier is shaped in the time domain using a rectangular window, resulting in a sinusoidal shaped sub-carrier in the frequency domain. Because of this, OFDMA requires perfect frequency synchronization and tight uplink timing alignment management within the cyclic prefix, which maintains orthogonality between signals and minimizes inter-carrier interference. This tight synchronization is not so suitable in systems where the WTRU is connected to multiple access points simultaneously. Additional power reduction is also typically applied to uplink transmissions to meet spectrum emission requirements for adjacent bands, which is very helpful when dealing with segmented spectrum for WTRU transmissions.

[0144] Some of the shortcomings of conventional OFDM (CP-OFDM) can be addressed by imposing more stringent RF requirements for implementation, which is helpful in cases where large amounts of contiguous spectrum are used for operation without aggregation. CP-based OFDM transmission schemes may also result in changes to the downlink physical layer of the 5G system, which may be similar to the downlink physical layer of legacy systems, perhaps mainly in changes to the pilot signal density and location.

[0145] Due to the differences in requirements and use cases between new 5G networks and legacy systems, including fragmented spectrum allocation, the 5gFLEX design is likely to focus on other waveform candidates. However, conventional OFDM will still be a possible candidate for 5G systems, at least for downlink transmission schemes. A design for flexible radio access for 5G built on OFDMA and legacy LTE systems is proposed here.

[0146] The 5gFLEX downlink transmission scheme is based on a multi-carrier waveform characterized by high spectral suppression (low side lobes and low OOB emissions). Possible MC waveform candidates for 5G include OFDM-OQAM and UFMC (UF-OFDM).

[0147] The multi-carrier modulation waveform can divide the channel into sub-channels and modulate the data symbols on the sub-carriers within these sub-channels. For OFDM-OQAM, filters can be applied to the OFDM signal in the time domain according to the sub-carriers to reduce OOB. OFDM-OQAM produces little interference to adjacent bands, does not require a large guard band, and does not require a cyclic prefix. However, OFDM-OQAM is very sensitive to multipath effects and high delay spread in terms of orthogonality, which complicates the equalization and channel estimation process.

[0148] For UFMC (UF-OFDM), filters are also applied to OFDM signals in the time domain to reduce OOB. The filtering process is applied per subband to use spectrum segmentation, thereby reducing complexity. However, if there are unused spectrum segments in the band, the OOB emissions in these segments may remain as high as conventional OFDM. In other words, UF-OFDM improves over OFDM only at the edges of the filtered spectrum. No improvement is seen in the spectral holes.

[0149] The methods described herein are not limited to the above waveforms, but can be applied to other waveforms. The above waveforms will be used further below, and it should be understood that they are exemplary only. These waveforms enable multiplexing within the frequency of signals with non-orthogonal characteristics (e.g., different subcarrier spacings), and can enable coexistence of asynchronous signals without the need for complex interference cancellation receivers. The method can also facilitate segmented spectrum aggregation in baseband processing as part of RF processing as a low-cost alternative to its implementation.

[0150] Coexistence of different waveforms in the same frequency band may be considered, for example, support for mMTC narrowband operation using SCMA may be considered. Another example of coexistence of different waveforms within the same frequency band may be supported, where there is a combination of different waveforms within the same frequency band, which may include CP-OFDM, OFDM-OQAM, and UF-OFDM, and this may be used for all aspects and for downlink and uplink transmissions. This coexistence may include transmissions using different types of waveforms between different WTRUs, or transmissions from the same WTRU, where the transmissions may be simultaneous or continuous in the time domain with some overlap.

[0151] Other ways to improve coexistence may include support for mixed types of waveforms, including waveforms and / or transmissions that support at least one of the following: a CP duration that may change (e.g., changes with transmission). A combination of a CP with a low-power tail (e.g., a zero tail) may also improve coexistence. A mixed guard interval format may also improve coexistence and may include the use of a low-power CP and an adaptive low-power CP. Similar improvements may also be used. The waveform may support dynamic changes and / or control of further design options, which may include filtering options, such as whether to apply filtering at the edge of the spectrum for receiving any transmission for a given carrier frequency, at the edge of the spectrum for receiving transmissions associated with a specific SOM, or according to subcarriers or groups thereof. The uplink transmission scheme may use the same or different waveform as the waveform used for downlink transmissions. The multiplexing of transmissions to and from different WTRUs in the same cell may be based on FDMA and TDMA.

[0152] The 5gFLEX radio access design can be characterized by spectrum flexibility, where the spectrum flexibility enables deployment in different frequency bands with different characteristics, which may include different duplex arrangements. Different and / or variable sizes of available spectrum can also be used, where the spectrum includes contiguous and non-contiguous spectrum allocations in the same or different frequency bands. The radio access design can support variable timing aspects, including support for multiple TTI lengths and support for asynchronous transmissions.

[0153] Both TDD and / or FDD duplex schemes are supported. For FDD operation, supplemental downlink operation is supported using spectrum aggregation. FDD operation can support full-duplex FDD, half-duplex FDD operation, or both. For TDD operation, DL / UL allocation is dynamic and not based on a fixed DL / UL frame configuration. The length of the DL or UL transmission interval can be set based on the transmission opportunity.

[0154] exist Figure 2 , examples of different transmission bandwidths are shown. The 5gFLEX design may allow for different transmission bandwidths on the uplink, downlink, or both. The transmission bandwidth may range from the nominal system bandwidth 201 (e.g. Figure 2 5 MHz as shown) to system bandwidth 202 (as shown at 20 MHz). Three examples of UE channel bandwidths are shown, namely, UEx channel bandwidth 203 shown at 10 MHz, UEy channel bandwidth 204 shown at 20 MHz, and UEz channel bandwidth 205 shown at 5 MHz. Other UE channel bandwidths between nominal bandwidth 201 and system bandwidth 202 may also be used.

[0155] For single carrier operation, the supported system bandwidths may include at least 5, 10, 20, 40 and 80 MHz. The supported system bandwidths may include any bandwidth within a specified range (e.g., from a few megahertz to 160 MHz). The nominal bandwidth 201 may have one or more fixed possible values. Narrowband transmissions up to 200 KHz may be supported within the operating bandwidth of the MTC device.

[0156] As used herein, system bandwidth 202 may refer to the maximum portion of the spectrum that the network can manage for a carrier. For such a carrier, the portion that a WTRU minimally supports for cell acquisition, measurements, and initial access to the network may be referred to herein as the nominal system bandwidth 201. A WTRU may be configured with a channel bandwidth 203, 204, or 205 that is within the range of the total system bandwidth 202. The channel bandwidth configured for a WTRU may or may not include, for example, Figure 2 The nominal portion of the system bandwidth is shown, where UEx channel bandwidth 203 and UEy channel bandwidth 204 comprise the nominal portion of system bandwidth 201 , but UEz channel bandwidth 205 differs from the nominal system bandwidth 201 of 5 MHz by 5 MHz.

[0157] For a given maximum operating bandwidth within a band, bandwidth flexibility is achieved because all applicable RF requirement sets can be met without introducing additional allowed channel bandwidth for the operating band. Bandwidth flexibility is facilitated by efficient support for baseband filtering of frequency domain waveforms.

[0158] The 5gFLEX physical layer may be band agnostic and may support operation in licensed bands below 5 GHz and / or in unlicensed bands in the 5-6 GHz range. For operation in unlicensed bands, a LBT Cat 4-based channel access framework similar to LTE LAA may be supported.

[0159] Flexible spectrum allocation may be achieved. Downlink control channels and signals may support FDM operation. The WTRU may acquire a downlink carrier by receiving transmissions using only a nominal portion of the system bandwidth. For example, the WTRU may not initially need to receive transmissions covering the entire bandwidth managed by the network for a particular carrier.

[0160] The downlink data channel may be allocated at a bandwidth that corresponds or does not correspond to the nominal system bandwidth and has no restrictions other than being within the channel bandwidth configured for the WTRU. For example, a network may operate a carrier with a 12 MHz system bandwidth using a nominal bandwidth of 5 MHz. This may allow WTRUs that only support a maximum RF bandwidth of 5 MHz to acquire and access the system, but may also allocate carrier frequencies from +10 to -10 MHz to other WTRUs that support channel bandwidths up to 20 MHz.

[0161] Figure 3 308 and 309. The SOM may also be defined by the TTI length. The SOM may also be defined by one or more reliability features, which may include HARQ processing or auxiliary control channels. In some cases, the SOM may be used to refer to a specific waveform or to relate to processing features (which may be used to support the coexistence of different waveforms in the same carrier by using FDM and / or TDM). The processing features may also be used when coexistence of FDD operation within a TDD band (which may be in a TDM manner or similar manner) is supported. The variable transmission characteristics 307 may also be used within the nominal system bandwidth 301 and / or the system bandwidth 302.

[0162] Single carrier operation may support spectrum aggregation, whereby the WTRU supports transmission and / or reception of multiple transport blocks on contiguous and / or non-contiguous sets of physical resource blocks (PRBs) within the same operating band. Mapping of a single transport block to different sets of PRBs may also be used to support spectrum aggregation.

[0163] Multi-carrier operation can be supported using contiguous or non-contiguous spectrum blocks within the same operating band or across two or more operating bands. Aggregation of spectrum blocks using different modes (e.g., FDD and TDD) or using different channel access methods (i.e., licensed and unlicensed band operation below 6 GHz) can also be supported.

[0164] Methods for configuring, reconfiguring and / or dynamically changing the multi-carrier aggregation of a WTRU are very helpful in supporting frequency band aggregation of multiple carriers within a single WTRU. Flexible framework formulation, timing and synchronization can be one way of dynamic reconfiguration.

[0165] An example of a frame structure for flexible framing, timing, and synchronization is shown in FIG. Figure 4 And for FDD Figure 5 Downlink and uplink transmissions may be organized into radio frames 410 / 510 characterized by fixed characteristics (eg, location of downlink control information) and / or varying characteristics (eg, transmission timing or supported transmission types).

[0166] A basic time interval (BTI) 411 / 511 is represented by an integer number of one or more symbols, where the symbol duration may depend on the subcarrier spacing applicable to the time-frequency resource. For FDD, the subcarrier spacing is thus 1 / 2 of the uplink carrier frequency f for a given frame. UL With the downlink carrier frequency f DL There are differences between Figure 5 As shown. Figure 4 As shown, for TDD, f UL With f DL The same or a combination of subcarrier spacings may be used, such as f UL+DL as shown.

[0167] The transmission time interval (TTI) may be the minimum time between consecutive transmissions supported by the system, where each transmission is associated with a different transport block (TB). DL , and associated with uplink UL TRx. Continuous transmissions may exclude preambles and may contain downlink control information (DCI) or uplink control information (UCI). A TTI may be represented by an integer number of one or more BTIs 411 / 511. A BTI 411 / 511 may be specific to or associated with a specified SOM.

[0168] The method may support multiple frame durations, which may be expressed in microseconds or milliseconds, and may include 100us, 125us (which may also be expressed as 1 / 8ms), or 142.85us (which may also be expressed as 1 / 7ms, which is 2 nCPLTE OFDM symbols). The method may also support a frame duration of 1 ms, thereby enabling alignment with the legacy LTE timing structure.

[0169] Each frame may start with a fixed duration T DCI Downlink control information (DCI), which may be followed by the carrier frequency (f for TDD) UL+DL , and f for FDD DL ) for downlink data transmission (DL TRx).

[0170] For TDD duplexing, a frame may include a downlink portion (DCI and DL TRx) and may also include an uplink portion (UL TRx) 219. A switching time slot (SWG) may precede the uplink portion of the frame.

[0171] For FDD-only duplex, a frame may contain a downlink reference TTI and one or more TTIs for the uplink. The start of the uplink TTI may be determined using an offset (t offset ), the offset may be applied from the start of a downlink reference frame overlapping with the start of an uplink frame.

[0172] For TDD, the 5gFLEX network can support D2D / V2x / sidelink operations within a frame by including corresponding downlink control and forward transmissions. If semi-static allocation of corresponding resources is used, downlink control and forward transmissions may be present in the DCI + DL TRx part. If dynamic allocation is used, they may only be present in the DL TRx part. The frame may also include corresponding reverse transmissions in the ULTRx part.

[0173] For FDD, the 5gFLEX network can support D2D / V2x / sidelink operations within the UL TRx portion of the frame by including the corresponding downlink control, forward and reverse transmissions within the UL TRx portion, using dynamic allocation of corresponding resources.

[0174] Scheduling functionality may be supported within the MAC layer. A network-based scheduling mode may be supported, which is useful for tight scheduling of resources, timing, and transmission parameters for downlink and / or uplink transmissions. WTRU-based scheduling may be supported, which is useful in situations where greater flexibility is required in timing and transmission parameters. For both modes, the scheduling information may be valid for a single or multiple TTIs.

[0175] Network-based scheduling enables the network to manage the available radio resources assigned to different WTRUs. This may help optimize the sharing of such resources. Dynamic scheduling may also be supported.

[0176] WTRU-based scheduling enables the WTRU to opportunistically access uplink resources within a shared or dedicated uplink resource set as needed with reduced latency. These uplink resources may be assigned dynamically or statically by the network. Synchronous opportunistic transmissions, asynchronous opportunistic transmissions, or both are supported. Contention-based transmissions and contention-free transmissions are also supported.

[0177] Support for opportunistic transmissions may be included. Opportunistic transmissions may be scheduled or unscheduled. Opportunistic transmissions are very useful for significantly reducing latency and / or saving power, which is very useful for meeting the requirements of 5G networks and / or mMTC use cases.

[0178] 5gFLEX networks may support logical channel prioritization, which may include an association between data available for transmission and available resources for uplink transmission. Multiplexing of data with different QoS requirements within the same transport block may be supported.

[0179] The transmission may be encoded using a variety of different coding methods for forward error correction and block coding, which may use different coding methods with different characteristics.

[0180] In one example, an encoding method can generate a series of information units. Each information unit or block can be self-contained so that errors in transmitting a first block do not impair the ability of a receiver to successfully decode a second block. This is useful if the second block is error-free and / or sufficient redundant information can be found in the second block or in a different block that at least a portion was successfully decoded.

[0181] Raptor / fountain codes may be used for encoding, whereby a transmission may consist of a series of N raptor codes. One or more such codes may be mapped in time to one or more transmission "symbols". A "symbol" may thus correspond to one or more sets of information bits (which may be one or more octets). Encoding using raptor / fountain codes may be used to add FEC to a transmission, whereby the transmission may use N+1 or N+2 raptor codes (or symbols, assuming a one-to-one raptor code-symbol relationship), whereby the transmission may be more resilient to the loss of a single "symbol", which may be due to interference or puncturing caused by other transmissions that overlap in time.

[0182] Reference signals may include synchronization signals and cell-specific reference signals. System information may include broadcast channels. 5G systems may need to operate with reduced periodic transmission of reference signals and / or system information. The reduction of reference signals and / or system information may have benefits such as reducing overall interference levels and / or reducing power consumption at a transmission-reception point (TRP).

[0183] In addition, it is also helpful in reducing the signaling overhead for common WTRU functions (such as mobility). The increased density of TRPs may greatly affect mobility. However, continuing to use the old WTRU behavior for mobility may result in overhead that will undermine the gains that can be achieved through ultra-dense deployment of TRPs.

[0184] Therefore, there is a need for a framework that enables a WTRU to maintain a connection with a set of TRPs. Therefore. There is also a need for the WTRU and the TRP to determine which TRP within the set of TRPs is the optimal TRP to serve the WTRU. This need can be met by one or more methods that enable the WTRU to maintain measurements on multiple TRPs with reduced reference signal and system information transmission overhead, so that the optimal serving TRP can be effectively determined and re-determined when appropriate. Further, there is a need for a method that enables the WTRU to perform movement between or within a set of TRPs with reduced signaling.

[0185] Methods are provided by which a WTRU can perform mobility between and within TRP sets without requiring higher layer control plane transmissions and with reduced interference between TRPs, which can reduce overall latency on the network during mobility operations. The reduced mobility latency can be beneficial for different scenarios such as eMBB, where lower latency when performing mobility can ensure more time is dedicated to high throughput transmission of data, and RULLC, where lower latency during mobility can provide reliability by ensuring that the WTRU is always connected to the best TRP.

[0186] The TRP may include network elements, such as cells, and / or WTRUs capable of D2D transmission and / or reception. The TRP may also indicate specific parameters about the network elements. For example, the TRP may indicate the beams on which the cell can transmit and / or receive. In another example, the TRP may indicate a resource set or a usage type (e.g., SOM, eMBB, URLLC, mMTC).

[0187] Figure 6 FIG. 4 is a flow chart of a process by which a WTRU receives RS configuration information from a source TRP that allows the WTRU to transmit to a target TRP. Figure 6 As shown, RS configuration 601 is sent from the source TRP to the WTRU. The RS configuration may be related to a coordinated TRP group. In box 602, the WTRU may perform measurements by using one or more RSs of one or more TRPs. The measurements may be of various types and may be related to the WTRU's ability to transmit to and / or receive from a serving TRP (e.g., source TRP) and / or a non-serving TRP (e.g., target TRP). Specific types of measurements will be discussed below. In box 603, the WTRU determines that at least one measurement satisfies a threshold. In box 604, the WTRU may perform random access with the target TRP by using resources determined based on the measured RS. In another example, in box 604, the WTRU performs random access with the target TRP by using pre-configured or predetermined resources. The resources may be pre-configured or predetermined based on previous instructions from the source TRP or from the target TRP.

[0188] In box 605, the WTRU receives a response with the resource grant. The resources may be used for UL transmissions, DL transmissions, or both, or may be used for other processes or procedures. In box 606, the WTRU indicates its own identity, which may include the WTRU's own context. In box 607, the source TRP and the target TRP perform inter-TRP coordination. This coordination may be used to determine which TRP will share which resources with the WTRU. In box 608, the WTRU successfully receives the transmission and updates the configuration about the serving TRP with information that may be related to the new resources granted to the WTRU by the target TRP.

[0189] In order for the WTRU or the network to determine that the WTRU may be optimally served by a particular TRP or set of TRPs, the WTRU may need to make measurements, and may need to make those measurements repeatedly, since the optimal TRP may change based on changing conditions (including mobility). Such measurements may include at least one of the measurement types discussed below.

[0190] For example, a WTRU may measure received power on a set of resources. The set of resources may be semi-static or may be dynamically indicated. Each serving TRP may have an independent set of resources on which the WTRU may measure received power. A set of TRPs (e.g., a TRP Group (TRPG)) may also share some resources on which the WTRU may make or maintain measurements.

[0191] The WTRU may measure the total received power over one or more symbols covering a predetermined or configurable bandwidth. The WTRU may determine the quality of the signal from the serving cell. One method for determining the reception quality may be to divide the received power by the signal strength.

[0192] The WTRU may also perform measurements on a configurable set of resources to determine the level of interference it experiences when served by a particular TRP on a particular set of resources. The WTRU may measure one type of interference, or may measure multiple types of interference. The WTRU may measure interference on signals from a TRP, interference on signals from any TRP within a TRPG, and / or interference on signals from all TRPs within a TRPG.

[0193] The WTRU may determine the signal to interference plus noise ratio (SINR) when served by at least one TRP. The WTRU may also perform measurements to determine channel occupancy. For example, the WTRU may have the ability to access an unlicensed channel.

[0194] The TRP load may be measured. The TRP load may be measured using DL channel usage, UL channel usage, or both.

[0195] In order to make measurements on one or more serving TRPs, the WTRU may first determine the resources on which it can make measurements. For example, the WTRU may autonomously look for a signal transmitted by the TRP that enables the WTRU to make measurements that meet the appropriate requirements. The WTRU may also be notified of the resources on which it can make measurements. This notification may occur dynamically.

[0196] The WTRU may determine the presence of a signature sequence autonomously and / or based on predetermined rules. For example, the WTRU may blindly detect a first instance of a signature sequence and may determine the presence of further signature sequences for the TRP based on a predetermined function. The predetermined function may be spaced fixed in time and / or frequency from the first detected signature sequence, but other predetermined functions may be used in addition to or in lieu of those referenced herein. The WTRU may also be notified (possibly by the TRP) of the presence of a signature sequence, or a function used to determine the presence of a signature sequence.

[0197] Mobile measurements may be performed by the WTRU on the signature sequence itself. For example, the WTRU may determine the received power of the signature sequence, and / or any interference present when decoding the sequence.

[0198] The WTRU may also perform measurements on reference signals used for measurements.The signature sequence may point the WTRU to resources where the WTRU may expect the presence of reference signals (RS) for measurement purposes, which may be done implicitly or explicitly.

[0199] The WTRU may use a function to determine the resources on which the RS is transmitted. This may be an example of implicitly indicating to the WTRU the resources on which the RS is expected. The function may use parameters regarding the signature sequence to determine the parameters of the RS. The parameters regarding the signature sequence (which may indicate the resources used for the RS) may include at least one of: resource mapping, sequence timing, sequence used, and / or antenna port.

[0200] The resources (eg, a combination of symbols and subcarriers) used to transmit the signature sequence may indicate relevant parameters about the RS.

[0201] The timing of the sequence may indicate a set of parameters for the RS, which may include the timing of the RS. The WTRU may expect the RS to be within a specific symbol or subframe, and it may determine the symbol or subframe number based on the timing of the signature sequence. The WTRU may also expect a specific timing offset between the signature sequence and the RS transmission.

[0202] The signature sequence may be transmitted using one of several possible sequences. A sequence related to the signature sequence may be mapped to specific parameters of the RS.

[0203] The antenna port used to transmit the characteristic sequence may indicate a parameter set of the RS. For example, a beam may be used to transmit the characteristic sequence, and the same beam may be used to transmit the RS. There may be multiple examples of implicit indication. Other methods of implicit indication may also be used.

[0204] The signature sequence may encode the parameters of the RS. This may be an example of an explicit indication of the RS by the signature sequence. For example, the signature sequence may be detected and demodulated by the WTRU, and the information may indicate some parameters of the associated RS. The signature sequence may be mapped to an entry in an access table. The entry may indicate some parameters of the associated RS. There may be multiple examples of explicit indication. Other ways of explicit indication may also be used.

[0205] The WTRU may also perform mobile measurements using a UE-specific RS. The UE-specific RS may be configured via one or more service TRPs. The UE-specific RS may also be transmitted, which may be periodic or aperiodic. Aperiodic transmissions may be indicated by one or more service TRPs. For example, aperiodic transmissions regarding RS may be multicast to a suitable group of WTRUs that share a similar RS configuration.

[0206] Further, the UE-specific RS may also be transmitted only inside or outside of a transmission burst. A transmission burst may be defined as a time period for which the serving TRP has a DL transmission to any of its WTRUs or expects an UL transmission from any of its WTRUs. For UE-specific RS transmission, a transmission burst may also be a time period for which the serving TRP has a DL transmission to the WTRU itself or expects an UL transmission from the WTRU itself.

[0207] The UE-specific RS may be transmitted upon request from the WTRU. The manner in which the WTRU may request transmission of the UE-specific RS may be indicated in the access table or may be configured by one or more serving TRPs.

[0208] The UE-specific RS may be transmitted based on the results of channel transmissions or other content of transmissions. For example, the WTRU may feedback certain measurements performed on a first RS. Depending on the value of the feedback, the WTRU may expect a transmission from a second RS on which the WTRU may perform mobile measurements. The WTRU may also report a NACK for a DL transmission. The WTRU may also expect a transmission from an RS to perform mobile measurements. This may be based on a redundant version of the transmission that caused the NACK.

[0209] The WTRU may also be configured to perform periodic mobile measurements. The WTRU may also be configured to perform mobile measurements when a suitable RS is present. This may be for on-demand RS transmission or RS transmission selected by a TRP.

[0210] When the WTRU has UL data to transmit to at least one TRP, or when the WTRU expects DL transmission from at least one TRP, the WTRU may need or desire to perform measurements. For example, a self-contained subframe may be used, which consists of a control region, a DL transmission region, a UL transmission region, and an appropriate guard period. If the WTRU is scheduled for DL ​​transmission or UL transmission or both during this subframe, the WTRU may perform mobile measurements (mobile measurements may be performed on RSs within the same subframe).

[0211] The WTRU may be triggered by at least one other TRP to perform a mobile measurement on a serving TRP. This triggering may be caused by a measurement being triggered on another serving TRP that shares the same signature sequence. A measurement being triggered on at least one other serving TRP that uses a different signature sequence may also trigger a mobile measurement event at the WTRU. Detection of other TRPs that share or do not share the same signature sequence may also result in mobile measurements. Increased interference from sharing (or not sharing) the same signature sequence may also trigger mobile measurements.

[0212] The WTRU may be triggered to perform mobile measurements based on the WTRU position, speed or orientation. For example, the WTRU may also be triggered to perform mobile measurements on a serving TRP based on the WTRU position, speed, orientation. The WTRU may transition from a non-mobile state to a mobile state, which may trigger mobile measurements. The WTRU may also move from a predetermined area to a different predetermined area, which may also trigger mobile measurements. The predetermined area may be determined by the WTRU, or may be signaled by the network, and may be defined by exact geographic coordinates (longitude, latitude or similar parameters), or may be related to a specific reference physical location that is also known to the WTRU or the distance from this location. In this case, the WTRU may determine its own position, speed, orientation, etc., independently of using positioning technology (such as GPS) or by using a network-based method and the network signaling the location to the WTRU.

[0213] The WTRU may be configured with a list of areas through which the WTRU can determine whether mobile measurements are needed. The WTRU may also autonomously determine this list of areas. The list may include geographic locations. The list may also include a set of TRPs and may include a configuration for enabling mobile measurements on the TRPs. The set of TRPs for each geographic list may be maintained by the WTRU. For example, the WTRU may add a TRP to the list once relevant measurements have been made. The WTRU may also remove a TRP from the list once a timer expires. The timer may be started from the time of the last mobile measurement on the TRP.

[0214] The WTRU may also determine a trigger for a mobile measurement based on its distance from a particular TRP. The WTRU may receive the geographic location of one or more TRPs. The WTRU may receive this message based on broadcast or dedicated signaling from the TRP or through information from an access table. A mobile measurement may be triggered if there is a change in distance, or if the distance meets certain trigger criteria. For example, if the distance between the WTRU location and the signaled TRP location exceeds a threshold, the WTRU may trigger a mobile measurement.

[0215] The WTRU may report a measurement when it completes the measurement. The WTRU may also have a periodic resource on which it may report mobile measurements. This resource may be similar to the CSI feedback resource. The WTRU may be triggered aperiodically by the serving TRP to report measurements. This trigger may include an UL grant regarding the resources on which the WTRU may report one or more measurements.

[0216] The WTRU may be triggered to report a measurement. When a measurement is triggered, the WTRU may feed back this measurement. The WTRU may be triggered to report a measurement when a measurement has been performed or may be performed based on the detection of a new feature. The WTRU may also be triggered to report a measurement when a measurement has been performed or may be performed based on the detection of a new RS for the same feature.

[0217] The WTRU may also be triggered to report measurements based on thresholds (which may be absolute or relative to other measurements). The comparison between the measurement and the threshold may depend on whether the measurement is for a TRP of a shared signature sequence. The WTRU may also be triggered to report measurements when the WTRU is provided with resources to report measurements, or based on a change in the WTRU's determined position, speed, heading, or distance to one or more TRPs.

[0218] The measurements may be reported via different mechanisms. For example, the measurements may be reported on a physical channel used for UL transmission. The mobility measurements may be included in periodic feedback or aperiodic feedback. The mobility measurements may also be included in the UCI transmitted in the UL grant for data transmission. The WTRU may also report the mobility measurements on physical layer resources. The WTRU may also report the mobility measurements on the MAC CE.

[0219] The WTRU may reuse CSI feedback resources. When reusing CSI feedback resources, the WTRU may include an identifier to indicate that the CSI feedback report has been replaced by a mobile measurement report. The identifier may also indicate that the mobile measurement has been concatenated or input to the CSI feedback report.

[0220] The WTRU may report mobility measurements within the HARQ feedback. The presence of mobility measurements may depend on the feedback itself. For example, an ACK may indicate to the serving TRP that mobility measurements are not included, which may happen because the channel is good enough to support the transmission. A NACK (possibly on a specific retransmission) may also indicate to the serving TRP that mobility measurements are also included.

[0221] A WTRU may report mobility measurements in the UL portion of a self-contained subframe. For example, a WTRU configured with an RS for mobility measurements or a WTRU configured to perform mobility measurements on a sub-contained subframe may transmit mobility measurements in the UL portion of the subframe. When a measurement triggers a mobility measurement or a mobility measurement report in a self-contained subframe, the report may also be transmitted in the UL portion of the same subframe.

[0222] The WTRU may maintain measurements about neighboring TRPs for subsequent use. A TRP may be identified by the WTRU through a transmitted signal, a signature sequence, or assistance from another TRP.

[0223] For example, the reference signal transmitted by the TRP may also be used by the WTRU to synchronize to the TRP. The transmitted signal may also be transmitted by a TRP other than the TRP to be identified. The transmitted signal may also be transmitted by another WTRU (which may be a WTRU served by the TRP). The transmitted signal may be periodic or may be transmitted on demand by the WTRU.

[0224] The signal may be transmitted periodically by identifying at least some parameters of at least one TRP. The signature sequence may be mapped to entries in an access table that are not frequently transmitted. The access table may provide some TRP system information.

[0225] For example, the first TRP may be identified by the assistance information transmitted from the second TRP. Although the WTRU has identified the existence of the TRP, this does not necessarily mean that the WTRU has performed any measurements.

[0226] The WTRU may detect and synchronize to a TRP that is not currently serving the WTRU, which may be referred to as a neighboring TRP. Once a neighboring TRP is detected, the WTRU may classify the TRP based on whether it shares a signature sequence with at least one serving TRP. If the signature sequence is shared, the access table may provide a list of RSs on which to synchronize with different TRPs within a TRPG that share the signature sequence. The WTRU may also assume that some synchronization is shared between TRPs that share a signature sequence. For example, the WTRU may use synchronization with a serving cell as a rough synchronization with a neighboring cell that shares a signature sequence. The access table may also provide the resources where the RS is located for performing measurements.

[0227] If the signature sequence of a neighboring TRP is not shared by at least one serving TRP, the WTRU may not assume any shared synchronization with the serving TRP. In this case, the WTRU may require multiple transmissions of the signature sequence before assuming sufficient synchronization to perform mobile measurements.

[0228] The search for neighbor TRPs with signature sequences that are not shared by at least one serving TRP is configurable and may be performed with the assistance of the serving TRP. For example, the WTRU may receive a signature sequence identifier or a resource set (where it may search for a new signature sequence) from at least one of its serving TRPs. The WTRU may also be instructed by at least one of its TRPs to search for other signature sequences without further assistance. The WTRU may also autonomously search for and detect neighboring TRPs that use other signature sequences.

[0229] Neighbor TRP measurements may use any of the methods and measurement types proposed herein for service TRP measurements.

[0230] If the signature sequence is used by at least one serving TRP, the WTRU may be expected to perform measurements on all TRPs that use the signature sequence. If the signature sequence is not used by at least one serving TRP, the WTRU may be configured to measure neighbor TRPs once the signature sequence or TRP is detected. In this case, the WTRU may be expected to measure one, some, or all TRPs that share the newly discovered signature sequence.

[0231] If the measurement on at least one serving TRP reaches a threshold, the WTRU may be triggered to perform measurements on a neighbor TRP. For example, the received power on at least one serving TRP may drop below a threshold or rise above a threshold. Received power may be just one example of a metric that may be used to trigger measurements.

[0232] This type of demodulation performance change of the WTRU may trigger a measurement if the WTRU is unable to correctly decode a certain number of transport blocks using less than a number of retransmissions. The number of transport blocks and / or the amount of retransmissions may be configurable.

[0233] Measurements triggered on a serving TRP may trigger measurements on one or more neighbor TRPs. This may be applicable if the neighbor TRP shares a signature sequence with the serving TRP for which the measurements were triggered.

[0234] Changes in WTRU position, speed, orientation, or distance between the WTRU and a neighbor TRP may also trigger measurements. This may also be combined with the requirement that the TRPs share the same signature sequence.

[0235] The WTRU may determine measurement resources based on the access table. If the signature sequence of the neighboring TRP is the same as the signature sequence of at least one serving TRP, the WTRU may receive assistance from the serving TRP. The WTRU may also obtain resources from at least one serving TRP, and it may use those resources to request measurement resources from the neighboring TRP. For example, the WTRU may be provided with resources by the serving TRP for UL transmission to a non-serving TRP. The UL transmission may trigger the neighboring TRP to transmit a UE-specific RS that can be used for measurement.

[0236] If the neighboring cell does not share a signature sequence with at least one serving TRP, the WTRU may need to trigger the RS for measurement by using shared UL resources. For example, the WTRU may transmit a sounding signal. The sounding signal may be transmitted on resources specific to the signature sequence. The sounding signal may also indicate the signature sequence for which it is being transmitted. The sounding signal may also trigger the transmission of the required RS, or it may trigger the transmission of possible UE-specific system information. The system information may be included in the triggered access table transmission.

[0237] Neighbor TRP measurements may be reported in a manner similar to the method defined herein for reporting measurements from a serving TRP. Neighbor TRP measurements may also be reported when serving TRP measurements are reported. A subset of neighbor TRP measurements may also be reported. For example, the WTRU may rank neighbor TRPs based on their measurements and report only the best. The WTRU may report measurements of all TRPs that share the same signature sequence as the best TRP. The WTRU may report measurements of a single TRP per signature sequence. The WTRU may report measurements of a set of best TRPs, regardless of whether they share a signature sequence.

[0238] Neighbor TRP measurement reports may be sent to different destinations. The WTRU may report neighbor TRP measurements to at least one of its serving TRPs. For example, the WTRU may report neighbor TRP measurements to any serving TRP that shares the neighbor's signature sequence. The WTRU may also report neighbor TRP measurements to a primary serving TRP, regardless of whether the neighbor TRP shares a signature sequence with the primary serving TRP.

[0239] The WTRU may also report the measurement to the TRP to which the measurement applies. This may enable WTRU autonomous switching.

[0240] The WTRU may also report measurements to any TRP that can hear the WTRU. For example, the WTRU may be configured with resources on which it can report measurement feedback. The resources may be shared between TRPs, such as between TRPs that share a signature sequence. The WTRU may also be provided with a shared resource on which it can report measurements. The shared measurement resource may be shared per TRPG (e.g., the TRPGs share the same signature sequence).

[0241] In addition to simple reporting measurements, the WTRU may be triggered to perform other actions when obtaining measurements. The actions that can be performed are configurable. Based on the measurement of at least one neighbor TRP satisfying at least one criterion (e.g., a measurement threshold), the WTRU may be triggered to perform random access to the neighbor TRP. This RA may be modified to include a cause value, thereby providing it to the neighbor TRP. The cause value may indicate the measurement that triggered the RA or the value of the measurement. The cause value may also indicate at least one source TRP. For example, the criterion for this action may be whether the neighbor TRP measurement has an offset greater than the measurement of at least one service TRP. In this case, the RA cause value may indicate a service TRP whose measurement has an offset based on a measurement lower than the neighbor TRP. This measurement-triggered RA may only be possible if the neighbor TRP shares a characteristic sequence with at least one service TRP. The measurement-triggered RA may include some WTRU information to enable appropriate switching between at least one source TRP and a target TRP.

[0242] The WTRU may build and maintain a list of neighbor TRPs, which it may provide to the network. This list may include neighbor TRPs that are currently being measured by the WTRU. It may also include a list of TRPs whose TRP measurements meet some specific criteria. This criterion may be based on any measurement described herein. The list may also include neighbor TRPs that the WTRU is able to detect. The category may also include TRPs that belong to a specific system feature or set of system features. The neighbor TRP list may also include a list of TRPs that meet the conditions for the WTRU to perform WTRU-autonomous switching.

[0243] The WTRU may transmit a list of neighbor TRPs to one or more of its serving TRPs. One reason for sending this list of neighbor TRPs may be to allow the TRP or network to determine which TRPs need to be involved in the context transfer in the event that the WTRU context needs to be transferred directly from one TRP to another. Another motivation may be to allow the network to select the TRPs to which the WTRU's DL traffic from the network needs to be sent, and to select which TRPs need to coordinate resources. The WTRU's data may be provided to multiple TRPs for DL ​​transmission. The actual TRP or TRPs that transmit the data may be triggered by the WTRU, which may involve the use of autonomous switching operations.

[0244] As the WTRU moves, it may update and report a new version of the neighbor list to the network. The update may include adding a neighbor TRP or removing a neighbor TRP from the list, and the update to the list may be triggered by certain factors or circumstances. The WTRU may be updated based on one or more triggers. If the measurement associated with the TRP meets or does not meet one or more specific criteria, this may trigger the addition of a neighbor TRP or the removal of a neighbor TRP from the list. A neighbor TRP may also be added or removed from the list when the distance between the WTRU and a specific TRP is above / below a specific threshold or when the speed of the WTRU increases / decreases beyond a specific value. For example, the WTRU may be configured with a specific minimum number of TRPs in the measurement list when its speed is above a certain amount, or the WTRU may be configured with an expected measurement list size corresponding to each speed range. Neighbor TRPs may also be added or removed from the list when a new signature sequence is detected. In this case, one or more TRPs associated with the new signature sequence may be added. Neighbor TRPs may also be added or removed from the list when a TRP from a TRPG is added to the neighbor list, in which case all other TRPs in the TRPG may be added.

[0245] The WTRU may send the neighbor list to the network based on a number of triggers. The WTRU may be configured to periodically transmit the neighbor list. The WTRU may also be triggered by at least one TRP (which may be a serving TRP) to transmit the neighbor list. The WTRU may also transmit the neighbor list when the list changes (e.g., there is an addition or removal of a neighbor on the list). The WTRU may also transmit the neighbor list at random access or WTRU-autonomous handover, as described below.

[0246] Figure 7 An architectural diagram of random access (RA) is shown. The WTRU 700 may begin by transmitting a RA preamble via a random access transmission 701, which may be detected by multiple TRPs 710 (up to and including all TRPs 710) within a TRPG 720. The WTRU 700 may then receive a RAR 702 from one TRP 710 in response to the random access transmission 701 and another RAR 702 from a second TRP 710. The WTRU 700 may begin a data transmission 703 with the first TRP 710 based on the RAR information received from the first TRP 701, and may store the RAR 702 from the second TRP 710. When the WTRU changes position in the direction of movement, or when the first TRP becomes unresponsive or the communication becomes slowly below a threshold, the WTRU 700 may stop transmitting between itself and the first TRP 710 and may start transmitting to the second TRP 710 based on the WTRU's new position and its relative proximity to the first TRP 710 and the second TRP 710 without another initial exchange of RA information. This may occur within single cell operation. The ability to seamlessly switch between TRPs may allow greater mobility and may reduce the amount of mobility-related signaling and always-on signals due to the stored RAR data.

[0247] The WTRU may be triggered by a measurement or combination of measurements to perform a RA to a neighbor TRP. For example, the WTRU may determine that a neighbor TRP may have become stronger than the serving TRP (e.g., has a higher received power than the serving TRP). Measurements on a neighbor TRP may also indicate to the WTRU that the neighbor TRP may have been added to the serving TRP set. This may depend on whether the neighbor TRP shares a signature sequence with at least one serving TRP.

[0248] If the WTRU has determined that it has suffered a degradation in transmission performance from at least one serving TRP, the WTRU may perform a RA to a neighbor TRP. This degradation may be determined based on an inability to decode one or more transport blocks (TBs). For example, once at least a threshold number x of TBs have failed to be delivered through an allowed number of retransmissions (e.g., by requesting an RLC retransmission), the WTRU may determine that it has suffered a degradation in performance. The x TBs may be x consecutive TBs, or the x TBs may be any x TBs within a time period or a total number of transmitted TBs. The time period or the total number of transmitted TBs may be configurable.

[0249] A WTRU may be instructed by at least one serving TRP to perform a RA on a neighboring TRP. The indication may be WTRU-specific, group-specific, or TRP-specific. The indication may be on a physical channel or may be broadcast. The indication may also be added to an access table entry. For example, a WTRU served by a TRP should continuously monitor the access table entry to which a signature sequence of the serving TRP is mapped. The indication may be performed by a change in one or more parameters of the signature sequence.

[0250] The WTRU may determine that its current serving TRP set may not be able to meet its UL or DL ​​transmission requirements. In one example, the WTRU may have a URLLC transmission that requires macro diversity. In order to achieve the desired macro diversity, the WTRU may need to increase its serving TRP set. Therefore, the WTRU may perform a RA to at least one neighboring TRP.

[0251] For example, the WTRU may determine that there is a change in its transmission requirements. This may be manifested as a change in the desired SOM. Therefore, the WTRU may perform a RA to a neighboring TRP that can support the required SOM.

[0252] For example, the WTRU may determine that, based on its speed, it may be better served by a TRP with a larger or smaller service area. The WTRU may then perform a RA to at least one suitable TRP.

[0253] For example, the WTRU may have a list of possible TRPs by geographic region. Upon entering a geographic region as determined by the location function, the WTRU may attempt to perform a RA on at least one TRP.

[0254] For example, the WTRU may have RLF to at least one serving TRP. In this case, the WTRU may perform a RA to at least one neighboring TRP or to the serving TRP from which it suffered the RLF.

[0255] The RA procedure may depend on whether the RA is for a TRP that shares a signature sequence with at least one serving TRP. For example, for a RA to perform a handover to a target TRP that shares a signature sequence with at least one source TRP, the WTRU may assume that the configured UL resources are still valid. Upon receiving the RAR, the WTRU may immediately continue with the pre-scheduled UL transmission. The WTRU may also assume that the configured DL transmissions (e.g., transmissions on reference signals, or semi-persistently scheduled transmissions) are also still valid.

[0256] On the other hand, for a RA to a TRP that does not share a signature sequence with at least one serving TRP, the WTRU may need to provide more information to the TRP before expecting a new scheduling grant. This may include HARQ process status, WTRU context, security information, etc. This information may be shared once the grant from the RAR message is received. This information may also be shared within the enhanced preamble transmission. Further, any configured UL resources may be assumed to be no longer valid.

[0257] The RA preamble transmitted by the WTRU may be targeted to a specific target TRP or any TRP within a TRPG (which may be composed of TRPs that share the same signature sequence). This RA may use resources indicated by at least one source TRP. For example, if the source TRP shares a signature sequence with the target TRP, the resources may be determined to be the same as those used for the source TRP.

[0258] The RA preamble may be transmitted without an intended target. This may apply to any TRP within a group of TRPs that share a signature sequence, or to any TRP that does not even share a signature sequence. This RA may be considered a detection mechanism that enables any TRP that can detect the RA preamble to transmit at least one signal. For example, the RA preamble may enable all neighboring TRPs to transmit their signature sequences or system information, or transmit RS to initiate measurements.

[0259] The WTRU may receive a single random access response (RAR). For example, a set of TRPs may be coordinated to transmit a single RAR. The RAR may contain information about the set of TRPs. Based on the RAR, the WTRU may be able to determine one or more TRPs to which it can connect.

[0260] In another scheme, the WTRU may receive multiple RARs, possibly one RAR for each TRP that successfully received the RA preamble, or possibly one RAR for each TRPG. Alternatively, the WTRU may receive one RAR for each set of TRPs that share a signature sequence.

[0261] Once multiple TRPs are received, the WTRU may select one or more TRPs based on measurements, characteristic sequences of the TRPs transmitting the RARs, WTRU context sharing, receive timing of the RARs, TRP capabilities, and / or parameters indicated within the RARs.

[0262] The WTRU may select one or more TRPs based on measurements made on the RS prior to transmitting the RA preamble. Measurements may also be made on the signal transmitted with the RAR.

[0263] The WTRU may give priority to TRPs that share a signature sequence with at least one source or serving TRP. The WTRU may also give priority to TRPs that do not share a signature sequence with at least one source or serving TRP. This may enable the WTRU to be served by a new set of TRPs, thereby potentially enabling more seamless mobility.

[0264] The WTRU may give priority to a TRP that shares a WTRU context, or HARQ process, or scheduler with at least one source or serving TRP. The WTRU may also prioritize a TRP that transmits its RAR earlier than another TRP. The WTRU may also interpret the timing of the RAR based on the latency that can be achieved for transmission to or from the TRP.

[0265] The RAR may include TRP capabilities, and the WTRU may prioritize TRPs whose capabilities better match the WTRU's needs. The TRP capabilities may also be known to the WTRU before the RAR is transmitted, because, for example, the TRP capabilities may be included in the access table.

[0266] The WTRU may also select a RAR based on parameters transmitted within the RAR. The parameters may include current TRP load, traffic volume, transmission restrictions, UL and DL configurations, or other parameters. Transmission restrictions may be used to reduce interference between TRPs.

[0267] The WTRU may select more than one RAR representing more than one TRP. This may enable the WTRU to be configured for carrier aggregation, or dual connectivity or CoMP. The selection of the more than one RAR may rely on criteria similar to those defined for the selection of a single RAR. In one example, the WTRU may select one RAR per TRP group, where a TRP group may be defined as a set of TRPs that share the same signature sequence. The WTRU may also select all RARs from a TRPG (that is, all RARs are from TRPs that share a shared signature sequence). The TRPG from which the WTRU may select all RARs may be determined as a TRPG whose signature sequence is shared or not shared with at least one source or serving TRP.

[0268] The WTRU may select a subset of RARs with which to proceed with the entire RA process. However, the WTRU may also store the set of TRPs for which unused RARs were previously transmitted (and any information contained in these RARs) for possible subsequent fast random access. For the stored set of TRPs, the WTRU may transmit an acknowledgment of the received RARs but may not proceed with the RA process. In addition, the WTRU may maintain measurements on these TRPs.

[0269] The RAR may include at least one of: a timing advance, a set of UL resources, system information, an indication regarding seamless mobility, and / or an indication regarding required WTRU information. Resources for UL transmission or resources for a scheduling request may be included in the RAR.

[0270] System information may be transmitted on demand and / or on WTRU-dedicated resources. The RAR may contain system information. The RAR may also contain resources on which the WTRU may request system information (which may include updated system information).

[0271] In the presence of an indication for seamless mobility, the WTRU may assume that once the RAR is received, all of its context and configuration from the source TRP may be maintained. For example, the target TRP may not be able to obtain the WTRU context, HARQ processing status, scheduling information, or WTRU configuration from at least one source or serving TRP. The target TRP may also not be able to share features with at least one source TRP, and this WTRU information may only be dynamically shared by TRPs that share the feature sequence. The RAR may indicate to the WTRU that it requires this information to perform PHY layer mobility. The RAR may provide the WTRU with UL resources for transmitting this information.

[0272] The RAR may also provide a set of UL resources to continue the transmission granted by the source TRP. The RAR may also provide conversion functions and / or conversion rules to allow the WTRU to convert between the resources granted by the source TRP and the corresponding resources that should be used in the target TRP when transmission occurs in the target.

[0273] The location of signals and certain channels from the source TRP to the target TRP may be indicated. These signals may include PUCCH, SR or SRS. The conversion function and / or conversion rules used to allow the WTRU to convert the location or attributes (time, frequency, scrambling code) of the channel or signal may also be indicated.

[0274] An indication may also be provided as to whether resources licensed within the source TRP are also available within the target TRP.

[0275] The WTRU may obtain the required information from at least one source or serving TRP and may perform a transmission to a target TRP. The WTRU may also instruct at least one source or serving TRP to provide the required information or a subset thereof to the target TRP. The indication may include a target TRP identifier. The indication may also provide radio resources on which the one or more source or serving TRPs may transmit the required WTRU information.

[0276] The RAR may also indicate to the WTRU that PHY layer mobility cannot be performed and may also indicate that it has started higher layer mobility procedures to obtain appropriate WTRU information.

[0277] If the WTRU does not receive a RAR from the target TRP, it may indicate to the serving TRP (e.g., source TRP) that it has attempted a RA to a neighbor TRP but did not receive a RAR. This indication may include the target TRP identifier (which may be a signature sequence). This indication may also provide a reason as to why the WTRU is attempting a RA to the target TRP. The reason may include a desire to perform a handover, a desire to add a serving TRP to an existing set, a desire to connect to the target TRP for a one-time transmission, or a desire to receive system information from the target TRP. Other reasons may also be included.

[0278] In the event that there is a desire to perform a handover, the WTRU may also indicate to the TRP set that it wishes to drop upon completion of the handover to the target TRP(s).

[0279] A serving TRP may be added to an existing set that may be used for carrier aggregation, dual connectivity or CoMP.

[0280] The WTRU may request to connect to a target TRP for a one-time transmission, which may be used when the WTRU wishes to connect to the target TRP to indicate its presence, or when it is experiencing adverse interference from the target TRP.

[0281] Failure to receive a RAR from a target TRP may also be a trigger that causes the WTRU to report mobility measurements to at least one serving TRP. A radio link failure (RLF) may be determined and announced by the WTRU for one, some, or all serving TRPs. For example, RLF may be determined on a single TRP basis, regardless of whether its signature sequence is shared. RLF may also be determined and announced on a TRPG if one, some, or all serving TRPs within that TRPG suffer from RLF.

[0282] If the WTRU fails to find a competent target TRP and at least one measurement on at least one serving TRP is below a threshold, the WTRU may experience an RLF. For example, a WTRU with a single serving TRP may find that the received power has dropped below a threshold for a time period, a set of consecutive measurements, or a set number of measurements within a time period. The power reduction may trigger the WTRU to attempt to find a target TRP. If the WTRU does not find an acceptable TRP within a set time period, it may declare an RLF. The RLF declaration may depend on whether the WTRU is able to find a target TRP that uses the same feature sequence as at least one serving TRP, or a target TRP that uses a different feature sequence than all serving TRPs. For example, the WTRU may have the ability to declare an RLF based on a TRPG, where the TRPs within the TRPG share the same feature sequence. In this example, the WTRU may look for a target TRP that does not share a feature sequence with any serving TRP, and may even perform a RA to that target TRP. However, the WTRU may declare an RLF for any TRPG in which it cannot find a new competent target TRP.

[0283] The WTRU may also declare RLF if at least one measurement regarding at least one serving TRP is below a threshold and it is unable to receive a RAR after attempting a RA to at least one target TRP.

[0284] The WTRU may also declare RLF when at least one measurement about at least one serving TRP is below a threshold and it cannot complete a RA to the at least one serving TRP (e.g., receive RAR fails). The WTRU may also declare RLF about a serving TRP when it cannot decode a transport block on a final HARQ retransmission. In another scenario, the WTRU may declare RLF about a serving TRP when it has reached the maximum RLC transmission for a transport block. The WTRU may also declare RLF when it has exceeded performance criteria for a radio bearer and / or SOM. For example, the WTRU may declare RLF when it cannot achieve a certain required delay for the SOM. In this example, the cause of the RLF may be indicated when declaring the RLF. This may enable the network to determine that the TRP or TRGG is still able to provide some connectivity to the WTRU, just not the kind of connectivity required by the SOM.

[0285] The WTRU may also declare RLF if measurements indicate that it may not be able to achieve the desired average performance. For example, a first measurement (which may be a received power measurement) may indicate that the WTRU may be able to achieve a certain instantaneous performance. However, a second measurement (which may be several hierarchical branches) may indicate that, on average, the WTRU is not able to achieve the desired performance.

[0286] The WTRU may also declare an RLF if it cannot be configured with the required reference signals or cannot detect the required reference signals. For example, the WTRU may be indicated with WTRU-specific and possibly dynamic reference signals. Once the first set of reference signals expires, if the WTRU is not configured with a new set or cannot detect the new set, it may declare an RLF.

[0287] RLF may be determined and declared based on the direction of transmission. For example, for an UL transmission to a serving TRP, the WTRU may determine that it is no longer able to achieve the required performance level. However, the same WTRU may be able to make DL transmissions from the same set of TRPs. Or vice versa. In this case, the WTRU may declare RLF and may also indicate the type of transmission (UL or DL) for which it is declaring RLF.

[0288] In another scenario, the WTRU may transmit an UL signal that causes at least one serving TRP to perform measurements. The UL signal may be transmitted periodically by the WTRU. The UL signal may also be transmitted when triggered by the WTRU. The trigger may include any of the previously mentioned reasons for the following matters: detection of a neighbor TRP, a RA to a neighbor TRP, or declaration of RLF. The transmission parameters of the UL signal may be semi-static (for example, indicated in an access table or system information) or may be configurable and WTRU-specific. Once the UL signal is transmitted, the WTRU may start a timer. Once the timer expires, if the WTRU does not receive a response from the target TRP of the signal, the WTRU may declare RLF to the serving TRP.

[0289] The RLF declaration may depend on the type of transport that the serving TRP is used for (e.g., SOM or URLCC / Embb / Massive MTC). For example, there may be different thresholds for different transport types or modes. In addition, RLF may only apply to one transport type or mode. In this example, the WTRU may declare RLF to the TRP for URLLC, but the WTRU may still be capable of eMBB.

[0290] The WTRU may be configured with two different thresholds, where the first threshold is higher than the second threshold. The first threshold may be a pre-RLF threshold and the second threshold may be a RLF threshold. If the measurement of system characteristics and / or reference signals becomes below the first threshold, the WTRU may perform a first set of actions, and when the measurement of system characteristics and / or reference signals becomes below the second threshold, the WTRU may perform a second set of actions. For example, when one or more service TRPs become below the first threshold, the WTRU may perform one or more of the actions described below.

[0291] The WTRU may transmit a request for a measurement reference signal to a non-serving TRP within a TRPG. For example, this measurement reference signal may be a WTRU-specific or TRP-specific reference signal that is turned off for power saving purposes. The WTRU may also transmit UL measurement signals on pre-configured WTRU-specific resources. One or more TRPs may listen on those UL resources and measure the WTRU's transmissions.

[0292] The WTRU may also be configured to receive downlink control information according to different transmission methods. Different transmission methods for downlink control information may mean different reliability levels. Different reliability levels may be achieved by a WTRU configured with more than one control channel, control channel search space, DCI decoding aggregation level, or control channel element set, etc. For example, the WTRU may monitor only the first control channel. The WTRU may also monitor the control channel search space when the service TRP is above a first threshold. When the service TRP is below the first threshold, the WTRU may start monitoring a second control channel set or control channel search space. The first control channel set may be TRP-specific, while the second control channel set may be common to all TRPs within the service TRPG or more than one TRP. The non-service TRP may also transmit a switching command on the second control channel set (or) control channel space based on a WTRU measurement report or a UL measurement signal.

[0293] The WTRU may also trigger an initial access procedure (e.g., random access) to non-serving TRPs within the TRPG. The WTRU may include additional information about the following to those TRPs: serving TRP ID, radio bearer configuration, WTRU context, failure cause, etc. As another option, the WTRU may perform a RA-less autonomous HO procedure described below.

[0294] When one or more service TRPs become lower than the second threshold, the WTRU may declare RLF and perform the above actions for TRPs in other TRPGs, TRPs in other layers, or LTE-Evo eNB.

[0295] If the WTRU is served by multiple TRPs, the WTRU may send an RLF announcement to one of its other serving TRPs. For example, the WTRU may send an RLF announcement to any other serving TRP that shares a signature sequence with the TRP from which it experienced the RLF.

[0296] If the WTRU is served by a single TRP (or a single TRP for a signature sequence), the WTRU may start the reestablishment process. If the WTRU is served by a single TRP, or a single TRP for a signature sequence, the WTRU may start searching for another TRP that shares the signature sequence. If a competent target TRP is found, the WTRU may start a RA and may also indicate the cause "RLF exists in another TRP that shares the signature sequence". The WTRU may also attempt a RA to any other competent TRP, regardless of whether it shares the signature sequence with the TRP that experienced the RLF.

[0297] The WTRU may also attempt a fast RA for a TRP for which the WTRU has stored a previously transmitted successful RAR but did not continue the RA procedure. In this case, the WTRU may indicate to this target TRP that it has stored the parameters transmitted in the previous RAR and that it wishes to continue the interrupted RA procedure. To enable this, the RAR may contain UL resources on which the WTRU may continue the interrupted RA procedure. There may also be an associated timer indicating how long this resource is valid.

[0298] The behavior of the WTRU upon experiencing RLF may depend on what the use case of the connection is. For example, the transmission type or mode (e.g., SOM or URLLC / eMBB / Massive MTC) may dictate the behavior that the WTRU may take upon declaring RLF. Thus, a WTRU may experience RLF for one mode (e.g., URLLC), but it may be able to indicate to the TRP that it experienced RLF for the first mode by using another mode.

[0299] The WTRU may perform RA-less mobility, which may also be referred to as WTRU-autonomous HO. The trigger for performing this mobility may be similar to the trigger for detecting neighbor cells, the trigger for measurement, the trigger for measurement reporting, or the trigger for RA-based mobility described above. In addition, the RLF declaration may initiate the RA-less mobility.

[0300] The ability to perform RA-less mobility may depend on whether the target TRP shares a signature sequence with at least one source TRP. The ability to perform RA-less mobility may also depend on whether the target TRP has been provided with DL data of the WTRU from the network in preparation for seamless switching.

[0301] A TRPG may have some common resources on which a WTRU served by at least one TRP within the TRPG may perform UL transmissions (which may be UL transmissions to any TRP within the TRPG). This resource may be dedicated to the WTRU, or may be dedicated to a TRP or a TRPG. This resource may be included in the access table or system information for the TRPG. This resource may also be provided by at least one serving TRP.

[0302] The WTRU may also receive an indication as to whether the grant provided within the source TRP is valid within the target TRP. This indication may be provided within the initial grant. For example, the WTRU may receive through the grant a list of TRPs for which the grant is valid. If the WTRU decides to make an UL transmission after moving to a different TRP, it may also receive transition rules or alternative resources to be used within the different TRP. Assuming that information about pending grants is provided as part of the context transmitted within the RA message, an indication of valid grants may also be provided within the RAR.

[0303] A valid grant may be indicated by resources in the target TRP that replace resources in the source TRP. It may also be indicated by a conversion rule, which may be a frequency offset, a time offset, or a difference in coding, scrambling, etc., that needs to be used to obtain the target TRP resources from the initially granted source TRP resources. A valid grant may also be indicated by a change in the access mechanism, rules or assumptions that need to be applied in the target TRP. The change may be, for example, a new HARQ-related parameter.

[0304] The WTRU may perform an UL transmission on this resource to indicate a request for a WTRU autonomous HO. Some UL transmission parameters may be reused from at least one serving TRP, which may only be for the same TRPG. For example, UL timing advance and power control may be reused by the WTRU. UL transmission parameters may also be indicated, for example, in the configuration regarding common UL resources.

[0305] The WTRU may indicate a request for a WTRU autonomous HO using one or more of the following methods. The request may be an UL transmission on UL resources dedicated to the WTRU. This resource may be common to one or more TRPs within a TRPG. The WTRU may include a priority list of one or more TRP identifiers (e.g., based on measurements) within the UL transmission.

[0306] The request may be for an UL transmission on UL resources dedicated to a TRP. This resource may be common to one or more WTRUs. The WTRU may perform contention-based transmissions on those resources. The WTRU may be configured with multiple TRP-dedicated UL resources. The WTRU may indicate the selection of a target TRP by selecting the UL resources associated with the target TRP. The WTRU may include a unique UE ID on the common resources to identify itself.

[0307] The request may also be for an UL transmission on UL resources dedicated to the WTRU and TRP pair. The WTRU may indicate the selection of the target TRP and UE ID by selecting the appropriate UL resources reserved for the WTRU and the target TRP.

[0308] The above UL resources may also be reserved for any UL feedback transmissions, which may include CQI reports, measurement reports, scheduling requests, possible WTRU autonomous handover signaling, etc. The WTRU may include the report type in the MAC control element, or may implicitly indicate a WTRU autonomous handover request by selecting a specific signal or preamble.

[0309] The above UL resources may also be explicitly reserved for WTRU autonomous HO requests. Any WTRU transmission on the UL resources may be considered as a request for a WTRU autonomous HO request.

[0310] In this UL transmission, the WTRU may indicate its source TRP and the desired target TRP. This indication may be explicit, or may be implicit and depend on the parameters used for the UL transmission. The parameters may include a sequence for a demodulation reference signal or orthogonal UL transmission resources. Other content may also be used.

[0311] The WTRU may transmit a UE ID to identify itself to the target TRP. The WTRU may indicate the UE identity using one of the following or a combination of two or more of the following: for example, a unique radio level identifier (e.g., RNTI) assigned within the source TRP and / or a unique UE context ID that identifies the source TRP and the WTRU context within the source TRP, a unique logical connection ID or set of radio bearers within the TRPG, and / or any transmission on WTRU-specific UL resources that may implicitly identify the WTRU. The WTRU may also include characteristics of system features and / or spectrum operating modes for serving the WTRU within the source TRP.

[0312] In this UL transmission, the WTRU may indicate its source TRP and the desired target TRP. This indication may be explicit, or may be implicit and depend on the parameters used for the UL transmission. The parameters may include the sequence used for demodulation reference signals, orthogonal UL transmission resources, or WTRU buffer status, etc.

[0313] In addition to the information about the target TRP, the WTRU may also provide an indication to the source TRP regarding the autonomous movement of the WTRU. This information may be similar to that described above for random access.

[0314] The WTRU may also provide WTRU information to the target TRP. This information may include, for example, granted UL resources, HARQ process status, or WTRU context.

[0315] This UL transmission may also explicitly request reference signal resources from the target TRP to enable the WTRU to feedback measurements. This measurement report may enable the target TRP to be added to the existing set of serving TRPs, rather than simply replacing the source TRP with the target TRP.

[0316] The WTRU may restrict the autonomous HO process to the TRPG to which the serving TRP belongs. If the WTRU is served by more than one TRP (e.g., may be served by parts of two or more TRPGs), the WTRU may perform autonomous HO within the TRPs under all those TRPGs. The TRPG within which the WTRU may perform autonomous HO may be referred to as the serving TRPG. The WTRU may apply an additional offset or bias to the TRP within the serving TRPG during the handover target TRP selection. If the target TRP belongs to a non-serving TRPG, the WTRU may perform an L3 based handover.

[0317] The WTRU may also trigger an autonomous HO to all TRPs by default, regardless of the TRPG they belong to. The WTRU may need to verify the success of the autonomous HO based on a response from the network. For example, the network may indicate the need to perform an L3-based handover, such as via a handover command message or an L2 reset command, after which the WTRU may reset the L2 context, clear the HARQ buffer, and transmit an L3 reestablishment message or a handover complete message.

[0318] During or after a RACH procedure or WTRU autonomous handover, the WTRU may send an indication to the source TRP to indicate that it has successfully connected to the target TRP. This indication may be used, for example, to terminate data transmission and / or desired reception on the resources of the source TRP. More specifically, in the case of a RACH procedure, the WTRU may continue data reception / transmission with the source TRP after the RA transmission. Thereafter, the WTRU may send an indication to the source TRP regarding the successful connection to the target TRP, and after successfully connecting to the target TRP, it may be assumed that data reception / transmission with the source TRP may be stopped.

[0319] The WTRU may send an indication of successful connection to the target TRP to the source TRP immediately or when conditions have been met. The indication of successful connection to the target TRP may be sent when a RAR is received from the target TRP. The indication may also be sent when UL resources or DL ​​data obtained from the target TRP are received. The indication may also be sent when any HARQ process running when the RA is transmitted is successfully transmitted / retransmitted or when an autonomous HO is decided. The indication may also be sent when a specific PDU or packet (the specific PDU or packet is associated with the sequence number of the transmission in progress when the RA is sent, or is associated with another specific sequence number determined by the WTRU) is successfully decoded and possibly reassembled by the L2 (MAC, RLC or similar layer). The indication may also be sent when a timer expires, which may be started when the RA is transmitted, when the RAR is received, when the decision to perform autonomous HO is made, or when any other event after the above events occurs. The indication may also be sent when an indication comes from the target TRP (which may come in the RAR) or at a limited time (e.g., a fixed or configurable time) after the RAR. The indication to the source TRP may include an identification and / or a signature sequence of the target TRP. The indication may also include the status of PDUs that were not transmitted or received at a particular L2 protocol layer. The indication may also include the latest TRP list maintained by the WTRU, or measurements on the target TRP.

[0320] WTRU context transfer is described herein. When mobility / handover is performed, the WTRU context may be transferred to the new TRP. While in legacy systems this task was performed by the network, in 5G systems this will no longer be the case. In this case, the WTRU may be configured to transfer portions of these contexts to the new TRP. A motivation for doing this may be, for example, the need to speed up handovers when traffic volumes dictate this. Another motivation may be to reduce unnecessary backhaul load. This may also result in a reduction in the number of transmissions and retransmissions since the WTRU HARQ information may be transferred directly.

[0321] Therefore, the WTRU may be configured to transmit information to a new TRP in any order or combination when performing mobility / handover. The WTRU may transmit HARQ related context. It may also transmit PDU history information. The WTRU may also transmit cache information. The WTRU may also transmit security information. It may also transmit radio bearer / logical channel information and / or source TRP information.

[0322] The WTRU may pass the receive side and / or transmit side HARQ context. This information may include the HARQ process number / ID for each configured HARQ process. This information may also include the HARQ process status, where this status includes information about terminated, ongoing receive / transmit transmissions, and the number of new data. This information may also include the MCS / TBS or other control information about the packets being received / transmitted on the HARQ process. This information may also include the most recent feedback information transmitted / received, and / or timing information: including the SFN of the most recent transmission for the HARQ process.

[0323] The new TRP can use this information, for example, to determine the exact state to continue the transmission. More specifically, assuming that the source TRP also sent the HARQ context to the new TRP, the new TRP can determine the HARQ process state and continue the transmission from where the source TRP left off. The WTRU context information can be used to ensure that the new TRP is well synchronized with the source TRP.

[0324] The WTRU may pass information about the history of successfully received PDUs. Depending on the architecture, the PDU may be an RLC PDU, a PDCP PDU, or even a MAC PDU, or a PDU of a layer that carries a PDU count or number. For example, the WTRU may pass information about the last successfully received PDCP PDU, or about the last NPDCP successfully received PDCP PDU. This information may contain, for example, the sequence number of the associated PDU and additional information about, for example, the bearer or associated logical channel.

[0325] The delivery of information about the PDU history can be designed to ensure that a new TRP does not deliver PDUs that have already been successfully received (which might waste resources), and to ensure that no PDUs are lost.

[0326] To speed up the start of communication, the WTRU may indicate its cached status or information to the new TRP so that the new TRP can start scheduling the WTRU appropriately, or may refuse the switch if the new TRP does not have sufficient resources for the WTRU.

[0327] The WTRU may further indicate, for example, the remaining time for transmission of a packet or packet fragment for URLLC traffic. The remaining time may indicate, for example, how long the TRP may have to schedule the WTRU for transmission before the delay requirement is violated.

[0328] In order for the WTRU to securely transmit data to and receive data from the new TRP, security information may need to be passed. Transmitting unprotected security keys over the air may expose the WTRU to risk of attack. One option may be to actually encrypt the security context using a specific encryption key and pass the encrypted security context to the new TRP. The new TRP may decrypt the information using a specific key. The specific key may be, for example, a public key pre-configured in the WTRU or some other type of encryption key.

[0329] The WTRU may be configured to pass radio bearer / logical channel (RB / LCH) information to the TRP. This information may be used, for example, by the new TRP to determine the highest priority RB / LCH to schedule. This is very useful on the UL because the new TRP does not need to wait to receive configuration from the network and can start scheduling the WTRU in every latency situation. This is especially important for latency-sensitive data flows, such as for URLLC traffic.

[0330] The information conveyed may include, for example, the RB / LCH number, associated ID, QoS information such as latency requirements, bit rate, or reliability for each RB / LCH.

[0331] In order for the new TRP to be able to obtain the remaining WTRU context and complete the handover process, the new TRP must be indicated by the WTRU as the source TRP. This information may include, for example, the source TRP ID, its IP address or other identification information.

[0332] In order for the new TRP to be aware of the WTRU's current power-related information and status, the WTRU may need to transmit some such information to the new TRP. This information may consist of, for example, the most recent power headroom calculated by the WTRU, the instantaneous power used for the most recent transmission or for a specific subframe or set of subframes, or the TRP-specific power used for the source TRP (if any).

[0333] In order to make the new TRP aware of the WTRU's currently configured power saving information so that any WTRU-related states are maintained, the WTRU may transmit its current power saving state as part of the context. This may consist of a sleep cycle, periodicity, current DRX state, or any current value of a parameter maintained by the WTRU (which may have been previously known to the source WTRU but now needs to be communicated to the new TRP).

[0334] The WTRU may provide some D2D-related configuration or information to the new TRP, such as resource configuration, usage, sensing-related information, etc. This information may allow the WTRU to continue D2D-related communications without interruption under the control of the new TRP.

[0335] During mobility in the presence of multiple TRPs, the WTRU may communicate with multiple TRPs simultaneously, in a TDM / FDM manner, or based on certain rules (which may depend on TRP capabilities, information type (control vs. data), and data or service type (e.g., logical channel)).

[0336] The WTRU may also receive scheduling information from multiple TRPs. The TRP that provides scheduling to a single WTRU may further correspond to a list of TRPs that the WTRU sends to the network. For example, the WTRU may report to a TRP whose measurements meet a certain criterion. In response to this report, the WTRU may expect to receive scheduling from any TRP provided in the report.

[0337] The WTRU may also need to receive schedules from a set of TRPs for a limited period of time, and thereafter receive schedules from a possibly different set of TRPs. For example, the WTRU may need to monitor a control channel on which the schedules may appear. For example, the set of TRPs that may provide scheduling information may change periodically, or when a new list of TRPs is transmitted by the WTRU. Once the network successfully receives the list of TRPs (this may be accomplished by the WTRU receiving an acknowledgment), the WTRU may assume that the list of TRPs that are capable of providing scheduling to the WTRU may be changed to the list of TRPs that were transmitted and acknowledged. The network may also provide this list periodically, and the WTRU may change the TRP from which it expects to receive scheduling information accordingly.

[0338] The WTRU may be allowed to transmit to multiple TRPs simultaneously without sending RAs or performing the WTRU autonomous mobility procedures described herein. Simultaneous transmissions may be performed using different antenna ports. The WTRU may also transmit in TDM, FDM, or CDM mode. These TRPs may conflict with the set of TRPs from which the WTRU receives a schedule.

[0339] These TRPs may also be from another set of TRPs (possibly an independent set of TRPs). These TRPs may also conflict with the set of TRPs that are signaled to the network within a TRP list. For example, each time the WTRU transmits a list of TRPs, the WTRU may indicate to the network which TRPs it may transmit to in the uplink. The WTRU may also transmit two lists: a first list for the set of TRPs that the WTRU expects to receive transmissions from, and a second list for the set of TRPs to which the WTRU expects to transmit. The WTRU may also receive two lists from at least one TRP: a first list indicating the set of TRPs that the WTRU should monitor for possible scheduling information, and a second list indicating the set of TRPs to which the WTRU may expect (or be allowed) to make UL transmissions.

[0340] For a given transmission, the WTRU may select a TRP to which it may transmit based on the capabilities or services supported by the TRP (e.g., the type of traffic supported). TRP selection may also be based on the available TTIs or the set of TTIs supported by the TRP. TRP selection may also be based on the TRP, or a list of possible TRPs may be signaled to the WTRU for use by the WTRU (e.g., as part of a UL grant). It may also be based on the current load of a particular TRP, which may be signaled by the network. TRP selection may also be based on the immediate or short-term availability of UL resources within that TRP. For example, when an SR configured within a TRP first appears after the data that needs to be transmitted arrives within the WTRU, the WTRU may transmit the SR on that particular TRP. A TRP may also be selected based on transmit power limitations or required resources (e.g., a particular TRP may only be applicable to a specific number of antenna ports, PRBs, symbols, etc.).

[0341] The WTRU may be scheduled with resources for UL transmissions and may select a TRP for the transmission. The selection may be made based on previously known TRP capabilities and the type of data the WTRU wishes to transmit using a particular grant.

[0342] The WTRU may also be provided with a TRP (as part of the grant) for UL transmissions, which may be provided explicitly through the identification of the TRP, or implicitly through the specific TTI or resource set that it signals within the grant.

[0343] The WTRU may indicate to the network the TRP that will be used for UL transmission. This indication may be provided prior to the actual UL transmission and may be provided to a single TRP (e.g., a primary TRP described in more detail below) or to multiple TRPs (e.g., to all TRPs within a TRP list, or to all TRPs associated with a particular feature). This indication may be used, for example, to allow the network to reuse specific unutilized resources within a TRP. The indication may be sent within predefined resources or in a manner that it may be received simultaneously by multiple TRPs.

[0344] The WTRU's selection of a TRP to which to transmit an UL transmission may be based on the capability information of the TRP (which may be broadcast by the network). The TRP capability information may include the possible TTIs that can be used for UL transmissions. The information may also include the type of traffic, or logical channel priorities, etc. (which may be transmitted on the TRP). The capability information may also include information on whether the TRP supports CP, UP, or both types of traffic. The capability information may also include the maximum speed supported during UL transmissions, or the supported UL channels (e.g., PUCCH, SR, etc.).

[0345] For example, based on the capability information of the TRP, the WTRU may need to transmit L2 control information (such as MAC CE) only for a specific TRP.

[0346] The WTRU may identify or be configured with a specific TRP (which may serve as a primary TRP), and the WTRU may perform multiple connections with several TRPs. The WTRU may select and indicate a primary TRP to the network. This indication may be part of a list of TRPs provided to the network, so that one of the TRPs may be designated as the primary TRP by the WTRU. The primary TRP may be selected based on criteria, which may include: the TRP with the best measurements, the TRP closest to the WTRU, the TRP that supports all services / capabilities required by the WTRU at a given time, a TRP that indicates the ability to serve as a primary TRP, or a TRP that provides resources to the WTRU (on which the WTRU may transmit a primary TRP transmission indicating which TRP any particular UL transmission is intended for).

[0347] The WTRU may expect certain control-related communications to occur with a designated primary TRP. For example, the WTRU may be allowed to transmit L2 control information to / receive L2 control information from the primary TRP.

[0348] The WTRU may be further configured to perform the mobility-related actions described herein (RA transmission, procedures related to WTRU autonomous mobility) when it decides to change the primary TRP.

[0349] Although the features and elements in specific combinations are described above, it will be recognized by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is introduced into a computer-readable medium for operation by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, a terminal, a base station, an RNC, or any host.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receiving, via a serving cell, a configuration message, wherein the configuration message includes configuration information for a candidate cell and a measurement condition for handover (HO) to the candidate cell; Determining to initiate HO to the candidate cell based on the measurement condition for HO being satisfied; Based on the measurement condition for the HO to the candidate cell being satisfied, sending a preamble using a physical random access channel (PRACH) resource of the candidate cell; receiving a random access response (RAR), the RAR including scheduling information for uplink transmission; as well as The uplink transmission is sent, and the uplink transmission scheduled by the RAR includes WTRU context information.

2. The method according to claim 1, wherein: The measurement condition is associated with a configured measurement offset value.

3. The method according to claim 1, comprising: Configuration information for a plurality of candidate cells and corresponding measurement conditions for HO to each of the plurality of candidate cells are received.

4. The method according to claim 1, wherein: The measurement condition corresponds to the WTRU determining that a measurement of the candidate cell is greater than a measurement of the serving cell by at least one configured offset.

5. The method according to claim 1, wherein: The measurement conditions include a combination of a plurality of conditions.

6. The method according to claim 1, wherein: The uplink transmission also includes a radio network temporary identifier (RNTI) for the WTRU in the serving cell.

7. The method according to claim 1, wherein: The configuration information for the candidate cell includes reference signal information for measurement associated with the measurement condition, and wherein the reference signal information indicates that the measurement associated with the measurement condition is to be performed on a synchronization signal of the candidate cell.

8. A wireless transmit / receive unit (WTRU), the WTRU comprising a processor, the processor configured to: Receiving, via a serving cell, a configuration message, wherein the configuration message includes configuration information for a candidate cell and a measurement condition for handover (HO) to the candidate cell; Determining to initiate HO to the candidate cell based on the measurement condition for HO being satisfied; Based on the measurement condition for the HO to the candidate cell being satisfied, sending a preamble using a physical random access channel (PRACH) resource of the candidate cell; receiving a random access response (RAR), the RAR including scheduling information for uplink transmission; as well as The uplink transmission is sent, and the uplink transmission scheduled by the RAR includes WTRU context information.

9. The WTRU of claim 8, wherein the measurement condition is associated with a configured measurement offset value.

10. The WTRU of claim 8, wherein the processor is configured to receive configuration information for a plurality of candidate cells and corresponding measurement conditions for HO to each of the plurality of candidate cells.

11. The WTRU of claim 8, wherein the measurement condition corresponds to the WTRU determining that a measurement of the candidate cell is greater than a measurement of the serving cell by at least one configured offset.

12. The WTRU of claim 8, wherein: The measurement conditions include a combination of a plurality of conditions.

13. The WTRU of claim 8 wherein: The uplink transmission also includes a radio network temporary identifier (RNTI) for the WTRU in the serving cell.

14. The WTRU of claim 8 wherein: The configuration information for the candidate cell includes reference signal information for measurement associated with the measurement condition, and wherein the reference signal information indicates that the measurement associated with the measurement condition is to be performed on a synchronization signal of the candidate cell.

Images