Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/34—Reselection control
  • H04W36/36—Reselection control by user or terminal equipment
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/24—Reselection being triggered by specific parameters
  • H04W36/32—Reselection being triggered by specific parameters by location or mobility data, e.g. speed data

Definitions

• a fifth generation may be referred to as 5G.
• a previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).
• 4G fourth generation
• LTE long term evolution
• Proactive conditional handover may include a wireless transmit/receive unit (WTRU) providing assistance information to a network.
• the WTRU may receive (e.g., from a base station of the network) coverage information, indicating the network’s deployment of cells and/or beams.
• the WTRU may receive a proactive CHO configuration (e.g., via a WTRU dedicated signal or a broadcast system information).
• the proactive CHO configuration may include CHO candidates (e.g., cell(s) and associated beam(s)) that may be suitable for performing CHO upon a determination of link degradation.
• the CHO candidates may be associated with (e.g., organized into sets based on) mobility causes, for example, device mobility (e.g., a change in position/orientation of the WTRU) and/or external mobility (e.g., movement of an external object).
• a candidate CHO of external mobility CHO configuration information e.g., a configuration set
• a device may comprise a processor configured to perform one or more actions.
• the device may send assistance information.
• the assistance information may indicate a characteristic associated with the WTRU.
• the WTRU may receive coverage information, external mobility conditional handover (CHO) configuration information (e.g., an external mobility CHO configuration set), and/or device mobility CHO configuration information (e.g., a device mobility CHO configuration set).
• the WTRU may determine a mobility cause.
• the WTRU may determine a CHO candidate cell based on a non-radio measurement, the mobility cause, and/or the coverage information.
• the WTRU may determine that an execution condition is satisfied for the CHO candidate cell.
• the WTRU may send a RACH transmission to the CHO candidate cell.
• the device may determine, based on the non-radio measurement, a location associated with the WTRU and an orientation associated with the WTRU.
• the determination of the CHO candidate cell may be further based on the location and/or the orientation of the WTRU.
• the WTRU may determine a RACH configuration based on the CHO candidate.
• the RACH transmission may be sent in accordance with the RACH configuration.
• the CHO candidate cell may be associated with one or more beams, and the WTRU may determine a RACH configuration based on a strongest beam of the one or more beams associated with the CHO candidate cell.
• the RACH transmission may be sent in accordance with the RACH configuration.
• the WTRU may determine that a radio link condition indicating the degradation of a serving link is satisfied.
• the mobility cause may be associated with the radio link condition.
• the mobility cause may be external mobility, and the CHO candidate may be indicated in the external mobility CHO configuration information.
• the mobility cause may be device mobility, and the CHO candidate may be indicated in the device mobility CHO configuration information.
• the determination that the execution condition is satisfied may be based on a radio measurement and the non-radio measurement.
• a wireless transmit/receive unit may provide assistance information to a network, which may include, for example, information on one or more of the following: position, location, panels, field of view (FoV), application-quality of service (QoS) from local sensors, and/or measurement data.
• a network may include, for example, information on one or more of the following: position, location, panels, field of view (FoV), application-quality of service (QoS) from local sensors, and/or measurement data.
• a WTRU may compute updated geographic coordinates and orientation, for example, based on information (e.g., from local sensors) and/or (pre)configured thresholds.
• a WTRU may compute updated geographic coordinates and orientation, for example, based on (e.g., after) a mobility event (e.g., resulting from device mobility or mobility in the environment) that may lead to compromised link quality.
• a mobility event e.g., resulting from device mobility or mobility in the environment
• a WTRU may determine (e.g., derive) the highest priority CHO candidate (e.g., (cell, beam) pair) from the (e.g., network configured) mapping against the (e.g., suitable, estimated) geographical coordinates.
• the highest priority CHO candidate e.g., (cell, beam) pair
• a WTRU may evaluate a CHO execution condition for a determined CHO candidate (e.g., (cell, beam) pair).
• a CHO execution condition for a determined CHO candidate e.g., (cell, beam) pair.
• FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.
• WTRU wireless transmit/receive unit
• FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.
• FIG. 2 illustrates an example timing diagram for performing a WTRU attach.
• FIGS. 3A and 3B show example situations for beam failure.
• FIG. 4 illustrates an example of parallel running procedures for beam/cell level mobility.
• FIG. 5 illustrates an example of an intra-NR Inter-gNB handover.
• FIG. 7 illustrates an example of mobility resulting from WTRU rotation/orientation.
• FIG. 10 illustrates an example of a proactive beam recovery and conditional handover configuration.
• FIG. 13 illustrates an example of a proactive CHO with a coverage ensemble, e.g., which may be provided as dedicated signaling.
• FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
• the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
• the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
• the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.
• UE user equipment
• PDA personal digital assistant
• HMD head-mounted display
• a vehicle a drone
• the communications systems 100 may also include a base station 114a and/or a base station 114b.
• Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112.
• the base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
• BSC base station controller
• RNC radio network controller
• the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum.
• a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
• the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
• a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
• the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
• the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
• DC dual connectivity
• the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).
• the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
• IEEE 802.11 i.e., Wireless Fidelity (WiFi)
• IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
• CDMA2000, CDMA2000 1X, CDMA2000 EV-DO Code Division Multiple Access 2000
• IS-95 Interim Standard 95
• IS-856 Interim Standard 856
• GSM Global System for
• the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT.
• the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
• the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
• the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
• the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
• the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
• SIM subscriber identity module
• SD secure digital
• the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
• the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
• the power source 134 may be any suitable device for powering the WTRU 102.
• the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
• the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
• location information e.g., longitude and latitude
• the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.
• the peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
• a gyroscope an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
• the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous.
• the full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
• the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
• a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
• FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
• 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 CN 106.
• the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
• the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
• the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
• the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
• Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
• the CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
• MME mobility management entity
• SGW serving gateway
• PGW packet data network gateway
• the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node.
• the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
• the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
• the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
• the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
• the SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
• the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
• packet-switched networks such as the Internet 110
• the CN 106 may facilitate communications with other networks.
• the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
• the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
• IMS IP multimedia subsystem
• the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
• the other network 112 may be a WLAN.
• a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
• the AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
• Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs.
• Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
• Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA.
• High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
• VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels.
• the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
• a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
• the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
• Inverse Fast Fourier Transform (IFFT) processing, and time domain processing may be done on each stream separately.
• IFFT Inverse Fast Fourier Transform
• the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
• the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
• MAC Medium Access Control
• WLAN systems which may support multiple channels, and channel bandwidths, such as
• the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
• the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
• TTIs subframe or transmission time intervals
• the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.
• WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
• WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point.
• WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
• WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
• WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
• Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface. [0085] The CN 115 shown in FIG.
• 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
• SMF Session Management Function
• Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
• different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like.
• URLLC ultra-reliable low latency
• eMBB enhanced massive mobile broadband
• MTC machine type communication
• the AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
• radio technologies such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
• the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface.
• the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface.
• the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
• the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.
• a PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.
• the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
• the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
• the CN 115 may facilitate communications with other networks.
• the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108.
• IP gateway e.g., an IP multimedia subsystem (IMS) server
• IMS IP multimedia subsystem
• the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
• the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
• DN local Data Network
• one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
• the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
• the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
• the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
• the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
• the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
• the emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
• the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
• the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
• the one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
• RF circuitry e.g., which may include one or more antennas
• a device may comprise a processor configured to perform one or more actions.
• the device may send assistance information.
• the assistance information may indicate a characteristic associated with the WTRU.
• the WTRU may receive coverage information, an external mobility conditional handover (CHO) configuration set, and/or a device mobility CHO configuration set.
• the WTRU may determine a mobility cause.
• the WTRU may determine a CHO candidate cell based on a non-radio measurement, the mobility cause, and/or the coverage information.
• the WTRU may determine that an execution condition is satisfied for the CHO candidate cell.
• the WTRU may send a RACH transmission to the CHO candidate cell.
• the device may determine, based on the non-radio measurement, a location associated with the WTRU and an orientation associated with the WTRU.
• the determination of the CHO candidate cell may be further based on the location and/or the orientation of the WTRU.
• the WTRU may determine a RACH configuration based on the CHO candidate.
• the RACH transmission may be sent in accordance with the RACH configuration.
• the CHO candidate cell may be associated with one or more beams, and the WTRU may determine a RACH configuration based on a strongest beam of the one or more beams associated with the CHO candidate cell.
• the RACH transmission may be sent in accordance with the RACH configuration.
• the WTRU may determine that a radio link condition indicating the degradation of a serving link is satisfied.
• the mobility cause may be associated with the radio link condition.
• the mobility cause may be device mobility, and the CHO candidate may be indicated in the device mobility CHO configuration set.
• the determination that the execution condition is satisfied may be based on a radio measurement and the non-radio measurement.
• Beam based procedures may be provided for use in a network (e.g., 5G NR).
• a network e.g., 5G-NR
• a network may operate in multiple (e.g., two) different frequency ranges, which may include, for example, sub-6 GHz (e.g., referred to as frequency range 1 (FR1 )) and/or millimeter wave (mmWave) (e.g., referred to as frequency range 2 (FR2)).
• FR1 frequency range 1
• mmWave millimeter wave
• the FR2 range may extend to 71 GHz.
• the range between 51 .4 GHz to 71 GHz may be referred to as FR2-2.
• a node of a network may transmit beams in multiple (e.g., all) directions in a burst, for example, at an interval (e.g., regular defined intervals).
• a WTRU may (e.g., if/when the WTRU is synchronizing with the network) read the synchronization signal block (SSB) and/or extract one or more of the following: a primary synchronization signal (PSS), a secondary synchronization signal (SSS), a physical broadcast channel (PBCH), and/or a demodulation reference signal (DMRS).
• PSS primary synchronization signal
• SSS secondary synchronization signal
• PBCH physical broadcast channel
• DMRS demodulation reference signal
• a PSS may include one or more (e.g., one of three) possible sequences.
• a PSS may provide a timing estimate.
• An SSS may include one or more (e.g., one of 336) possible sequences.
• a PBCH and/or a DMRS may include a master information block (MIB).
• MIB master information block
• a PBCH and/or a DMRS may include information (e.g., basic information) to proceed (e.g., take the next step), which may include decoding a system information block (e.g., SIB-1).
• Beam switching may be performed. Switching from one beam to another may be referred to as intra-cell mobility or beam-level mobility. Beam switching may be based on a trigger condition for a beam and/or a configured beam switching algorithm. Beam switching may be applicable, for example, if/when a WTRU is in connected mode. Beam switching may be performed through L1/ L2 procedures. Handover (e.g., on the other hand) may be used (e.g., typically) for inter-cell mobility. Handover may be an L3 procedure.
• Beam and/or link failures may occur.
• Network procedures may detect beam failure (e.g., and/or recovery) and/or radio link failure.
• Beam failure detection and recovery may be performed. WTRU mobility and/or changes in the wireless environment may lead to deterioration of a beam pair, for example, if/when a WTRU and the network are communicating through narrow beams. Beam level measurements and/or continuous evaluation procedures may help maintain and/or switch to the best beam pair between a WTRU and the network. The procedures may be jointly called beam failure detection and recovery (BFDR).
• BFDR beam failure detection and recovery
• FIGS. 3A and 3B illustrate examples of beam failure detection at the MAC Layer.
• the PHY layer of a WTRU may generate a “Beam Failure Instance (BFI),” for example, if/when the quality of a beam deteriorates (e.g., if/when the measurements from the configured reference signals for the beam fall below a configured threshold).
• BFI Beam Failure Instance
• the MAC layer may maintain a “BeamFailurelnstance Counter.”
• the MAC layer may increment the BFI counter and reset the “Beam Failure Detection Timer” for an (e.g., each) instance of the PHY layer reporting BFI. Beam failure may be detected, for example, if a BFI counter exceeds a configured value.
• Beam failure detection (BFD) may occur within the beam failure detection timer.
• FIGS. 3A and 3B show example situations for beam failure.
• FIG. 3A shows an example where the MAC layer receives a BFI from the PHY layer, but the beam failure detection timer expires, and no beam failure is generated.
• FIG. 3B shows an example where the PHY Layer is reporting BFI at a rate that is not letting the timer expire, the BFI counter reaches the BFD threshold, and the MAC layer generates a BFD.
• a WTRU may (e.g., after detection of the beam failure event) initiate a beam failure recovery (BFR) procedure.
• a WTRU may (e.g., once beam failure has been detected) try to recover from the beam failure, for example, if the candidate recovery beams are configured.
• a WTRU may try to validate the (e.g., configured) candidates for a given serving cell, for example, according to the configured/defined measurement quality condition(s) and thresholds.
• a WTRU may prepare a BFR MAC-CE or a truncated BFR MAC-CE, for example, according to the defined conditions (e.g., where the cells and/or recovery beams may be indicated for network knowledge).
• a beam recovery procedure may vary/differ, for example, based on whether the beam failure is detected on an SpCell or on an SCell.
• a WTRU may (e.g., after validating the configured candidate beams) choose a validated candidate beam for RACH transmission.
• a normal or truncated BFR MAC-CE may be sent as part of a RACH procedure.
• a RACH transmission may follow the parameters configured as part of a candidate beam configuration.
• a (e.g., successful) RACH transmission may let the network know that a WTRU has recovered through a candidate beam.
• a WTRU may (e.g., after having validated the candidate beams) transmit the BFR MAC-CE or truncated BFR MAC-CE to the network.
• a RACH procedure may not be initiated for beam failure recovery on an SCell.
• An RLF may be a T310 based RLF, which may be based on one or more link quality measurements (e.g., using SSBs and/or CSI-RSs).
• an RLF timer T310 may be started if consecutive out-of-sync indications (e.g., measurement below a threshold) are received a preset number of times (e.g., N310 times).
• the T310 timer may be reset, for example, if the channel quality recovers before the T310 timer expires.
• An RLF may be declared (e.g., upon expiration of the T310 timer), for example, if the channel quality does not recover before the T310 timer expires.
• An RLF may be a T312 based RLF.
• a WTRU may start a T312 timer based on (e.g., upon) triggering a measurement report, for which the T310 timer may already be running.
• a T312 timer may allow a WTRU to differentiate between an RLF caused by a handover failure from an RLF caused by coverage hole.
• a T312 timer may (e.g., typically) be shorter than the T310 timer.
• a shorter T312 timer may expire earlier than a T310 timer.
• An RLF may be timely declared, for example, if the channel quality of the source gNB is worse than a threshold.
• An HO process may fail, for example, due to poor channel qualities of a target node and/or the source node.
• handover problems may be exacerbated because the link qualities of the target and source nodes may deteriorate quickly due to mobile blockers and/or WTRU rotations.
• the blockage of a target node during a handover procedure may result in a handover failure (HOF).
• a handover failure timer T304 may be started, for example, if/when the WTRU receives an RRC reconfiguration message.
• a HOF may be declared, for example, if the T304 timer expires before the handover is completed.
• the time budget may be (e.g., further) decreased, for example, for applications with high (e.g., even higher) quality of service requirements.
• Mobility events may be the result of translational motion, rotational motion, and/or a change in a wireless medium (e.g., device mobility).
• WTRU rotations may come from rotational movements of handset/wearable devices, such as smartphones, game controllers, VR/XR headsets, etc. Movements may originate from hand gestures, head movements, etc. WTRU rotations may lead to channel variations between the serving node and the WTRU, which may cause beam misalignment and/or link/connection failures. Other types of dynamic changes may originate from translational mobility.
• An initial configuration of a deployment/coverage ensemble may be provided.
• a network may broadcast coverage ensemble information.
• a coverage ensemble system information block (SIB) may be specified.
• Coverage ensemble information broadcasted by a cell and/or a TRP may be configured to reflect a local deployment environment of a cell and/or TRP broadcasting the coverage ensemble.
• WTRU processing may achieve an effective coverage ensemble.
• a network deployment ensemble may be shared with one or more WTRUs, for example, following a configuration (e.g., as described herein), e.g., by adding attributes to a cell configuration and/or by one or more configurations having geographic attributes. Links of the TRP/beam level configurations may be provided to the (e.g., legacy) cell configurations.
• a WTRU may have a detailed effective coverage ensemble (e.g., also referred to as on-the-ground coverage ensemble), for example, to use in mobility events and/or effective selection of beams, cells, and/or TRPs.
• a deployment ensemble may be made rich enough so that it captures (e.g., all) topographical and/or shadowing aspects.
• a coverage ensemble may take into account TRP locations and/or beam attributes.
• a coverage ensemble may incorporate the physical nature of the environment around, which may include (e.g., the specifics of), for example, terrain and/or buildings (e.g., with all their physical attributes, which may shadow, block, and/or reflect the beams). Examples are provided to support/enable a WTRU acquiring/fabricating an on-the-ground coverage ensemble.
• a WTRU may process a network provided coverage ensemble.
• a network provided deployment configuration may be made (e.g., very) rich and/or refined.
• a network provided deployment configuration may be provided in the form of rich shapes, which may capture (e.g., all) the (e.g., specific) aspects of the local terrain, shadowing from buildings, and/or other objects.
• Different reference shapes may be defined, e.g., to indicate the shapes delimiting the cells/beam level coverage.
• reference shapes may be in the form of circles, ovals, ellipses, ellipsoids with parameterization, etc.
• the network may indicate the shapes with attributes and/or may provide links to the cell/beam identity, which may provide one or more advantages, for example, because the network knows (e.g., precisely) the deployment of network cells, TRPs, and/or beams.
• a network may have access to topographical data, for example, using a navigation system, cameras, and/or ongoing measurements on cells/beams from the devices that let the network know a (e.g., very precise) coverage ensemble.
• An (e.g., additional) advantage may be the use of (e.g., all) historic data, for example, in the form of network measurements, cells/beam transitions, which may be used to update and/or refine (e.g., detailed) coverage ensembles.
• Transmission of large amounts of information may have a large signaling overhead.
• the amount of information exchanged may be significant, for example, given that precise coverage for even a single beam may involve a set of objects and object attributes communicated to a WTRU.
• Large signaling overhead may involve a number of message exchanges (e.g., at RRC level), which may lead to increased configuration latency.
• a WTRU may process a network provided deployment ensemble.
• a network may provide to one or more WTRUs a snapshot of network nodes deployment and/or limited information about the beams the network transmits.
• a (e.g., snapshot of a) deployment ensemble may be used, for example, if/when a network provides (e.g., is providing) a network deployment configuration.
• a network may provide information about TRP locations, beam angles, and/or beam-specific parameters, for example, without modulating the coverage with the features of the local terrain.
• Providing a (e.g., snapshot of a) deployment ensemble may have lower signaling overhead and/or latency performance (e.g., by providing less information), for example, compared to providing a (e.g., detailed) coverage ensemble.
• Devices may receive deployment features/parameters for TRPs/beams.
• Devices may use the local knowledge (e.g., through other technologies), such as local stored topography, positioning systems, and/or cameras, to prepare a refined coverage ensemble, which may add topographical aspects to the deployment configuration (e.g., received from the network).
• WTRUs may (e.g., after local processing and fabrication) get/determine an effective ensemble, which may delimit different coverage zones associated with different beams and/or cells.
• a refined coverage ensemble may (e.g., then) be used in beam and/or cell level mobility procedures at the WTRU.
• a local physical coverage ensemble may be refined, for example, with the mobility and/or additional information obtained from other sensors.
• Devices may prepare an effective ensemble, for example, using the network provided deployment parameters combined with information from local sensors.
• Devices may use local sensors, additional storage, and/or compute capability to prepare effective ensembles, e.g., by combing network deployment with information from local sensors.
• Hybrid information may be provided/received (e.g., hybrid solutions/techniques may be standardized) to get (e.g., determine) a refined coverage ensemble at the devices.
• a network may send a refined ensemble to devices, for example, if one or more devices are not equipped with (e.g., necessary) local sensors, and/or don’t have (e.g., necessary) compute power to process and/or fabricate an ensemble.
• Devices having (e.g., necessary) local sensors, compute power, and/or storage may receive (e.g., only) limited deployment features from the network, and may prepare the effective ensemble locally.
• Hybrid information may (e.g., also) be used, for example, depending upon one or more of the following: WTRU power consumption requirements, battery quality, remaining battery, and/or as a function of active applications and/or application attributes.
• a deployment/coverage ensemble may be maintained.
• a WTRU may (e.g., based on/upon detection of change in coverage ensemble area) re-acquire a coverage ensemble for the WTRU’s current location.
• a re-acquisition may be in the form of dedicated RRC signaling.
• ensemble maintenance may be implemented by re-acquiring the coverage ensemble SIB.
• a WTRU may detect a change in a coverage ensemble area, for example, by one or more of the following: a change in serving cell or (re)selection to a cell that doesn’t belong to the current coverage ensemble area; a (re)selection to an RNA that doesn’t belong or doesn’t correspond to the current coverage ensemble area; execution of an RNA update procedure, and/or transmission of an RNA update message to the network (base station); a (re)selection to a TA that doesn’t belong, and/or an ensemble that doesn’t correspond to the current coverage ensemble area; execution of a TA update procedure, and/or transmission of a TA update message to the network (core network); and/or a (re)selection to a PLMN that doesn’t belong, and/or an ensemble doesn’t correspond to the current coverage ensemble area.
• a deployment/coverage ensemble configuration may be released.
• a WTRU may discard coverage ensemble configuration information, for example, if the ensemble configuration information becomes/gets outdated.
• An outdated indication may be derived/determined, for example, if a WTRU changes coverage area and/or is not able to acquire the updated coverage ensemble.
• a configuration may include/comprise one or more (e.g., explicit) timers, which may result in a WTRU releasing the configuration (e.g., if the one or more timers are expired).
• Timers may be refreshed, for example, if the WTRU stays (e.g., is staying) in an area associated with the WTRU’s current coverage ensemble.
• a coverage ensemble area may be defined, for example, in terms of RNA, TA, PLMN, and/or other condition(s).
• a network may send an (e.g., explicit) indication to a WTRU to release a coverage ensemble configuration.
• a WTRU may release a coverage ensemble configuration, for example, if the WTRU goes out of an RRC active state.
• a network may provide an indication of a deployment/coverage ensemble.
• Deployment ensembles may be provided to a WTRU.
• Cells/beam configurations and mobility configurations with the deployment configuration may be related.
• An ensemble indication may be provided as part of a cell/beam configuration.
• a deployment ensemble may be part of a cell configuration.
• a cell configuration may be part of a conditional (re)configuration associated with candidate cells, which may be part of a conditional handover or conditional PSCell change/addition procedure.
• a deployment ensemble may be associated with one or more serving cell configurations.
• a deployment ensemble may be used for one or more (e.g., any of) the beam management procedures, such as one or more of beam switching, beam failure recovery, etc.
• Attributes may define, for example, one or more of the following: the TRPs where the cell is being transmitted, the locations of the TRPs in global and/or local coordinate systems, and/or the beam coverage attributes for the beams being transmitted through the TRPs.
• a configuration may provide the information on SSB beams and/or CSI-RS beams.
• Attributes for beams may be in the form of azimuthal and/or elevation angle, e.g., with reference directions. Reference directions may be taken from cardinal directions and/or may be indicated as part of the configuration.
• the range for the beams may be indicated, for example, as per beam attribute and/or a (e.g., single) value, which may indicate the unobstructed range in view of the transmit power.
• Beam attributes may define the beam width in horizontal and/or vertical directions.
• a (e.g., simpler) deployment may specify a (e.g., one single) beam width attribute for horizontal and/or a (e.g., one) for vertical directions, which may be (e.g., assumed to be) the same for (e.g., all) the configured beams.
• a network may provide a (e.g., one) value for a TRP with delta values (e.g., as appropriate) for each beam, for example, for deployments with varying beam width sizes.
• a network may provide beam width as part of a beam configuration without a TRP and/or cell level indication.
• the coverage for a (e.g., each) beam may be specified as an ellipsoid, e.g., with parametrization.
• An ensemble indication may be provided as an independent (e.g., dedicated) configuration.
• an ensemble may be provided as an individual configuration to WTRUs.
• a coverage ensemble configuration may not be part of a cell configuration and/or a conditional (re)configuration.
• a coverage ensemble may depend on a geographic deployment and/or coverage, for example, while coverage ensemble configuration and/or signaling may be provided by the network independent of the cell configuration and/or other conditional (re)configurations.
• a coverage ensemble configuration may be in the form of network nodes deployment and/or beam attributes and/or in the form of on the ground detailed coverage, which may incorporate topographic and/or terrain-specific features.
• a coverage/deployment ensemble configuration may provide the linkage of indicated TRP locations and/or beam attributes to cell identities and/or cell configurations.
• An ensemble indication may be provided as broadcast signaling.
• a deployment/coverage ensemble indication may be transmitted by a network, for example, in the form of broadcast signaling.
• Information may be broadcast by a network.
• Devices e.g., relevant devices/WTRUs
• Devices may be (pre)informed and/or may have (e.g., prior) knowledge how to get and decode the information.
• control information to locate ensemble related broadcast information may be broadcast, e.g., through paging (e.g., special paging) and/or downlink control information (e.g., special downlink control information) informing (e.g., all) the devices about the broadcast based ensemble information.
• an ensemble indication may be treated as part of system information.
• a system information block (SIB) may carry and/or convey a deployment/coverage ensemble indication.
• the network may use (e.g., periodic) transmission of an ensemble SIB to keep the WTRUs aware of the ensemble information.
• WTRUs which may be starting (e.g., relevant) services where outage may be minimized, may send a (e.g., an explicit) request to the network requesting the transmission of the ensemble SIB.
• Measurement procedures and/or a framework may be based on measurement identities.
• a measurement identity may link a measurement object with a reporting configuration.
• a measurement object may constitute an object over which a WTRU may perform measurements.
• a measurement object may indicate one or more (e.g., a combination) of time, frequency, bandwidth, and/or sub-carrier spacing parameters, which may be relevant for the reference signal over which the WTRU may perform measurements.
• a reporting configuration may provide one or more of the reporting condition(s), the nature of the reporting whether periodic, an event trigger, and/or cell global identity reporting. In some examples (e.g., for event triggered reporting), a reporting configuration may provide a triggering event and/or parameters that may be relevant for the event.
• a measurement identity may (e.g., always) link a measurement object and a reporting configuration.
• Measurement objects e.g., current measurement objects
• Measurement objects may belong to the same RAT through which measurements are being configured and/or inter-RAT measurements, which may be defined over other 3GPP technologies. Examples are provided for nonradio-measurements from non-3GPP RATs, which may be generated by/received from local sensors and/or from other sources.
• Reporting for non-radio measurements may be performed in the same or similar manner as reporting for radio measurements.
• Non-radio measurements may trigger events in the same or similar manner that radio measurements trigger events.
• Non-radio measurements and/or indicated events may be used for mobility procedures and/or conditional reconfigurations in the same or similar manner that radio measurements may be used for mobility procedures and/or conditional reconfigurations.
• Mr may be the WTRU rotation estimated by the WTRU, for example, through its local sensors, e.g., not taking into account any offsets.
• Rotation estimation may be over a duration not exceeding a duration Td, which may be configured as part of the configuration.
• Hys may be the hysteresis parameter for this event (e.g., hysteresis as defined within configuration for this event).
• Threshl may be the threshold for this event, for example, defined as an amount of reference rotation within configuration for this event, e.g., and used as rotation threshold to enter this event.
• Mr may be the WTRU rotation estimated by the WTRU, for example, through its local sensors, e.g., not taking into account any offsets.
• the rotation estimation may be over a duration not exceeding a duration Td, which may be configured as part of the configuration.
• Hys may be the hysteresis parameter for this event (e.g., hysteresis as defined within configuration for this event).
• Threshl may be the threshold for this event, e.g., defined as an amount of reference rotation within configuration for this event and/or used as rotation threshold to enter this event.
• Thresh2 may be the threshold for this event, e.g., defined as an amount of reference rotation within configuration for this event and/or used as rotation threshold to exit this event. Mr may be expressed in degrees. In some examples, Mr may be expressed in radians. In some examples, the unit for Mr may be configured as part of the configuration. Hys may be expressed in the same unit as Mr. Threshl and Thresh2 may be expressed in the same unit as Mr.
• the definition of Event R1 may apply to CondEvent R1 .
• Event OD1 may be associated with device orientation and/or distance matching the location of a given TRP, e.g., within one or more thresholds.
• Ml may be the WTRU location, which may be represented by the distance between WTRU and a reference location parameter for this event (e.g., reference location of candidate TRP for this event), e.g., not taking into account any offsets.
• Ou may be the WTRU absolute orientation estimated by WTRU, for example, through its local sensors, e.g., not taking into account any offsets.
• Hys1 may be the hysteresis parameter for orientation condition used for this event.
• Thresh 1 may be the threshold for this event, for example, defined as an amount of reference orientation within configuration for this event and/or used as rotation threshold to enter this event.
• Thresh2 may be the threshold for this event, for example, defined as a distance from a reference location configured in configuration for this event. Ou may be expressed in degrees, e.g., with respect to a configured measurement reference. In some examples, Ou may be expressed in radians. In some examples, the unit for Ou may be configured as part of the configuration. Hys1 may be expressed in the same unit as Ou. Threshl may be expressed in the same unit as Ou. Ml may be expressed in meters. Hys2 may be expressed in the same unit as Ml. Thresh2 may be expressed in the same unit as Ml. The definition of Event OD1 may apply to CondEvent OD1 .
• Event OD2 may be associated with device orientation and/or distance matching being better for a location of a given TRP than the serving TRP, e.g., according to the configured thresholds.
• the WTRU may consider the entering condition for this event to be satisfied if both condition OD2-1 and condition OD2-2, e.g., as specified herein, are fulfilled.
• the WTRU may consider the leaving condition for this event to be satisfied if condition OD2-3 or condition OD2-4, e.g., as specified herein, is fulfilled.
• condition OD2-3 or condition OD2-4 e.g., as specified herein
• Ou may be the WTRU reference orientation in absolute units estimated by WTRU, for example, through its local sensors, e.g., not taking into account any offsets.
• Op may be the orientation of the serving TRP in absolute units from the WTRU, for example, as estimated by WTRU, e.g., using the location of the serving TRP received in configuration.
• On may be the orientation of the neighbor TRP in absolute units from the WTRU, for example, as estimated by WTRU, e.g., using the location of the neighbor TRP received in configuration.
• Hysl may be the hysteresis parameter for orientation condition used for this event.
• Dp may be the distance between WTRU location and the location of the serving TRP.
• Event CM1 may be associated with a device crossing out the boundary of a specific zone in the coverage ensemble.
• the WTRU may consider the entering condition for this event to be satisfied if condition CM1-1 , e.g., as specified herein, is fulfilled.
• the WTRU may consider the leaving condition for this event to be satisfied if condition CM1-2, e.g., as specified herein, is fulfilled.
• condition CM1-1 e.g., as specified herein
• condition CM1-2 e.g., as specified herein
• MI1 may be the WTRU location, which may be represented by the distance between the WTRU and a reference location parameter for this event, e.g., not taking into account any offsets.
• a reference location parameter may be configured as the center of the zone or a suitable reference point of the zone. It may be configured as the location of a TRP serving this zone.
• Hys may be the hysteresis parameter for this event (e.g., hysteresis as defined within reportConfigNR for this event).
• Threshl may be the threshold for this event, for example, defined as a distance from a reference location (e.g., serving TRP) to a boundary of the coverage ensemble.
• the WTRU may derive Threshl from the coverage ensemble, for example, using the information of the WTRU’s current location, the serving TRP location, and/or the boundary definition, e.g., according to the configuration.
• the boundary definition may correspond to the coverage of RNA, TA, PLMN, and/or TRP coverage.
• a configuration may provide information indicating whether Threshl may be an LOS distance (e.g., in which case, Threshl may be the distance of the coverage boundary on the line joining the serving TRP and WTRU) and/or a different calculation may be used.
• MI1 may be expressed in meters. Hys may be expressed in the same unit as MI1 .
• Threshl may be expressed in the same unit as MI1 .
• Event CM1 may apply to CondEvent CM1 .
• Event CM2 may be associated with a device entering a specific zone in the coverage ensemble.
• the WTRU may consider the entering condition for this event to be satisfied if condition CM2-1 , e.g., as specified herein, is fulfilled.
• condition CM2-2 e.g., as specified herein, is fulfilled.
• MI1 may be the WTRU location, which may be represented by the distance between the WTRU and a reference location parameter for this event, e.g., not taking into account any offsets.
• the reference location may be attributed to center or a suitable reference point of the specific zone to which this event may be associated.
• Hys may be the hysteresis parameter for this event (e.g., hysteresis as defined within reportConfigNR for this event).
• Threshl may be the threshold for this event, for example, defined as a distance from a reference location (e.g., reference location of the reference zone) to a boundary of the coverage ensemble.
• the WTRU may derive Threshl from the coverage ensemble, for example, using the information of its current location, the reference node/TRP location, and/or the boundary definition, e.g., according to the configuration.
• the boundary definition may correspond to the coverage of RNA, TA, PLMN, and/or node/TRP coverage.
• the configuration may provide information indicating whether Threshl may be an LOS distance (e.g., Threshl may be the distance of the coverage boundary on the line joining the reference TRP and WTRU) and/or a different calculation may be used.
• MI1 may be expressed in meters. Hys may be expressed in the same unit as MI1. Threshl may be expressed in the same unit as MI1 .
• the definition of Event CM2 may apply to CondEvent CM2.
• Joint Event J1 may be associated with a device entering a specific zone in the coverage ensemble, where the reference cell in this zone becomes better than a threshold.
• the WTRU may consider the entering condition for this event to be satisfied if condition J1-1 and condition J1-2, e.g., as specified herein, are fulfilled.
• the WTRU may consider the leaving condition for this event to be satisfied if condition J1-3 or J1-4, e.g., as specified herein, is fulfilled.
• condition J1-3 or J1-4 e.g., as specified herein
• the WTRU may derive Threshl from the coverage ensemble, for example, using the information of its current location, the reference node/TRP location, and/or the boundary definition, e.g., according to the configuration.
• the boundary definition may correspond to the coverage of RNA, TA, PLMN, and/or node/TRP coverage.
• the configuration may provide the information whether Threshl may be an LOS distance (e.g., Threshl may be the distance of the coverage boundary on the line joining the reference TRP and WTRU) and/or a different calculation may be used.
• Mn may be the measurement result of the neighboring cell, e.g., not taking into account any offsets.
• Ocn may be the measurement object specific offset of the neighbor cell (e.g., offsetMO as defined within measObjectNR corresponding to the neighbor cell).
• Ocn may be the measurement object specific offset of the neighbor cell (e.g., celll ndividualOffset as defined within measObjectNR corresponding to the neighbor cell), which may be set to zero, e.g., if not configured for the neighbor cell.
• Hys2 may be the hysteresis parameter for this event (e.g., hysteresis as defined within reportConfigNR for this event), which may be used in cell measurement conditions.
• Thresh2 may be the threshold parameter for this event (e.g., a4-Threshold as defined within reportConfigNR for this event).
• Ml may be expressed in meters.
• Hys1 may be expressed in the same unit as MI1 .
• Threshl may be expressed in the same unit as MI1 .
• Mn may be expressed in dBm (e.g., for RSRP) or in dB (e.g., for RSRQ and/or RS-SINR).
• Ocn Hys2 may be expressed in dB.
• Thresh2 may be expressed in the same unit as Mn.
• the definition of Event J1 may apply to CondEvent J1.
• Joint Event J2 [OD2 && A4] may be associated with device orientation and distance matching being better for a location of a given TRP than the serving TRP, e.g., according to the configured threshold(s).
• the WTRU may consider the entering condition for this event to be satisfied if conditions J2-1, J2-2 and J2-3, e.g., as specified herein, are fulfilled.
• the WTRU may consider the leaving condition for this event to be satisfied if any of the conditions J2-4, or J2-5 or J2-6, as specified herein, is fulfilled. For example:
• Ocp may be set to zero, for example, if not configured for the SpCell.
• Off may be the offset parameter for this event (e.g., a3-Offset as defined within reportConfigNR for this event).
• Thresh3 may be the threshold parameter for this event (e.g., a4-Threshold as defined within reportConfigNR for this event).
• Ou may be expressed in degrees, e.g., with respect to a configured measurement reference. In some examples, Ou may be expressed in radians. In some examples, the unit for Ou may be configured as part of the configuration.
• Op, On and Hys1 may be expressed in the same unit as Ou.
• Dn may be expressed in meters.
• Dp and Hys2 may be expressed in the same unit as Dn.
• Mn, Mp may be expressed in dBm in case of RSRP, or in dB in case of RSRQ and RS-SINR. Ofn, Ocn, Ofp, Ocp, Hys3, Off may be expressed in dB.
• the definition of Event J4 may apply to CondEvent J4.
• conditional (re)configurations such as one or more of the following: beam failure recovery, conditional handover, conditional PSCell change/addition, etc.
• Examples may be used to create/implement additional events jointly (e.g., over radio measurement and non-radio measurement quantities), which may identify a target scenario (e.g., in a very precise manner) and/or choose a (e.g., most suitable) beam/cell/TRP/node (e.g., in a fast manner), for example, based on the combinations.
• a target scenario e.g., in a very precise manner
• a beam/cell/TRP/node e.g., in a fast manner
• events A3 and A4 may be combined with non-radio measurement quantities, e.g., combining orientation, distance, and/or zone entrance.
• event A5 may be combined with non-radio measurement quantities.
• joint events J1 , J2, J3, and/or J4 may be (e.g., further) combined with a speed/velocity condition (e.g., as used in event V1), for example, to segregate high speed and low speed scenarios, e.g., and use suitable beams/cells/TRPs accordingly.
• a speed/velocity condition e.g., as used in event V1
• event R1 and/or event 01 may be combined with (e.g., classic) measurement quantity events (e.g., A3, A4, and/or A5), etc. to create/implement rotation focused conditional events, which may (e.g., then) trigger (re)configurations.
• classic measurement quantity events
• A3, A4, and/or A5 etc.
• Reporting associated with non-radio measurements may be used, implemented, etc. .
• a reporting framework may be (e.g., fully) applicable to non-radio measurements, for example, if measurement objects are defined for non-radio measurements.
• a WTRU may provide non-radio measurements (e.g., according to reporting configuration attributes, whether periodic or event triggered).
• Non-radio measurements may be (e.g., suitably) filtered, e.g., according to the quantity configuration.
• the WTRU may provide a report to the network, for example, with an indication of measurement identity, which may serve as a reference for the reporting.
• reporting for non-radio measurements may be based on a reporting configuration.
• Post-processing and/or filtering over non-radio measurements may not be applied or may be defined, e.g., a-priori without a quantity configuration.
• Proactive conditional handover feature(s), such as those described herein, may be based on non-radio measurements.
• a conditional handover (CHO) procedure may be defined as if/when a WTRU is provided with the configuration of candidate cells for a CHO with execution conditions.
• a WTRU may start a handover procedure with a candidate cell, for example, if/when an execution condition for a candidate CHO cell is satisfied, which may avoid a WTRU being unable to complete handover signaling exchanges with the source cell, resulting in handover failure, for example, if the current serving cell undergoes a fast failure.
• WTRU may need to perform an RRC connection re-establishment and/or, e.g., eventually, cell selection, which may result in latencies and/or outages (e.g., far) exceeding the QoS requirements for some applications.
• a proactive conditional handover may be implemented with predictive mobility.
• Cellular networks are planned networks.
• a network may have precise knowledge of its deployment of cells, e.g., and the beams within those cells.
• a network may not know how a WTRU may move from one cell/beam to another cell/beam. This information may (e.g., also) be unknown to the WTRU.
• a WTRU may not have information of network deployment (e.g., in terms of cells, beams, and/or geographic areas where the cells/beams are active).
• a WTRU may be equipped with one or more (e.g., many) local sensors.
• Knowledge of network deployment of cells/beams may be combined with the ability of a WTRU to track its movements and determine updated geographic location/position and orientation.
• the network may share a portion (e.g., suitable finite piece) of its deployment relevant to a WTRU, for example, based on assistance information received from the WTRU.
• the shared piece of network deployment may include/comprise, for example, neighboring cells, (e.g., relevant) beams, and/or a mapping of the (cell, beam) pairs to geographic coordinates.
• a configuration may include the execution conditions to perform a conditional handover to the configured (cell, beam) pairs.
• a WTRU may (e.g., in case of degradation over the link quality) use information from one or more local sensors and/or interfaces to extract the WTRU’s current geographic coordinates and orientation.
• the WTRU may use the parameters to determine a conditional handover candidate (cell, beam) pair, e.g., from the network provided configuration.
• the configuration parameters may provide the quality condition(s) and/or execution conditions for the candidate (cell, beam) pairs, e.g., along with their RACH configuration.
• the WTRU may initiate a conditional handover to the candidate (cell, beam) pair, for example, if the execution condition(s) is(are) fulfilled.
• the deterministic derivation of candidate (cell, beam) pairs based on the updated geographic coordinates may lead to WTRU mobility management, e.g., with seamless handovers and/or minimal interruptions.
• Assistance information from (e.g., provided by) a WTRU may be (e.g., broadly) categorized, for example, in two groups, which may be referred to as radio signal measurement-based data and non-radio signal measurement-based data.
• Radio signal measurement based data may be used synonymously with measurement based data.
• Non-radio-signal measurement based data may be used synonymously with non-measurement-based data.
• Non-measurement-based data may include/comprise (e.g., all) information that is not extracted from the network signaling.
• a first sub-group in non-measurement-based data may include/comprise WTRU capability and/or implementation details, which may cover one or more of the following: the WTRU’s antenna panels, respective field-of-views for those panels, transceivers and/or power characteristics, switching delays, simultaneous operation for the panels, etc.
• a second sub-group in non-measurement-based data may include/encompass (e.g., all), for example, one or more of the following: information extracted or measured through local sensors and interfaces (e.g., other than the radio interface where mobility is being considered), such as the WTRU geographic parameters, the WTRU location information, such as absolute position, relative positions to objects and/or other geographical markers, and/or a reference location of serving or neighboring cell/TRP(s).
• local sensors may include one or more of the following: positioning sensors, gyroscopes, accelerometers, speed monitoring sensors, etc.
• the WTRU may perform a conditional handover to the selected (cell, beam) pair, for example, using the determined RACH parameters.
• the network may provide (e.g., relevant) parameters to trigger conditional handover, for example, for a (e.g., each) (cell, beam) pair in a configured conditional handover set, e.g., in addition to the angular span around a WTRU.
• the parameters may include/comprise one or more contention free RACH preambles within the beam.
• Parameters may include the RACH parameters, e.g., one or more of RACH preamble sequence identity, RACH duration, power ramping parameters, parameters related to RACH occasions associated with the indicated beam, etc.
• a configuration may include the conditions under which the configuration stays valid.
• the configuration may have a timer.
• the validity of the configuration may expire upon the expiry of the timer.
• a configuration release condition may be associated with the mobility.
• a configuration may be released, for example, if the configured device moves away from its last known position/location by more than a configured threshold.
• a configuration may be released if a WTRU moves out of its current zone.
• a configuration may be valid in a current zone where direct neighbors have overlapping boundaries.
• a WTRU may (e.g., in this case) release a configuration, for example, if the WTRU moves out of direct neighbor zones.
• a configuration release condition may be associated with the device’s timing advance value (e.g., with the serving node).
• the device may be configured to release the current active configuration, for example, if the device moves and the change in the timing advance is above a configured threshold.
• One or more (e.g., any suitable combination of) parameters from the assistance information may be used to define validity conditions and/or release conditions.
• one or more configurations may be given to the device.
• the mapping/association of a configuration with a zone, a location, and/or a timing advance value/range may be given to the device.
• the device may select the configuration, for example, based on the tracking of the associated metric (e.g., one or more of zone, location, and/or timing advance, etc.).
• Some systems may use ultra-massive MIMO with a capability of deploying thousands of beams per TRP.
• Network deployment of beams may follow one or more rules to contain (e.g., reduce, minimize) signaling overhead.
• the rule(s) may be provided to a WTRU, for example, in a compact form.
• beam deployment for from a TRP may follow a pattern in azimuthal and/or elevation dimensions.
• a set of patterns may be known, for example, in tabular forms and/or through formulae.
• the network may choose a pattern for its deployment, for example, according to network requirements in a given geographic area.
• a network may (e.g., for such cells and/or beam deployments) provide a compact form of a deployment pattern to a WTRU, for example, as part of a proactive conditional handover configuration.
• the configuration may include the positions of TRPs in coordinates for candidate (cell, beam) pairs.
• a WTRU receiving a configuration may determine the nearest TRPs (e.g., for any location relevant) for each candidate (cell, beam) pair and (e.g., then) determine the candidate (cell, beam) matching its updated geographic coordinates.
• FIG. 8 illustrates an example of a proactive configuration for a conditional handover (e.g., with rotational motion).
• An example configuration for a WTRU rotation scenario is shown in FIG. 8 for a WTRU communicating with node 1.
• FIG. 8 shows an example configuration including/comprising an indication of a reference direction with the current beam, and the neighboring cells/beams with their spans.
• a beam from node 2 may be configured with its span marked with respect to the reference (e.g., beam) direction as a start angle (e.g., 02s) and an end angle (e.g., 02e).
• FIG. 8 shows the start and end angles for an exemplary beam from node 3 as 03s and 03e.
• the node may (e.g., for each configured candidate (cell, beam) pair) provide the RACH related details, for example, to allow contention free RACH access (CFRA) within that (cell, beam) pair.
• CFRA contention free RACH access
• the WTRU may determine the amount of rotation from its local sensors and determine the candidate node/beam which may provide coverage, e.g., post-rotation.
• the configuration may include the events on rotation/orientation (e.g., event R1 , 01 etc.) or joint events (e.g., events J2, J4 etc.) that the WTRU starts evaluating.
• event trigger the WTRU may extract the RACH parameters for the candidate and send a RACH transmission.
• the network may provide coverage information to a WTRU.
• the coverage information may indicate cells in the vicinity of the WTRU (e.g., as described herein).
• the WTRU may extract the candidate cells (e.g., on condition(s) of a mobility event, link degradation, and/or link failure), for example using sensors data and the coverage information (e.g., as described herein).
• the WTRU may validate the CHO candidate using radio and non-radio execution conditions (e.g., as described herein).
• the WTRU may perform CHO to the validated candidate (e.g., as described herein).
• FIG. 9 illustrates an example of a proactive configuration of a conditional handover (e.g., with translational and rotational motion).
• FIG. 9 shows an example scenario where a WTRU is configured by the network with multiple CHO candidates to counter/combat both translational and rotational motion.
• a WTRU may (e.g., in this case) be configured with a CHO configuration from different nodes, for example, with a location/position of the WTRU, orientation, and a mapping to the candidate CHO cells, such that the WTRU may determine the beam/node to attach using the mobility information from its local sensors.
• the location/position and/or angular span may be provided with reference to the WTRU position and orientation.
• FIG. 10 shows an exemplary scenario where a WTRU is moving on a road in a car.
• the WTRU may face situations where it crosses beams from a single TRP, beams from one TRP to a neighboring TRP controlled by the same control unit (CU), and/or moving from one beam of a given TRP to a beam from a different TRP under a different CU.
• FIG. 10 shows an example scenario where beams/cells switching may take place as a result of translational motion and/or rotational motion.
• the WTRU may be provided with a proactive beam failure recovery configuration (e.g., as described herein) and a proactive conditional handover configuration (e.g., as described herein).
• the WTRU may perform a proactive beam recovery and/or a proactive CHO, avoiding (e.g., any) outages while the WTRU may be moving (e.g., very) fast and/or traversing the beams and cells.
• FIG. 10 illustrates an example of a proactive beam recovery and conditional handover configuration.
• a WTRU may implement one or more features (e.g., associated with a procedure), for example as described herein.
• a WTRU may extract information from one or more local sensors, for example, if the WTRU undergoes compromised link quality.
• the WTRU may combine the extracted information with other radio measurements.
• Translational movement information may, for example, come from the local GPS receiver.
• Rotational movement may, for example, come from gyroscope and/or other components.
• the WTRU may compute its new geographic coordinates and/or orientation.
• the WTRU may use the geographic coordinates and/or orientation information to find a candidate (cell, beam) pair, e.g., from the network provided mapping of (cell, beam) pairs to geographic coordinates and/or orientation.
• the mapping may let a WTRU know (e.g., precisely) which beam of a cell from a node that may have line-of-sight connection with the WTRU, e.g., respect to its updated coordinates.
• the WTRU (e.g., therefore) may not need to perform blind cell searches to find which beams of which cells may be active (e.g., and suitable) after undergoing a mobility event.
• the WTRU may derive the (cell, beam) pair from the network provided configuration.
• the WTRU may evaluate the CHO condition with the (e.g., derived) target candidate pair.
• the WTRU may send a contention free RACH with the configured RACH parameters over the configured RACH resources (e.g., provided as part of the determined candidate (cell, beam) pair), for example, if the CHO trigger condition is satisfied.
• FIG. 11 shows an example of a proactive conditional handover, where the proactive conditional handover may include one or more of the features illustrated in FIG. 11 .
• a CHO candidate (e.g., each CHO candidate) in a CHO configuration set may include one or more cells (e.g., and associated beams).
• a cell e.g., each cell
• a CHO candidate may be associated with and/or included in multiple CHO candidate sets.
• Coverage information (e.g., received by the WTRU) may indicate a network deployment of cells and beams.
• the proactive CHO configuration and coverage information may be received via one of: a WTRU dedicated signal or a broadcast system information.
• a second condition may be if/when the CHO candidate becomes better than a second configured threshold.
• the execution conditions may be specified in terms of joint radio and non-radio measurement quantities and joint events (e.g., as specified in Events J1, J2, J3 and J4 etc.).
• ultra-massive MIMO beams may have a variety of deployment possibilities, e.g., including layered and/or hierarchical architectures.
• Reference signals may (e.g., suitably and/or rapidly) identify, detect, and/or measure ultra-massive MIMO beams.
• the reference signals may be used to identify (cell, beam) pairs.
• the reference signals may be provided as part of a network configuration.
• Quality condition(s) and/or CHO execution conditions) e.g., conditional A3/A5 and/or other condition(s)
• a configuration for CHO candidates may be provided as a unified configuration, e.g., to enable proactive conditional handover.
• the candidates and/or their priorities e.g., all the candidates and/or their priorities
• the WTRU may determine the RACH configuration for the determined CHO candidate, and perform CHO (e.g., perform handover based on condition(s) described herein begin satisfied) to the determined CHO candidate with the determined RACH parameters.
• FIG. 12 shows a flowchart for a proactive conditional handover. FIG. 12 (e.g., compared to FIG.
• FIG. 11 shows that the network configuration for CHO candidates is provided in a unified manner, e.g., encompassing candidates for (e.g., targeting) external mobility and device mobility.
• FIG. 12 illustrates an example associated with a proactive conditional handover, e.g., with a unified mobility configuration.
• the WTRU may send assistance information to a base station of the network (e.g., a gNB).
• the assistance information from the WTRU may include information from local sensors (e.g., position sensors, gyroscope, accelerometer, etc.), panels, and/or field of view (FoV). Additional groups and constituent elements for WTRU assistance information (e.g., as described herein) may be provided.
• a WTRU may receive a unified proactive CHO configuration set (e.g., of CHO candidates).
• the unified proactive CHO configuration set may include a mapping of CHO candidates to geographical coordinates, span, FoV, and/or WTRU panels.
• a WTRU may get (e.g., obtain, collect, determine) information from its local sensors, for example, to decide whether a link failure is happening due to device mobility or external mobility, for example, if/when the WTRU is undergoing a link failure situation and/or the quality of the serving link falls (e.g., is falling) below a configured threshold.
• the WTRU may use this information (e.g., from local sensors) combined with other sensor’s information to pick a (e.g., the most suitable) CHO configuration (e.g., a CHO candidate).
• the WTRU may activate a different antenna panel (e.g., as per the selected configuration), for example, to attach the most suitable CHO candidate.
• the WTRU may activate the antenna.
• the WTRU may evaluate the execution condition for the selected CHO candidate.
• the CHO execution condition may be configured, for example, in terms of RSRP, RSRQ, and/or SI NR using indicated measurement objects.
• the CHO configurations may provide the same or different execution conditions for different CHO candidates.
• the WTRU may (e.g., if the selected CHO candidate satisfies the execution condition) select the RACH configuration associated with the selected (cell, beam) candidate and/or transmit RACH as part of the CHO initiation, which may trigger the fast attach procedure to the CHO candidate. As shown in FIG.
• the WTRU may perform CHO to the determined CHO candidate with the determined RACH parameters.
• a configuration may be provided for a proactive conditional handover.
• An indication of a coverage ensemble from the network may include cell/beam level granularity and/or a zones configuration, which may provide a WTRU with knowledge about different cells/beams serving neighboring zones.
• the network may provide (e.g., independently) a set of candidate CHO cells.
• the CHO candidates may be indicated with associated beams and/or other relevant parameters to initiate CHO.
• Location/orientation information from local sensors may lead a WTRU to determine the target cell/beam serving the zone of its latest position, for example, if/when the WTRU moves from a zone served by one cell to another zone served by another cell.
• the WTRU may (e.g., then) extract the cells and/or their relevant beams serving the zone from the network provided deployment/coverage ensemble configuration. This may allow the WTRU to evaluate execution conditions for the CHO candidates, determine RACH parameters, and/or initiate CHO to the successful candidate.
• the WTRU may determine the candidate (cell, beam) pairs corresponding to its determined zone, for example, using the WTRU’s local copy of Coverage ensemble.
• the WTRU may short-list the candidates that are part of the proactive CHO configuration.
• the WTRU may evaluate the configured execution conditions for the target CHO candidates, for example, where the conditions may be a combination or composite over radio and non-radio measurements (e.g., events OD1/2 combined with events A3/A4/A5, etc.).
• the WTRU may determine its associated RACH configuration from the received CHO configuration, for example, if execution conditions get fulfilled for a CHO candidate.
• the WTRU may perform the conditional CHO on the target candidate (cell, beam) pair, for example, using the determined RACH parameters.
• one or more of the following may be performed (e.g., by a WTRU) during a proactive CHO.
• a WTRU may send assistance information (e.g., proactive assistance information) to a network (e.g., a base station, a node, etc. of the network).
• the assistance information may indicate characteristic(s) associated with the WTRU, e.g., as discussed herein.
• a characteristic of the WTRU may be one or more of: a position of the WTRU; an orientation of the WTRU; a number of panels; an active antenna panel; a capability (e.g., of the WTRU) to determine its rotation, translation, and/or position (e.g., such as through sensors); or a field of view (FoV) of the WTRU.
• a characteristic of the WTRU may be one or more of: a position of the WTRU; an orientation of the WTRU; a number of panels; an active antenna panel; a capability (e.g., of the WTRU) to determine its rotation, translation, and/or position (e.g., such as through sensors);
• the assistance information may comprise, for example, one or more of the following groups of information: radio measurement quantity based data; non radio measurement quantity based data; and/or WTRU capability and implementation details.
• the transmission of assistance information may be in response to contextual and/or situational triggers (e.g., starting of a car or starting of game.
• Contextual and/or situation triggers may include translational or rotational triggers.
• a CHO configuration set (e.g., each CHO configuration set) may comprise one or more of the following: one or more CHO candidates (e.g., groupings of cells and their associated beams); an execution condition of a CHO candidate (e.g., each CHO candidate) in the CHO configuration set; a mapping of a CHO candidate (e.g., each CHO candidate) in the CHO configuration set to geographic coordinates and/or orientation; and/or a priority of a CHO candidate (e.g., each CHO candidate) in the CHO configuration set.
• one or more CHO candidates e.g., groupings of cells and their associated beams
• an execution condition of a CHO candidate e.g., each CHO candidate
• a mapping of a CHO candidate e.g., each CHO candidate
• a priority of a CHO candidate e.g., each CHO candidate
• the network may transmit coverage information to the WTRU (e.g., in addition to CHO configuration information).
• the coverage information may indicate a network deployment of cells and beams.
• the coverage information may provide the WTRU with one or more cells in the WTRU’s vicinity.
• the coverage information may be received by the WTRU over a WTRU dedicated signal and/or a system information broadcast.
• the coverage information may be transmitted by the network to a WTRU (e.g., over a WTRU dedicated signal) upon receipt of assistance information from the WTRU.
• the WTRU may determine a CHO candidate based on one or more of: a mobility cause, coverage information, or CHO configuration information (e.g., CHO configuration sets). For example, if the WTRU determines a mobility cause is device mobility, the WTRU may determi ne/select a CHO candidate (e.g., a (cell, beam) pair) from (e.g., received) device mobility CHO configuration information. For example, if the WTRU determines a mobility cause is external mobility, the WTRU may determine/select a CHO candidate (e.g., a (cell, beam) pair) from (e.g., received) external mobility CHO configuration information.
• a mobility cause is device mobility
• the WTRU may determine/select a CHO candidate (e.g., a (cell, beam) pair) from (e.g., received) external mobility CHO configuration information.
• a CHO candidate may be determi ned/selected (e.g., by the WTRU) from a mapping table (e.g., for device mobility CHO configuration information and/or for an external mobility CHO configuration information).
• the determination/selection of a CHO candidate (e.g., by a WTRU) may be based on the WTRU’s determined geographic coordinates (e.g., position/location, orientation, etc.) and/or radio measurements.
• the WTRU may select a highest priority CHO candidate (e.g., (cell, beam) pair) from the candidates of CHO configuration information (e.g., the CHO configuration information corresponding to a determined mobility cause).
• the WTRU may activate an antenna panel associated with the selected CHO candidate. For example, the WTRU may switch an active antenna panel according to coverage information and/or a selected CHO candidate.
• the WTRU may evaluate (pre)configured execution conditions for a CHO candidate (e.g., before selecting/transmitting to the CHO candidate).
• the WTRU may perform the CHO to the CHO candidate (e.g., target cell on the target beam), for example, if the execution condition is satisfied.
• the WTRU may send a RACH transmission to the determi ned/selected CHO candidate cell.
• the determined/selected CHO candidate cell may be associated with one or more beams.
• a RACH configuration may be determined (e.g., by the WTRU) based on the determined/selected CHO candidate (e.g., a strongest beam associated with the CHO candidate).
• the RACH transmission may be sent in accordance with the RACH configuration.
• the set(s) (e.g., two sets) of conditional handover configurations may be associated with device mobility and/or external mobility.
• the sets of CHO configurations may be (e.g., indicated to be) associated with one or more QoS requirements of one or more applications/services, which may be running at the WTRU device.
• the sets of CHO configurations may be (e.g., indicated to be) associated with one or more WTRU power consumption requirements.
• the sets of CHO configurations may be (e.g., indicated to be) associated with the WTRU subscription.
• a (e.g., only one) unified configuration may be provided to the WTRU.
• a WTRU may be configured by the network jointly for a proactive conditional handover.
• Features may (e.g., also) be applicable to proactive beam recovery.
• One or more of the following may apply.
• a WTRU may be configured with a proactive BFR and CHO.
• FIGS. 15A-15C show an example where a WTRU may be provided (e.g., by the network) with a proactive BFR configuration and a proactive CHO configuration.
• the WTRU may provide assistance information to the network.
• the network may determine (e.g., and create/generate) a proactive BFR configuration and a proactive CHO configuration, for example, using the assistance information and the network’s known deployment of cells, beams, and/or location of TRPs.
• the network may configure the WTRU with the configurations for proactive BFR and CHO.
• the configurations may include, for example, one or more details as described herein.
• FIGS. 15A-15C illustrate an example where a WTRU may be configured with a proactive BFR configuration and a proactive CHO configuration. As shown in FIGS. 15A-15C, one or more of the following features may be applied/implemented.
• a WTRU may (e.g., if the link quality degrades for the WTRU) extract information from its measurements, interfaces, and/or local sensors, for example, to determine the WTRU’s updated geographic coordinates and/or orientation.
• the determination of an updated geographic coordinates and/or orientation may (e.g., additionally) use radio measurements, e.g., to make the estimate more precise, robust, and/or granular.
• a WTRU may determine whether there is a proactive recovery beam.
• the WTRU may extract the (e.g., relevant) configured parameters and/or initiate beam recovery, for example, using a derived recovery beam (e.g., if the WTRU finds the recovery beam).
• a beam recovery (e.g., if configured and possible) may be prioritized over a conditional handover.
• a beam recovery may be prioritized, for example, because a CHO may involve an update of the cell configuration, which may involve configurational changes (e.g., with respect to the current active cell configuration) and/or may have a higher impact on the QoS (e.g., compared to beam recovery).
• FIGS. 15A-15C may be implemented.
• FIGS. 15A-15C show beam recovery prior to finding a CHO candidate.
• a WTRU may simultaneously evaluate BFR and CHO configurations, e.g., with respect to the WTRU updated determined geographic coordinates. The WTRU may select the most appropriate candidate from BFR and/or CHO configurations.
• the WTRU may not find a recovery beam.
• the WTRU may determine whether there is a CHO configuration for the updated position.
• the WTRU may (e.g., if the WTRU is configured with a CHO configuration matching its determined coordinates) choose/select the (cell, beam) pair from its selected CHO configuration.
• the WTRU may initiate the CHO execution, for example, if the execution conditions are fulfilled.
• the WTRU may, for example, try a highest priority candidate first before trying the next highest priority candidate.
• Multiple candidates with a priority indication may be provided for a BFR and/or a CHO.
• a proactive BFR and/or CHO procedure may not be successful (e.g., succeed to completion), which may be the result of one or more of the following: the WTRU may not receive a positive response to its BFR recovery transmission, a CHO condition may not be fulfilled, CHO execution may fail, and/or a CHO/BFR configuration may be missing for the WTRU coordinates.
• the WTRU may (e.g., based on unsuccessful completion) resort to another (e.g., legacy) beam recovery and/or handover procedure.
• the WTRU may (e.g., eventually) fall back to RRC reestablishment and/or cell selection procedures.
• a WTRU may be configured with a proactive BFR and CHO.
• An exemplary embodiment specifying a procedure to have Proactive features may be associated with a WTRU undergoing bad radio situations, which may result in beam/link failures. One or more of the following may apply.
• the node may prepare multiple configurations for a proactive BFR and a proactive CHO, for example, based on one or more of the following: the WTRU assistance information, a WTRU profile, application/services that may be running at the WTRU, a WTRU subscription level, and/or the network knowledge of its deployment of cells, beams, and/or transmission nodes.
• the node may transmit the sets of configurations to the WTRU.
• the WTRU may receive the proactive BFR and CHO configurations from the node, which may comprise, for example, one or more of the following: a set of (e.g., two) proactive BFR configurations and a set of (e.g., two) proactive CHO configurations.
• a WTRU may have the configuration for the current PCell.
• a WTRU may save the cell configuration, for example, if the WTRU changes to another PCell (e.g., if this is indicated as part of the conditional configuration).
• the execution conditions may be provided while the PCell is indicated as a potential CHO candidate (e.g., for later use).
• a conditional PSCell change (CPC) and CPC candidates may become non-volatile CPC configurations and non-volatile CPC candidate cells.
• the WTRU may execute the associated conditional configuration, for example, if the execution conditions are fulfilled to one of the CHO candidates (e.g., volatile or non-volatile).
• the WTRU may (e.g., after successful execution) release the volatile candidates (and configurations) while retaining non-volatile candidates (e.g., and configurations) as active.
• the WTRU may continue monitoring the trigger conditions for the retained candidates and configurations.
• the WTRU may continue performing the execution of the conditional configuration to the candidate fulfilling the conditions.
• the WTRU may (e.g., after each execution) release the volatile candidates/configurations and maintain the non-volatile candidates/configurations as active.
• the WTRU may release the concerned configurations/candidates, for example, if/when the release conditions for non-volatile configurations/candidates are fulfilled.
• Non-volatile conditional configurations/candidates may have one or more release conditions. Release conditions may be used individually or in one or more combinations to release the non-volatile conditional configurations/candidates.
• a configuration release (e.g., for non-volatile configuration/candidates) may be conditioned upon a number of executions (e.g., a set number of executions).
• a release condition for non-volatile configuration/candidates may be specified in terms of a threshold on how many times a WTRU executes the conditional configuration.
• a threshold may be configured with value N.
• the WTRU may release the configuration/candidates, for example, after performing N conditional configurations (e.g., after being configured with the non-volatile configuration).
• the network may re-set or re-configure the value of a threshold, for example, by sending a message to the device.
• An example message may be in the form of RRC signaling providing an updated value for the threshold.
• a (e.g., more) dynamic update/refresh may use, for example, MAC and/or PHY signaling.
• a configuration release (e.g., for non-volatile configuration/candidates) may be an RRC state change based configuration release.
• the release conditions for non-volatile configurations may be defined in terms of a change in a WTRU RRC state.
• a device of interest may release non-volatile conditional configurations/candidates, for example, if the device of interest moves out of an RRC active state (e.g., moving to RRC inactive state or RRC idle state).
• a release condition may be a configured (group-)sequence based configuration release.
• a subset of cells may be assigned a sequence number #1 , #2, and #3.
• the subset of cells assigned to #1 may a set of cells that serve an overlapping area using narrow beams.
• the subset of cells assigned to #2 and #3 may serve subsequent overlapping areas.
• a WTRU may keep (e.g., all) the configurations (e.g., initially), for example, as long as the WTRU is performing a CHO among the candidates in subset #1 .
• a release condition may be a RAN tracking area based configuration release.
• the release conditions for non-volatile conditional configurations may be specified in terms of a tracking area identity (e.g., instead of assigning the set of cells, and their conditional configurations, an artificial group identity).
• a WTRU may release (e.g., all) the configurations (e.g., and candidates) having the same RAN tracking area of the previous PCell, for example, if the WTRU moves to a conditional configuration candidate with a new RAN tracking area.
• Release based on a tracking area may provide a grouping mechanism, where a network may (e.g., implicitly) know (e.g., and control) how and which configurations may be kept active by a WTRU. Release based on a tracking area may make use of RAN tracking area codes, which may group cells (e.g., similar to the highway example). [0391] In some examples, release conditions may be defined in terms of a RAN registration area, e.g., where multiple tracking areas may be defined. A RAN registration area may use existing or new cell or cell group identities, which may be specified to be used in release conditions.
• cells may be configured as non-volatile CHO with timers.
• the timers may be reset, for example, each time the WTRU performs CHO to one of the configured CHO candidates.
• a successful CHO among the set may imply that the WTRU is still in the vicinity and prone to implement another CHO, e.g., potentially from the same set of cells.
• Resetting the timers may avoid the timers getting expired, which may permit the WTRU to implement a subsequent CHO without interruption (e.g., and without configuration overhead).
• a network being able to configure the PCell as one of the nonvolatile CHO candidates may be (e.g., extremely) advantageous, for example, to support a WTRU moving frequently among a small subset of cells as its PCell follows the rotation events, which may occur in combination with limited translational mobility.
• a release condition (e.g., for rotational mobility focused scenarios) may be triggered by an event when the WTRU hands over to a cell that is not part of the non-volatile CHO candidates.
• the triggering of the event may imply (e.g., in some deployment scenarios) that the WTRU has moved out of the boundary where the originally configured CHO candidates were useful, which may lead to the release of the candidates and associated configurations.
• nonmeasurement data based conditions may be specified to release the non-volatile configurations/candidates.
• a WTRU may release a non-volatile configuration, for example, if the WTRU moves away a certain distance from a reference location (e.g., specified as the device location and/or in terms of a reference point from the network, such as a serving or a different TRP location, or a general network provided reference location).
• a reference location e.g., specified as the device location and/or in terms of a reference point from the network, such as a serving or a different TRP location, or a general network provided reference location.
• a WTRU may provide assistance information to a network (e.g., a node).
• the network may configure non-volatile proactive CHO candidates, for example, based on the received WTRU assistance information, the network deployment of cells/beams and network nodes, and/or the network data/WTRU profile.
• the candidates may be bound to the geographic locations of the WTRU.
• the WTRU may be provided with the locations and/or orientation of beams from a set of network nodes.
• the WTRU may derive the best node/beam/cell, for example, based upon its location/orientation.
• CHO candidates may be configured as non-volatile, e.g., as described herein.
• a WTRU may not release CHO configurations, for example, even if the WTRU undergoes a handover after receiving a proactive non-volatile CHO configuration.
• Proactive features may be associated with a WTRU undergoing a conditional handover with nonvolatile conditional configurations. One or more of the following may apply.
• the WTRU may receive the proactive CHO configuration from the node.
• the proactive CHO configuration may comprise, for example, a set of non-volatile conditional configurations.
• a (e.g., each) configuration may be indicated for a scenario/condition.
• a (e.g., each) configuration may comprise, for example, one or more of the following: a set of CHO candidate (cell, beam) pairs; a mapping of each candidate (cell, beam) pair to geographic coordinates and/or orientation for Device Mobility and External Mobility; a mapping of each candidate (cell, beam) pair to geographic coordinates and/or orientation; a priority of (cell, beam) pairs, for example, if/when multiple (cell, beam) pairs may have overlap over geographic zones/orientations; an execution condition for each conditional configuration; and/or a release condition for each non-volatile conditional configuration.
• the WTRU may select the highest priority CHO candidate (cell, beam) pair among the determined candidates.
• the WTRU may activate the antenna panel associated with the selected CHO candidate.
• the WTRU may evaluate the configured execution conditions for the target CHO candidate.
• the WTRU may perform the conditional CHO to the CHO target cell on the target beam, for example, if the execution condition is satisfied.
• the WTRU may evaluate the release conditions for non-volatile configurations/candidates.
• the WTRU may continue evaluating the execution conditions (e.g., and may execute the conditional configuration upon fulfillment), for example, if the release condition(s) is(are) not satisfied.
• the WTRU may release the associated non-volatile configurations/candidates, for example, if the release conditions are fulfilled.
• the release condition for the non-volatile configuration may be defined, for example, in terms of a timer expiry.
• the release condition for the non-volatile configuration may be defined, for example, in terms of a threshold.
• the non-volatile configuration may be released, for example, if/when the number of executions exceeds the configured threshold.
• the release condition for the non-volatile configuration may be defined, for example, to trigger based on (e.g., upon) the WTRU changing state from RRC Active.
• the release condition for the non-volatile configuration may be defined, for example, in terms of a configured (group-)sequence, e.g., where the subsets of non-volatile candidates may be associated with an (e.g., one) entry of the configured sequence (e.g., in a suitable manner).
• the release condition for the non-volatile configuration may be defined, for example, in terms of a RAN notification area and/or a RAN tracking area identity.
• the WTRU may release the associated non-volatile configuration, for example, in case of a change in the RAN notification area and/or RAN tracking area identity.
• the release condition for the non-volatile configuration may be defined, for example, in terms of one or more WTRU location coordinates.
• the release condition for the non-volatile configuration may be defined, for example, in terms of one or more non-measurement data quantities, e.g., WTRU distance from a reference location exceeding a configured threshold.
• Non-volatile conditional (re)configuration (e.g., as described herein) may be applied in the context of conditional handover.
• Non-volatile configuration may (e.g., also) be applied to a conditional CPC and/or CPA.
• a WTRU may be configured to perform a conditional CPC with a non-volatile configuration and/or non-volatile CPC candidates.
• Proactive features may be associated with (e.g., the secondary cell group for) a WTRU undergoing a conditional PSCell change with one or more non-volatile conditional configurations. One or more of the following may apply.
• the WTRU may perform the conditional CPC on the target candidate (cell, beam) pair, for example, using the determined RACH parameters.
• the WTRU may evaluate the release conditions for non-volatile configurations/candidates (e.g., as described herein).
• the WTRU may continue evaluating the execution conditions (e.g., and may execute the conditional configuration upon fulfillment), for example, if the release condition(s) is(are) not fulfilled.
• the WTRU may release the associated non-volatile configurations/candidates, for example, if the release condition(s) is(are) fulfilled.
• the processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor.
• Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media.
• Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as compact disc (CD)-ROM disks, and/or digital versatile disks (DVDs).
• a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=88237383

Family Applications (1)

Country Status (3)

Family Cites Families (3)

• 2023
  • 2023-09-06 WO PCT/US2023/032053 patent/WO2024054481A1/en not_active Ceased
  • 2023-09-06 EP EP23783127.6A patent/EP4584997A1/de active Pending
  • 2023-09-06 CN CN202380075562.XA patent/CN120113287A/zh active Pending

Also Published As

Similar Documents

Legal Events