CN116686390A - Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU - Google Patents
Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU Download PDFInfo
- Publication number
- CN116686390A CN116686390A CN202180080333.8A CN202180080333A CN116686390A CN 116686390 A CN116686390 A CN 116686390A CN 202180080333 A CN202180080333 A CN 202180080333A CN 116686390 A CN116686390 A CN 116686390A
- Authority
- CN
- China
- Prior art keywords
- wtru
- relay
- remote
- rrc
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 162
- 230000005540 biological transmission Effects 0.000 claims description 125
- 238000011084 recovery Methods 0.000 claims description 49
- 238000012545 processing Methods 0.000 claims description 22
- 238000013468 resource allocation Methods 0.000 claims description 21
- 238000004891 communication Methods 0.000 description 59
- 230000007246 mechanism Effects 0.000 description 33
- 230000015654 memory Effects 0.000 description 33
- 230000006870 function Effects 0.000 description 29
- 238000005259 measurement Methods 0.000 description 28
- 230000011664 signaling Effects 0.000 description 27
- 238000005516 engineering process Methods 0.000 description 24
- 230000008859 change Effects 0.000 description 23
- 230000004044 response Effects 0.000 description 22
- 230000000737 periodic effect Effects 0.000 description 21
- 230000007704 transition Effects 0.000 description 21
- 101000998783 Homo sapiens Insulin-like 3 Proteins 0.000 description 17
- 230000004048 modification Effects 0.000 description 17
- 238000012986 modification Methods 0.000 description 17
- 238000012544 monitoring process Methods 0.000 description 16
- 238000007726 management method Methods 0.000 description 14
- 230000001960 triggered effect Effects 0.000 description 13
- 102100022887 GTP-binding nuclear protein Ran Human genes 0.000 description 11
- 230000009471 action Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 11
- 208000016344 lissencephaly with cerebellar hypoplasia Diseases 0.000 description 10
- 238000012360 testing method Methods 0.000 description 10
- 241000760358 Enodes Species 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000001228 spectrum Methods 0.000 description 7
- 238000010187 selection method Methods 0.000 description 6
- 230000008093 supporting effect Effects 0.000 description 6
- 238000003860 storage Methods 0.000 description 5
- 102100039292 Cbp/p300-interacting transactivator 1 Human genes 0.000 description 4
- 101000888413 Homo sapiens Cbp/p300-interacting transactivator 1 Proteins 0.000 description 4
- 230000006399 behavior Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 101150096310 SIB1 gene Proteins 0.000 description 3
- 230000004913 activation Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 239000000969 carrier Substances 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 230000009977 dual effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000004088 simulation Methods 0.000 description 3
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 2
- 238000004873 anchoring Methods 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000001976 improved effect Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 229910001416 lithium ion Inorganic materials 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- QELJHCBNGDEXLD-UHFFFAOYSA-N nickel zinc Chemical compound [Ni].[Zn] QELJHCBNGDEXLD-UHFFFAOYSA-N 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 102100022734 Acyl carrier protein, mitochondrial Human genes 0.000 description 1
- 101100396152 Arabidopsis thaliana IAA19 gene Proteins 0.000 description 1
- 230000005355 Hall effect Effects 0.000 description 1
- 101000678845 Homo sapiens Acyl carrier protein, mitochondrial Proteins 0.000 description 1
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- 101100274486 Mus musculus Cited2 gene Proteins 0.000 description 1
- 241000700159 Rattus Species 0.000 description 1
- 108091005487 SCARB1 Proteins 0.000 description 1
- 102100037118 Scavenger receptor class B member 1 Human genes 0.000 description 1
- 101150096622 Smr2 gene Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- OJIJEKBXJYRIBZ-UHFFFAOYSA-N cadmium nickel Chemical compound [Ni].[Cd] OJIJEKBXJYRIBZ-UHFFFAOYSA-N 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229910052987 metal hydride Inorganic materials 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 229910052759 nickel Inorganic materials 0.000 description 1
- PXHVJJICTQNCMI-UHFFFAOYSA-N nickel Substances [Ni] PXHVJJICTQNCMI-UHFFFAOYSA-N 0.000 description 1
- -1 nickel metal hydride Chemical class 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 238000001356 surgical procedure Methods 0.000 description 1
- 238000000411 transmission spectrum Methods 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- CSRZQMIRAZTJOY-UHFFFAOYSA-N trimethylsilyl iodide Substances C[Si](C)(C)I CSRZQMIRAZTJOY-UHFFFAOYSA-N 0.000 description 1
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
Methods and corresponding apparatus are provided for determining whether a relay WTRU may provide network-initiated connection services for a remote wireless transmit/receive unit (WTRU) based on a coverage status of the WTRU, a Channel Busy Ratio (CBR), and access control decisions made by the network. The methods may include receiving an in-coverage IC indication from the remote WTRU indicating that the remote WTRU is in an IC of a suitable cell; receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and forwarding the paging message on a side link and instructing the remote WTRU to trigger a radio resource control, RRC, connection via Uu if the CBR is above a threshold.
Description
Cross Reference to Related Applications
The present application claims the benefits of (i) U.S. provisional patent application No. 63/091488 filed on day 10, month 14 of 2020 and (ii) U.S. provisional patent application No. 63/136430 filed on day 1, month 12 of 2021; each of these applications is incorporated herein by reference.
Background
The first version of the New Radio (NR) side chain is focused on supporting internet of vehicles (V2X) related road safety services. The design is intended to provide support for broadcast, multicast and unicast communications in both out-of-coverage scenarios and in-network coverage scenarios. In addition, side link based relay functionality may provide side link/network coverage extension and power efficiency improvement in view of a wider range of applications and services.
Coverage for side-link based communications may be improved in relation to WTRU-to-network coverage extension and WTRU-to-WTRU coverage extension (WTRUs represent wireless transmit/receive units).
In summary, the side link connection can be further extended in the NR framework in order to support the enhanced QoS requirements.
Disclosure of Invention
The methods and apparatus described herein may determine whether an inactive relay WTRU may provide network-initiated connection services to a remote WTRU based on a coverage status of the remote WTRU, a Channel Busy Ratio (CBR), and access control decisions made by the network. Such methods may be implemented by a relay WTRU and may include: receiving an in-coverage (IC) indication from a remote WTRU indicating that the remote WTRU is in an IC of a suitable cell; receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and forwarding the paging message on a side link and instructing the remote WTRU to trigger an RRC connection via Uu if the CBR is above a threshold.
Other methods and apparatus for radio resource control connections are described herein. The methods may be implemented, for example, by a method used in a wireless transmit/receive unit (WTRU) and may include a method in a WTRU for restoring a Radio Resource Control (RRC) connection with a network when the WTRU connects to a relay WTRU via a PC5-RRC connection and has an active Uu RRC connection with the network via the relay. The method may include: detecting a side link radio link failure (SL-RLF) of the relay WTRU, performing cell reselection to select a suitable cell, and performing a Random Access Channel (RACH) procedure and providing a Packet Data Convergence Protocol (PDCP) status report in a data portion of the RACH under the same conditions as the cell to which the relay WTRU is connected.
Studies on NR sidelink relay may cover the use of both WTRU-to-network relay and WTRU-to-WTRU relay based on PC5 (sidelink). PC5 refers to a reference point where a WTRU communicates with another WTRU over a direct channel. In this case, communication with the base station is not required. Specifically, the NR-side links of the first version are focused only on supporting V2X-related road safety services based on the reasons/goals of the study. The design is intended to provide support for broadcast, multicast and unicast communications in both out-of-coverage scenarios and in-network coverage scenarios. In addition, in view of a wider range of applications and services, a side link-based relay function may be additionally studied to achieve side link/network coverage extension and power efficiency improvement.
To further explore coverage extension for side link based communications, WTRU-to-network coverage extension and WTRU-to-WTRU coverage extension may be improved.
For WTRU-to-network coverage extension, the WTRU requires Uu coverage reachability to reach the corresponding WTRU outside of a server or neighborhood in the PDN network. However, existing solutions regarding WTRU-to-network relay are limited to EUTRA-based technology (E-UTRA is the air interface of the mobile network upgrade path of 3GPP LTE, which is an acronym for evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access, also known as the work item of 3GPP Long Term Evolution (LTE), also known as evolved universal terrestrial radio access (E-UTRA) in the early draft of the 3GPP LTE specifications, and thus cannot be applied to NR-based systems for both NG-RAN and NR-based side link communication.
-for WTRU-to-WTRU coverage extension: proximity reachability is currently limited to single hop side links via EUTRA-based or NR-based side link technologies. However, this may not be sufficient without Uu coverage considering limited single hop side link coverage.
In summary, the side link connection may be further extended in the NR framework, for example, to support enhanced QoS requirements.
Mechanisms for single hop NR side link relay can be explored, including:
1. mechanisms with minimal specification impact that support the SA requirements of side-link based WTRU-to-network and WTRU-to-WTRU relay focus on the following aspects of layer 3 relay and layer 2 relay (if applicable):
-relay (re) selection criteria and procedure;
-relay/remote WTRU authorization;
QoS for relay function;
-service continuity;
the security of the relay connection after the work group responsible for the security aspect in 3GPP and called SA3 provides its conclusion;
impact on user plane protocol stack and control plane procedures (e.g. connection management of relay connections).
2. Assuming no new physical layer channels/signals, a mechanism for upper layer operation of the discovery model/procedure for side link relay is supported.
WTRU to network relay
Relay via proximity services (ProSe) WTRU-to-network relay is introduced to extend network coverage to out-of-coverage WTRUs using PC5 (device-to-device communication, D2D) between the out-of-coverage WTRU and the WTRU-to-network relay.
ProSe WTRU-to-network relay provides a generic L3 forwarding function that can relay any type of IP traffic between a remote WTRU and the network. One-to-one and one-to-many link communications may be used between the remote WTRU and ProSe WTRU to network relay. For both remote and relay WTRUs, only one single carrier (i.e., the public safety ProSe carrier) operation may be supported (i.e., uu and PC5 should be the same carrier for relay/remote WTRUs). The remote WTRU may be authorized by the upper layer and may be within the coverage of the public safety ProSe carrier or outside the coverage of any supported carrier, including the public safety ProSe carrier for WTRU-to-network relay discovery, (re) selection and communication. ProSe WTRU-to-network relay is always within the coverage of EUTRAN (E-UTRAN is an acronym for evolved UMTS terrestrial radio access network and is a combination of E-UTRA, user Equipment (UE) and E-UTRAN node B or evolved node B (eNB)). ProSe WTRU-to-network relay and remote WTRUs may perform side link communication and side link discovery.
Relay selection for WTRU to NW relay
Throughout the following, the terms rrc_inactive state/INACTIVE, rrc_active state/ACTIVE, rrc_idle/IDLE, rrc_connected/CONNECTED are used interchangeably and may refer to the state of the device. The Radio Resource Control (RRC) protocol is used for the air interface (Uu) in UMTS, LTE and 5G. The RRC protocol is a layer 3 (network layer) protocol used between the WTRU and the base station. The protocol is specified by 3GPP for UMTS, LTE and 5G new radios. The RRC message may be transmitted via PDCP protocol. The air interface is the radio frequency part of the circuit between the WTRU and the (active) base station.
The main functions of the RRC protocol include connection setup and release functions, system information broadcasting, radio bearer setup, reconfiguration and release, RRC connection mobility procedures, paging notification and release, and out-of-loop power control. By means of the signaling function, the RRC configures the user plane and the control plane according to the network state and allows the implementation of radio resource management policies.
The operation of the RRC may be directed by a state machine that may define certain states that the WTRU may be in. Different states in the state machine may have different amounts of radio resources associated with them, and these radio resources are resources that the WTRU may use when it is in a given particular state. The quality of service experienced by the user and the power consumption of the WTRU are affected by the state machine due to the different amounts of resources available in the different states. For example, after establishing an RRC connection, the WTRU may be in an rrc_connected state/CONNECTED, or in an rrc_inactive state/INACTIVE. If this is not the case, i.e., no RRC connection is established, the WTRU may be in RRC IDLE state/IDLE, for example.
Relay selection/reselection of ProSe WTRU-to-NW relay may be performed based on a combination of AS layer quality measurement (RSRP) and upper layer criteria:
The eNB may control whether the WTRU may act as a ProSe WTRU-to-network relay:
-ProSe WTRU-to-network relay operation may be supported in the cell if the eNB broadcasts any information associated with ProSe WTRU-to-network relay operation;
the eNB may provide:
-using transmission resources of broadcast signaling of rrc_idle state and dedicated signaling of rrc_connected state for ProSe WTRU-to-network relay discovery;
-receive resources for ProSe WTRU-to-network relay discovery using broadcast signaling;
the eNB may broadcast minimum and/or maximum Uu link quality (RSRP) thresholds that prose WTRU-to-network relay needs to adhere to before it may initiate a WTRU-to-network relay discovery procedure. In rrc_idle, the WTRU may use a threshold to autonomously start or stop the WTRU-to-network relay discovery procedure when the eNB broadcasts a pool of transmission resources. While in rrc_connected, the WTRU may use a threshold to determine if it may indicate to the eNB that it is a relay WTRU and that it wishes to initiate ProSe WTRU to network relay discovery;
if the eNB does not broadcast a pool of transmission resources for ProSe-WTRU-to-network relay discovery, the WTRU may initiate a request for ProSe-WTRU-to-network relay discovery resources by dedicated signaling, taking into account these broadcasted thresholds.
If ProSe-WTRU-to-network relay is initiated by broadcast signaling, it may perform ProSe WTRU-to-network relay discovery when it is in rrc_idle. If ProSe WTRU-to-network relay is initiated by dedicated signaling, relay discovery may be performed as long as it is in rrc_connected.
ProSe WTRU-to-network relay performing side link communication for ProSe WTRU-to-network relay operation is in rrc_connected. Upon receiving a layer 2 link setup request or TMGI monitoring request (upper layer message) from a remote WTRU, the ProSe WTRU-to-network relay may indicate to the eNB that it is a ProSe WTRU-to-network relay and is intended to perform ProSe WTRU-to-network relay side link communication. The eNB may provide resources for ProSe WTRU-to-network relay communications.
The remote WTRU may decide when to start monitoring ProSe WTRU-to-network relay discovery. The remote WTRU may transmit the ProSe WTRU-to-network relay discovery request message while in rrc_idle or rrc_connected, depending on the configuration of resources for ProSe WTRU-to-network relay discovery. The eNB may broadcast a threshold that the remote WTRU may use to determine whether it may transmit ProSe WTRU-to-network relay discovery request messages in order to connect or communicate with ProSe WTRU-to-network relay WTRUs. The rrc_connected remote WTRU uses the broadcasted threshold to determine whether it can indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe WTRU to network relay discovery and/or communication. The eNB may use broadcast or dedicated signaling to provide transmission resources and broadcast signaling to provide reception resources for ProSe WTRU-to-network relay operation. When RSRP exceeds the broadcast threshold, the remote WTRU may cease using ProSe WTRU-to-network relay discovery and communication resources.
The exact time of the traffic switch from Uu to PC5 or from PC5 to Uu may be up to higher layers.
The remote WTRU may perform radio measurements at the PC5 interface and use these radio measurements with higher layer standards for ProSe WTRU-to-network relay selection and reselection [62]. If the PC5 link quality exceeds a configured threshold (pre-configured or provided by the eNB), then ProSe WTRU-to-network relay may be considered appropriate in terms of radio standards. The remote WTRU may select a ProSe WTRU-to-network relay that meets higher layer criteria and has the best PC5 link quality among all suitable ProSe WTRU-to-network relays.
The remote UE may trigger ProSe WTRU to network relay reselection when:
-the PC5 signal strength of the current ProSe UE to network relay is below a configured signal strength threshold;
it receives layer 2 link release messages (upper layer messages) from ProSe UE to network relay [62].
WTRU-to-network relay for wearable device
Research on WRTU to NW relay is performed in the RAN for commercial use cases specific to wearable devices and IoT devices. Although such studies did not produce any specifications, technical Report (TR) provided some preferred solutions for such relays. In contrast to ProSe WTRU-to-NW relay using L3 (IP layer) relay methods, WTRU-to-NW relay for wearable devices is expected to be L2 relay based on the protocol stacks shown in fig. 2 and 3, where fig. 2 shows the user plane radio protocol stack for layer 2 evolved WTRU-to-network relay (PC 5) and fig. 3 shows the control plane radio protocol stack for layer 2 evolved WTRU-to-network relay (PC 5).
Connection establishment for unicast links in NR V2X
The relay solution in the previous release of the LTE specifications is based on a one-to-one communication link established at the upper layer (ProSe layer) between two WTRUs (remote WTRU and WTRU-to-NW relay). Such connections are transparent to the AS layer and connection management signaling and procedures performed at the upper layers are carried by the AS layer data channels. The AS layer is unaware of such a one-to-one connection.
In NR V2X release 16, the AS layer supports the concept of a unicast link between two WTRUs. Such unicast links are initiated by the upper layer (as in ProSe one-to-one connections). However, the AS is informed of the existence of such unicast links, AS well AS any data transmitted between peer WTRUs in a unicast manner. With such knowledge, the AS layer may support HARQ feedback, CQI feedback, and power control schemes dedicated to unicast.
Unicast links at the AS layer are supported via the PC5-RRC connection. The PC5-RRC connection is defined as follows:
the PC5-RRC connection is a logical connection between the source layer 2ID and the destination layer 2ID pair in the AS. One PC5-RRC connection corresponds to one PC5 unicast link. PC5-RRC signaling may be initiated after its corresponding PC5 unicast link is established. When the PC5 unicast link is released as indicated by the upper layer, the PC5-RRC connection and the corresponding side link SRB and side uplink DRB are released.
For each PC5-RRC connection that is unicast, one side link SRB is used to transmit the PC5-S message before the PC5-S security has been established. One side chain SRB is used to transmit PC5-S messages to establish PC5-S security. One side link SRB is used to transmit a PC5-S message after the PC5-S security has been established, protecting the message. One side link SRB is used to transmit PC5-RRC signaling, protect this signaling, and send it only after PC5-S security has been established.
The PC5-RRC signaling includes a side link configuration message (rrcrecon configuration sidelink) in which one WTRU configures RX related parameters for each Side Link Radio Bearer (SLRB) in the peer WTRU. Such reconfiguration messages may configure parameters of each protocol (service data adaptation protocol (SDAP), packet Data Convergence Protocol (PDCP), etc.) in the L2 stack. The receiving WTRU may acknowledge or reject such a configuration depending on whether it may support the configuration proposed by the peer WTRU.
Drawings
A more detailed understanding can be obtained from the following detailed description, which is given by way of example in connection with the accompanying drawings. The drawings in the present specification are examples. Accordingly, the drawings and detailed description are not to be regarded as limiting, and other equally effective examples are possible and contemplated. In addition, like reference numerals in the drawings denote like elements, and wherein:
Fig. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.
Fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A, in accordance with an embodiment.
Fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment.
Fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A, according to an embodiment.
Fig. 2 is a user plane radio protocol stack for a layer 2 evolved WTRU-to-network relay (PC 5).
Fig. 3 is a control plane radio protocol stack for a layer 2 evolved WTRU-to-network relay (PC 5).
Fig. 4 is a flow chart illustrating a representative method implemented by a WTRU for recovering a radio resource control connection.
Fig. 5 is a flowchart illustrating a representative method implemented by a relay WTRU for determining whether the relay WTRU may provide network-initiated connection services for a remote WTRU.
Fig. 6 is a flow chart illustrating an embodiment of a method for processing paging messages. The method may be implemented by an INACTIVE relay wireless receiving transmitting unit WTRU, for example by a relay in rrc_inactive state.
Fig. 7 is a flow chart illustrating a further embodiment of a method for processing paging messages. The method may be implemented by an INACTIVE relay wireless receive transmit unit WTRU (e.g., by a relay WTRU in an rrc_inactive state).
Detailed Description
Exemplary network for implementing embodiments
Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter Bank Multicarrier (FBMC), and the like.
As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, public Switched Telephone Networks (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.
Communication system 100 may also include base station 114a and/or 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. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, gnbs, NR node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
Base station 114a may be part of RAN 104/113 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).
More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, a base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115/116/117.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or High Speed UL Packet Access (HSUPA).
In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro) to establish the air interface 116.
In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a New Radio (NR) to establish the air interface 116.
In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface used by the 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., enbs and gnbs).
In other embodiments, 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 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106/115.
The RANs 104/113 may communicate with the CNs 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RANs 104/113 and/or CNs 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RANs 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 that may utilize NR radio technology, the CN 106/115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA, wiMAX, E-UTRA, or WiFi radio technology.
The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RANs 104/113 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.
Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
Although the transmit/receive element 122 is depicted as a single element in fig. 1B, 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 transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).
The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.
The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry battery packs (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 a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.
The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photographs and/or video), universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, wireless communications devices, and the like,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. Peripheral device 138 may include one Or a plurality of sensors, which may be one or more of: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.
WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit for reducing and/or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).
Fig. 1C is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with CN 106.
RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that 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 to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In an embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102a, for example.
Each of the evolved node 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 UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.
The CN 106 shown in fig. 1C 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 should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
The MME 162 may be connected to each of the evolved node bs 162a, 162B, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.
SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.
The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, 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. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.
Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).
In representative embodiments, the other network 112 may be a WLAN.
A WLAN in an 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 access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. 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 pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.
High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, via a combination of a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.
Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).
The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).
WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA (supporting only 1MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and possibly available.
The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
Fig. 1D is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over an air interface 116. RAN 113 may also communicate with CN 115.
RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 113 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, gnbs 180a, 180b may utilize beamforming to transmit signals to gnbs 180a, 180b, 180c and/or to receive signals from gnbs 180a, 180b, 180 c. Thus, the gNB180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB180a and gNB180 b (and/or gNB180 c).
The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from one transmission to another, from one cell to another, and/or from one portion of the wireless transmission spectrum to another. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).
The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.
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 UL and/or DL, support of network slices, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.
The CN 115 shown in fig. 1D 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 should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
AMFs 182a, 182b may be connected to one or more of gNB 180a, 180b, 180c in RAN 113 via an N2 interface and may function as a control node. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 162 may provide control plane functionality for switching between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi.
The SMFs 183a, 183b may be connected to AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. SMFs 183a, 183b may select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.
UPFs 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 a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.
In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-d, base stations 114a-B, evolved node bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN 185a-B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.
The simulation device may be designed to enable one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more emulation devices can perform one or more or all of the 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 can perform one or more functions 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 testing purposes and/or may perform testing using over-the-air wireless communications.
The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test laboratory and/or a test scenario in a non-deployed (e.g., test) wired and/or wireless communication network in order to enable testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and/or receive data.
Efficient use of side links and reachability of remote WTRUs, and detection of link problems
For L2 relay, the remote WTRU may initiate an RRC connection using Uu connection setup signaling via WTRU-to-NW relay. After the PC5-RRC connection to the relay, the remote WTRU may also perform a similar state transition to the network as it would if it were directly connected via Uu.
However, before and during this PC5-RRC connected state, multiple procedures may need to be performed at the remote/relay WTRU to ensure efficient use of the side link and reachability of the remote WTRU. In particular, the remote WTRU may experience a lack of Uu traffic. In this case it should keep the network reachable without having to consume power to monitor the side links of any relay traffic. The embodiments described herein relate to modeling of IDLE/INACTIVE of a WTRU when connected to a relay, and the behavior of a relay/remote WTRU with respect to its RRC state in terms of mobility with respect to a side link according to embodiments will be described below. Additional embodiments described herein relate to the manner in which a remote WTRU additionally receives paging or access system information in each of its Uu states (and prior to connection with a relay WTRU).
Further, the PC5-RRC connection may experience a link problem (e.g., PC 5-RRC), and such a link problem may be detected by the relay WTRU or the remote WTRU. Embodiments described herein relate to detecting this link problem and informing the network or other WTRUs in time is critical to avoid inefficient operation of relay WTRUs and remote WTRUs.
Method for control plane processing/access via WTRU to NW relay
Paging and DRX on SL for WTRUs in rrc_idle/rrc_inactive
Remote/relay WTRU informing the network of the relay/remote WTRU to which it is connected
The network may need a method to be able to know the remote WTRU that relays the WTRU PC5-RRC connection. Such methods may involve the relay WTRU notifying the network connected remote WTRU or the remote WTRU that is no longer connected. Alternatively, the remote WTRU may notify the network of the relay WTRU to which it is connected. The relay/remote WTRU may send a message to the network in either:
the remote WTRU may provide a relay/remote ID (e.g., L2 ID) to the network:
a. when the remote/relay WTRU transitions to rrc_connected;
b. when a PC5-RRC connection is established with the (possibly another/new) relay/remote WTRU;
c. when a RAN area update is triggered.
The relay WTRU may inform the network PC5 of the number of connected remote WTRUs and/or whether there is at least one PC5-RRC connected remote WTRU and/or ID of the connected remote UE if:
a. After receiving the request from the network;
b. after a change in the number of PC5-RRC connected WTRUs;
c. upon detecting a SL RLF of one of the remote PC5 connected WTRUs;
d. after establishing a PC5-RRC connection with the first remote WTRU or any remote WTRU;
e. when there are no more remote WTRUs in PC5-RRC connection with the relay WTRU;
f. during relay WTRU updating RAN area (e.g., in rrcreseume message);
g. after the remote WTRU makes the HO (e.g.,
RRCReconfigurationComplete)。
remote/relay WTRU informing the network of the relay/remote WTRU to which it is connected
According to an embodiment, the remote WTRU may inform the relay WTRU of its Uu coverage. For example, when the coverage of a remote WTRU changes (i.e., it moves from in-coverage to out-of-coverage or out-of-coverage to in-coverage), the remote WTRU may transmit a PC5-RRC message to its PC5-RRC connected relay WTRU and the remote WTRU may inform the relay WTRU whether it is in-coverage or out-of-coverage. In-coverage or out-of-coverage may be defined as whether the remote WTRU has a suitable cell that it may select on Uu. The remote WTRU may further inform the relay WTRU that the remote WTRU is in its coverage area.
An RRC connection release implicitly/explicitly releases all remote WTRUs
According to an embodiment, the relay WTRU may receive a release message (release to IDLE or release to INACTIVE) that implicitly/explicitly releases each of the remote WTRU PC5-RRC connections. For example, the relay WTRU may release all PC5-RRC connections upon receiving a release message, which may contain an explicit indication to perform such release.
According to an embodiment, the relay WTRU may receive a release message (release to IDLE or release to INACTIVE) that implicitly/explicitly releases each of the remote WTRU Uu connections. Specifically, the relay WTRU may receive a release of rrc_inactive/rrc_idle, which may include a release indication. Upon receiving such a release, the relay WTRU may transmit a message on PC5 to instruct one or more remote WTRUs to release their own Uu RRC connection. The relay WTRU may further indicate an RRC state (e.g., rrc_idle or rrc_inactive) to which the remote WTRU should transition. The remote WTRU may transition to rrc_idle/rrc_inactive or the state indicated in such a message upon receiving such a PC5-RRC message from the relay WTRU.
The remote WTRU transitions to SLDRX while in Uu RRC IDLE/INACTIVE
A remote WTRU connected to the network via a WTRU-to-NW relay may operate in a different RRC state (with the network) while having an active PC5 connection. In one solution, the remote WTRU may perform SL DRX when it transitions to Uu RRC IDLE/rrc_inactive. Such SL DRX at the remote WTRU may include monitoring a subset (in time/frequency) of the RX resource pool. Such SL DRX at the remote WTRU may include monitoring a different RX resource pool than the RX resource pool configured when the WTRU is not in SL DRX. In particular, the remote WTRU may initiate SL DRX when it receives a Uu release RRC message from the network (send the WTRU to rrc_inactive/rrc_idle). In particular, the remote WTRU may initiate SL DRX upon expiration of the Uu inactivity timer.
The remote WTRU is out of SL DRX while in RRC_IDLE/RRC_INACTIVE
The remote WTRU may deviate from SL DRX (i.e., initiate monitoring for SL outside of its defined DRX on period) on any of the following conditions:
-conditions related to the quality of attached SL relay: in particular, the remote WTRU may monitor the SL quality of the current relay WTRU while in DRX (e.g., by measuring the RSRP of discovery messages or similar periodic messages transmitted by the relay WTRU). If the quality is below the threshold, the remote WRTU may leave DRX. In particular, the remote WTRU may initiate relay discovery/monitoring with other relay WTRUs in addition to the currently connected remote WTRU.
-conditions related to a change of system information: in particular, the remote WTRU may determine whether the system information has changed (e.g., based on an indication from the remote WTRU). In the event that the system information has changed, the remote WTRU may disengage from DRX to acquire new system information.
-based on an explicit indication of the relay WTRU or the network: in particular, the relay WTRU may notify the remote WTRU that there is a transmission on SL that will fall outside of the DRX on period.
-the relay WTRU indicates in the SL paging message whether to initiate the Uu connection directly or via a relay
The relay WTRU may receive paging messages for each of its plurality of remote WTRUs. The relay WTRU may extract from the Uu paging message only paging records associated with its associated WTRU (i.e., with its remote WTRU having a PC5-RRC connection). The relay WTRU may include one or more such paging records within the SL message.
In addition to Uu paging records, the relay WTRU may send the following information on the SL paging message:
indication/command/preference indicating whether the remote WTRU should initiate a Uu connection directly on Uu or via SL relay
a. The relay WTRU may determine the value of such an indication based on a response from the network
i. For example, the network may explicitly include preferences (Uu or relay) in the paging message sent to the remote WTRU, and the relay WTRU may read such explicit indications when the page is received from the remote WTRU
For example, the relay WTRU may determine the value of such an indication based on the result of a recovery procedure to the network. For example, if the recovery procedure to the network fails (i.e., release/reject) at the remote WTRU, the relay may instruct the remote WTRU to perform the connection via Uu.
b. The relay WTRU may determine the value of such indication based on a Channel Busy Ratio (CBR):
i. for example, if the measured CBR at the relay WTRU is above a threshold and the relay (possibly) knows that the remote WTRU is in IC, the relay may instruct the remote WTRU to initiate a connection via Uu
c. The relay WTRU may determine the value of such an indication based on the coverage situation of the remote WTRU:
i. for example, the remote WTRU may send a message to the relay WTRU to provide coverage at the remote WTRU (e.g., in-coverage or out-of-coverage of the appropriate cell). The remote WTRU may send such a message each time the coverage situation changes. If the relay WTRU knows that the remote WTRU is within coverage of a suitable cell, the relay WTRU may determine (e.g., based on other factors) to send an indication that the remote WTRU is to connect via Uu
When a remote WTRU receives a paging message and such an indication, the remote WTRU may determine whether to initiate an RRC connection via Uu or via relay based on the value of such an indication, and possibly also:
i. Measured CBR;
access class of remote WTRU;
priority indication in paging message.
Arrival of paging messages for one or more remote WTRUs triggers a resource allocation operation at the relay WTRU
The relay WTRU may trigger one or more of the following operations related to resource allocation when the relay WTRU receives a Uu paging message with at least one paging record for a remote WTRU that PC5-RRC connects to the relay:
triggering RRC connection/recovery:
a. connection/restoration may indicate a cause value informing the network
i. One of the remote WTRUs receives a paging message from the network;
the remote WTRU receiving the paging message from the network is either in-coverage or out-of-coverage.
b. A relay at rrc_idle/rrc_inactive may trigger RRC connection/resume upon receiving a paging message destined for one or more of the remote WTRUs to which it is attached. The remote WTRU may indicate (e.g., in a connection cause, in an additional RRC message, or in the data portion of a two-step Random Access Channel (RACH)) what the connection/recovery is for.
c. The relay WTRU may receive a SL grant for transmitting the paging message to the remote WTRU in a message transmission associated with the recovery procedure (e.g., in a recovery message or a subsequent RRC reconfiguration message). In the case where the relay WTRU receives such an allocation, it may determine not to transmit an SR once it resumes the RRC connection.
Triggering SR
a. A relay WTRU configured in mode 1 may transmit an SR upon receiving a paging message addressed to one of its connected remote WTRUs. In particular, the relay WTRU may be configured with one or more dedicated SR configurations for use when receiving paging messages destined for a remote WTRU.
b. The relay WTRU may be configured with multiple SR configurations, where each SR configuration may be associated with any of the following:
i. the number of connected remote WTRUs. For example, a remote WTRU may be configured to have SR configurations associated with the number or range of connected remote WTRUs, and the corresponding SR configuration may be selected based on the number of connected remote WTRUs
The number of remote WTRUs that are paged in one or more time slots or within a time period: for example, a remote WTRU may be configured to have an SR configuration associated with the number of remote WTRUs that are paged over a period of time (e.g., over a previous SL DRX cycle).
Triggering SL resource (re) selection
a. A relay WTRU configured in mode 2 may trigger the SL resource selection procedure upon receiving Uu paging messages associated with one or more of its attached remote WTRUs. Alternatively, if a relay WTRU receives at least one paging message destined for one or more remote WTRUs within a given period of time (e.g., the last DRX cycle), the relay WTRU may trigger the SL resource selection procedure at a predefined time (e.g., at the end of the DRX cycle)
Triggering a 2-step/4-step RACH for transmitting SL resource requests
a. A relay WTRU in rrc_inactive may send a SL resource request in a 2-step or 4-step RACH procedure. The purpose of such SL resource requests may be to send SL paging messages. The WTRU may trigger such a 2-step/4-step RACH procedure upon receiving a Uu paging message for one or more of the connected remote WTRUs. Alternatively, such a procedure may be triggered for some pre-configured period of time (e.g., at the beginning/end of a Uu or SLDRX cycle) such that at least one paging message for a remote WTRU is received within such period of time
b. The relay WTRU may receive the SL resource allocation in a subsequent downlink transmission (in or after a 2/4 step RACH procedure). Such subsequent downlink grants may have a (pre) configured SL grant size. Alternatively, the SL grant size may vary with:
a. the number of WTRU paging records received in a paging occasion prior to the SL resource request for the attached remote WTRU;
b. an indication of the number of paging records in the request (2-step/4-step RACH) and/or an index to a table of the number of paging records and/or the grant size of the request.
Such downlink grants may employ (pre) configured parameters relating to time/frequency resources. The DL message may provide an index of the resource offset according to a (pre) configured or predefined resource. For example, the DL message may contain an index representing an offset according to:
a. Paging occasions of the remote WTRU;
b. paging occasions of the relay WTRU;
c. preconfigured time slots (e.g., time slots provided in system information).
Implicitly trigger a change in transmit mode at the relay WTRU (e.g., mode 2 to mode 1 or mode 1 to mode 2)
Triggering transmission on pre-defined or (pre) configured side chain resources and/or implicitly allocating side chain resources
a. For example, the relay WTRU may perform transmissions (e.g., transmissions of Uu paging messages) on SL resources pre-configured for such transmissions (e.g., grant of configuration for SL paging transmission reservation)
b. For example, the relay WTRU may implicitly determine the SL resource allocation by receiving a paging message for one or more of its attached remote WTRUs. In particular, such receipt of paging messages may be employed to allocate SL resources to relay WTRUs for transmission of paging messages. The relay WTRU may determine time/frequency resources for SL resources to transmit the paging message based on:
i. fixed/(pre) configured time offset from receipt of Uu paging message
Any content of paging messages (e.g., resource index, offset, etc.)
The number of remote WTRUs that may be paged in a given time or in a given time slot
A WTRU may be configured to conditionally decide what resource allocation to take after receiving a remote WTRU page
Operation of the preparation
According to embodiments, the relay WTRU may determine which of the above operations to perform (or whether to perform the above operations) based on one or more conditions associated with the sidelink/relay connection. Specifically, the relay WTRU may be configured to: the first operation is performed if the following first condition is satisfied, and the second operation is performed if the following second condition is not satisfied. Alternatively, the relay WTRU may perform the first operation if the condition is met, and may not perform any operation if the condition is not met. The relay WTRU may determine whether to perform the above-described resource allocation operations/which of the above-described resource allocation operations based on any one or a combination of the following:
-the measured CBR, possibly compared with a threshold value
Content of paging messages
a. For example, the paging message contains an access category or access type
b. For example, the paging message contains a high priority indication, or is based on a priority value provided in the paging message
-type of RLC bearer, or configuration of RLC bearers at the relay WTRU and associated with the remote WTRU
a. For example, the RLC bearer may be configured to have an attribute indicating whether the WTRU should perform the first operation or the second operation
Coverage status of the remote WTRU (which may be provided to the relay WTRU via PC 5-RRC)
-number of remote WTRUs connected to the relay WTRU
In accordance with an embodiment, in the event that CBR is below a threshold, the relay WTRU may initiate an RRC recovery procedure to the network to obtain resources on PC5 to forward the paging message. When CBR is above the threshold, the relay WTRU may request resources using the 2-step/4-step RACH procedure described herein.
According to another embodiment, the relay WTRU may initiate an RRC recovery procedure if the paging message does not contain a high priority access/indication, or if the priority is below a threshold. On the other hand, in the case that the paging message contains a high priority indication, or if the priority is above a threshold, the relay WTRU may request SL resources while remaining at INACTIVE.
According to an embodiment, the relay WTRU may trigger an RRC connection resume message indicating that the reason for the resume message is that the relay WTRU received a paging message for at least one of its remote WTRUs. The relay WTRU may receive a resume message that transitions the relay WTRU to rrc_connected. In this case, the relay WTRU may further receive SL resource allocations for transmitting the SL paging message in the resume message. Alternatively, after the relay WTRU is in rrc_connected, the relay WTRU may receive the SL grant in the DCI schedule. On the other hand, the relay WTRU may receive an RRC reject/RRC release message from the network indicating that the relay WTRU should remain in rrc_inactive. In this case, the remote WTRU triggers a mode 2 resource selection procedure to obtain resources for transmitting pages via the side-chain.
According to an embodiment, if the remote WTRU is in coverage and the SL CBR is above a threshold, a relay WTRU in rrc_inactive/rrc_idle may transmit a paging message over the SL while remaining in rrc_inactive/rrc_idle. Otherwise, the relay WTRU may initiate a recovery procedure, indicating in the resumeRequest whether the remote WTRU is in-coverage or out-of-coverage. If the relay WTRU receives the recovery message, the relay may transmit the paging message while in rrc_connected. The relay may use SL resources provided by the network in DCI or in a resume message. If the relay WTRU receives a reject/release message in response to the resume, the relay may transmit a paging message on the SL while maintaining INACTIVE/IDLE and further indicate to the remote WTRU that it should initiate the connection via Uu. This may be the case if the relay WTRU knows that the remote WTRU is in coverage. On the other hand, if the remote WTRU is out of coverage and the relay receives a reject message, the relay WTRU may discard the paging message.
A relay WTRU determines a DRX wake-up slot for each remote WTRU and provides it to the remote WTRU
According to embodiments, the relay WTRU may determine a DRX wakeup slot for each remote WTRU and provide it to the remote WTRU to use as a DRX period that the remote WTRU would use while in rrc_idle/rrc_inactive. The WTRU relay WTRU may independently determine such DRX pattern for each remote WTRU. Alternatively, the relay WTRU may determine a common DRX period to provide to all remote WTRUs that PC5-RRC connects to the relay WTRU. The relay WTRU may provide DRX configuration to the remote WTRU in a PC5-RRC message. Such configurations may include:
-a period of DRX wake-up time;
-a RX resource pool to be used when the remote WTRU is in DRX on SL;
-timing of paging frames/slots within DRX;
-timing of any system information transmissions relative to DRX transmissions;
-WTRU ID or similar ID used by the remote WTRU to calculate the wake-up time and or timing of paging on SL.
The relay WTRU may determine the DRX wake up slot of the remote WTRU based on any one or a combination of the following:
-relay RRC state of WTRU
a. For example, when the relay WTRU is rrc_connected, the relay WTRU may use a different standard/method to calculate the DRX wakeup slot of the remote WTRU than when the relay WTRU is rrc_idle/rrc_inactive.
RRC state of remote WTRU
a. For example, the relay WTRU may use a first criteria/method to determine the DRX on period when the remote WTRU is in rrc_idle and may use a second criteria/method to determine the DRX on period when the remote WTRU is in rrc_inactive
Uu paging occasions for one or more of the remote WTRUs
a. For example, the relay WTRU may align the DRX on period for the remote WTRUs with each of their Uu paging occasions, so that the remote WTRUs wake up for SL DRX at or after such paging occasions
-number of attached remote WTRUs
a. For example, the relay WTRU may determine the length of the on duration of the remote WTRU DRX cycle based on the number of remote WTRUs
Uu paging occasion for remote WTRU
a. For example, the relay WTRU may select a configuration of DRX cycles that maximizes the number of remote WTRUs that fall within a single on duration
CBR on SL
a. For example, the relay WTRU may determine the length of the DRX on duration based on the measured CBR
-bearer configuration (SL RLC bearer configuration or UL bearer configuration) of remote WTRUs and/or QoS of active bearers configured at each remote WTRU
a. For example, the relay WTRU may calculate the maximum delay between the remote WTRU Uu paging frame and the start of the DRX on period for the remote WTRU based on the QoS of any active bearers at the remote WTRU (i.e., for the case where the remote WTRU is in rrc_inactive).
Remote WTRU determines SL time slots that it should wake up on SL to receive paging/SI
The remote WTRU may determine one or more SL slots during which the remote WTRU should monitor for SL to receive the page. The WTRU may monitor the SL for one or more slots per DRX period on the side link. For example, the WTRU may be configured to have and/or determine a SL paging window consisting of a set of time slots in which the WTRU may receive Uu pages via a SL transmission of the relay WTRU. In particular, the WTRU may be configured to wake up from DRX during a particular time slot and continue to monitor SL during a fixed number of time slots. Alternatively, the WTRU may monitor the SL until a paging message is received. Such paging messages may include paging information for other WTRUs. The WTRU may stop monitoring for SL after receiving such a paging message. Alternatively, if the paging message is not intended for the WTRU in question, the WTRU may continue to monitor for SL during the entire number of slots. The remote WTRU may determine the DRX period and/or the location/number of time slots to monitor based on any one or a combination of the following:
-network configuration
-group member ID provided by upper layer
a. For example, the WTRU may determine its SL slot to perform SL monitoring and/or its SL slot for which it expects to receive paging messages and/or system information on the SL based on the group member ID provided by the upper layer
b. For example, a WTRU may determine its SL paging slot by employing the UL paging slot (calculated as done in Uu) and adding an offset that depends on the group member ID
An identity (relay WTRU L2 ID or another ID) provided/dedicated to the relay WTRU by the relay WTRU
a. For example, as part of the calculation of the paging frame, the WTRU may calculate the paging frame by including the relay WTRU ID or another ID provided by the relay WTRU (e.g., in a PC5-RRC message). For example, the WTRU may be configured to calculate the periodicity and offset of the paging frame on SL using a formula based on the L2 ID of the relay WTRU. The remote WTRU may wake up before the calculated paging frame or the calculated paging frame.
-timing with respect to discovery messages and/or resource pools, or other periodic messages that may be transmitted by the relay WTRU
a. For example, the remote WTRU may determine the timing of its scheduled wakeup slot or the beginning of its side link paging window based on some (pre) configured offset from the discovery message or other periodic message transmitted by the relay WTRU.
b. For example, the remote WTRU may determine the beginning of its side chain paging window with respect to the resources in the pool of resources used for discovery reception. For example, the remote WTRU may determine that its start of the sidelink paging window is at some time offset from its discovery resource pool closest to the WTRU Uu paging occasion.
-timing relative to one or more previous wake-up/monitor times of a remote WTRU
a. For example, the relay WTRU may transmit the exact timing (e.g., slot, offset, etc.) of the timing of the next period in a discovery message or similar periodic message
Indicated by the relay WTRU (e.g., in a scheduling SCI, MAC CE or PC5-RRC message)
a. For example, the WTRU may wake up periodically at a fixed time. May be a WTRU
Such times are (pre) configured. The WTRU may receive a discovery message or similar periodic message at the fixed time. In addition, the WTRU may receive (e.g., in a scheduling SCI, MAC CE, or PC5-RRC message) an indication of the wake-up time to read the paging message. The WTRU may revert to DRX before the time indicated in the message. For example, the WTRU may receive a fixed time message (e.g., a discovery message) in the SCI schedule indicating that additional allocations have been reserved (e.g., a periodic indication). The WTRU may receive a paging message at the indicated allocated time and perform DRX between the initial message and the paging message. For example, the WTRU may receive an additional message (e.g., a MAC CE) in the discovery message (or similar periodic message) indicating the number of time slots following the discovery message after which the WTRU should perform monitoring for paging/system information.
b. For example, the relay WTRU may indicate a new timing for paging occasions for the remote WTRU (e.g., in PC5-RRC signaling). If such timing is not provided, the remote WTRU may use its originally calculated paging occasion timing (i.e., paging occasion timing based on WTRU ID) and determine SL paging timing based on a (pre) configured offset from this timing or based on an offset determined according to other examples given herein
-timing of paging occasions calculated relative to it on Uu
a. For example, a WTRU may determine its SL paging slot by employing the UL paging slot (calculated as done in Uu) and adding an offset that depends on the group member ID
-based on the measured CBR
a. For example, the WTRU may determine its SL paging slot and/or first monitoring slot by considering the measured CBR at some time prior to and/or during the wakeup. In particular, the WTRU may determine the wakeup slot as an offset according to a predetermined time slot defined in other solutions (e.g., a predefined time of the discovery message), where such an offset may further vary with CBR and possibly other parameters (e.g., offset = cbr_factor x group ID)
-the relay WTRU requesting to change paging timing of the remote WTRU
According to an embodiment, a relay WTRU may request to the network to change the timing of paging messages. In particular, the relay WTRU may indicate a tendency to change the timing of Uu paging frames (for the remote WTRU) to a different frame/slot or to shift the existing timing by an offset. The relay WTRU may send such a request (e.g., a sidelink WTRU information message or a WTRU assistance information message) to the network in an RRC message. In addition, if the relay WTRU is in rrc_idle/rrc_connected, the relay WTRU may also request such changes for its own paging frame/slot. The content of such messages may include:
-WTRU identity (e.g. L2 ID) of the WTRU that should send its paging message;
absolute time or time offset of the desired paging timing (e.g., from the calculated paging occasion), or a set/range of possible occasions.
The relay WTRU may trigger such a request under any of the following events/criteria or a combination thereof:
-after establishing a PC5-RRC connection with a remote WTRU
a. For example, the relay WTRU may determine a DRX on period of the remote WTRU to establish a PC5-RRC connection based on the Uu paging occasion of the first WTRU. After that, the relay WTRU may send a request to change the paging occasion of any subsequent remote WTRU connected via PC5-RRC if the time difference between the Uu paging occasion timings of the first WTRU and the subsequent WTRU is greater than a threshold value
-time difference between Uu paging occasions of any two remote WTRUs connected to the relay WTRU based on PC5-RRC
a. For example, if the time difference between paging occasions of any two remote WTRUs is greater than a threshold, the relay WTRU may trigger such a request
-the relay WTRU determining new/modified paging occasions of the remote WTRU
According to an embodiment, the relay WTRU may determine Uu paging occasions for the remote WTRU. Such a mechanism for paging determination may be different from the traditional formulation of determining paging of a WTRU based on a WTRU ID. Such a mechanism may be used to align paging occasions of multiple remote WTRUs together so that a relay WTRU may still effectively monitor paging of a remote WTRU while the relay WTRU is in RRC IDLE/RRC INACTIVE. The relay WTRU may determine the paging occasion of its remote WTRU:
based on its own paging occasion
a. For example, the relay WTRU may assume that the paging occasion of the remote WTRU corresponds to its own paging occasion
b. For example, the relay WTRU may determine the paging occasion of the remote WTRU based on an offset from its own paging occasion (where such an offset may be determined by other factors herein)
-number of remote WTRUs connected based on PC5-RRC
-based on a member ID or similar ID associated with a particular remote WTRU
a. Such IDs may be assigned to relay/remote WTRUs from an upper layer
b. Such IDs may be determined based on the order in which the remote WTRUs connect to the relay via the PC5-RRC connection
-the relay WTRU determining paging occasions of the remote WTRU based on its own RRC/DRX state
According to embodiments, a relay WTRU may determine/identify paging occasions for remote WTRUs to which it attaches based on its own RRC state. Specifically, the relay WTRU may use a first mechanism to determine remote WTRU paging occasions when in one state (e.g., rrc_idle, rrc_inactive) and a second mechanism to determine remote WTRU paging occasions when in another state (e.g., rrc_connected). For example, when a relay WTRU is in rrc_connected, the relay WTRU may determine a paging occasion for each remote WTRU based on the WTRU ID of the remote WTRU. When the relay WTRU is in RRC IDLE, the relay may determine the paging occasion of the remote WTRU based on any of the mechanisms further described herein.
Remote WTRU determines whether Uu RRC connection/recovery is performed by relay WTRU or directly via Uu
According to embodiments, a remote WTRU in rrc_idle/rrc_inactive and possibly PC5-RRC connected to a relay WTRU may determine whether to perform Uu RRC connection/recovery directly via Uu or through the relay WTRU based on one of the following criteria or a combination thereof (e.g., based on a number of conditional and/or).
Information in paging messages received from the network
a. For example, the WTRU may receive an explicit indication in the paging message of whether to connect to the network via a relay link or a direct link
b. For example, the WTRU may receive the level/class of access in a paging message. Depending on the class/category in the paging message, the WTRU may be further (pre) configured to initiate the connection/recovery via Uu or through relay. For example, the WTRU may be (pre) configured with certain rules (based on other factors herein) where access for each class/category in the paging message should be performed directly on Uu or via relay
Uu bearer configured or data arrived
a. For example, the WTRU may be configured to have a preferred link (direct Uu or PC 5) on which to establish a connection for a given bearer that data has arrived (for UL trigger), or to indicate a bearer that data has arrived in a paging message (for DL trigger)
SL characteristics such as
a. Measured CBR
i. For example, the WTRU may decide to connect via Uu or via relay based on the CBR measured when paging or UL data arrival is received. Specifically, if the measured CBR is above a threshold, the WTRU may connect via Uu
b. Relay WTRU measured RSRP, CQI or others
i. For example, the WTRU may connect via Uu or PC5 based on measured RSRP (e.g., RSRP relaying discovery messages) or other SL measurements (e.g., CQI). For example, if the measured relay RSRP is below a threshold, the WTRU may connect via Uu
Uu measurement of cells
Whether the relay WTRU is connected to the same cell/related cell as the cell in which the remote WTRU resides/is in coverage
a. For example, the WTRU may connect via Uu of the cell with the highest measured RSRP. If the cell is the same as the cell to which the relay WTRU is connected, the WTRU may be allowed to connect directly via Uu. Otherwise, the WTRU may connect via the relay path.
b. For example, in the above example, it may be allowed to connect directly via Uu to a cell associated with the cell to which the relay WTRU is connected. Such "correlations" may be determined based on the transmission of an identification (e.g., area ID) in the system information. For example, if the area ID obtained from the relay WTRU matches the area ID broadcast directly on Uu, the remote WTRU may connect directly via Uu.
A WTRU that decides to connect directly via Uu may issue a release of the PC5-RRC connection to a peer (relay WTRU).
RAN area update procedure for remote/relay WTRUs
-relay WTRU RAN area update implicitly causes remote WTRU RAN area update
According to an embodiment, the RAN area update performed by the relay WTRU may implicitly result in a RAN area update for each of the remote WTRUs. Specifically, the relay WTRU may transmit an rrcreseum message when triggering a RAN area update, including an identity of the remote WTRU (e.g., remote WTRU ID, L2 ID, group member ID, or I-RNTI) to which the PC5 is connected. Alternatively, the remote WTRU may keep the network aware of the remote WTRU connected to PC5 while in INACTIVE. In particular, the relay WTRU may perform network access (e.g., RRC recovery procedure or similar RAN area update procedure) when a new PC5-RRC connection of the remote WTRU occurs. In particular, the relay WTRU may perform network access when one or more PC5-RRC connected remote WTRUs are released. In particular, the relay WTRU may perform network access (e.g., a recovery procedure) if the remote WTRU changes its L2 ID. In such a second alternative, the relay WTRU may initiate the RAN area update procedure without providing the WTRU ID of the remote WTRU in the resume message. In yet another alternative, the relay WTRU may periodically notify the network of the presence of a new remote WTRU and/or release of other remote WTRUs. In yet another alternative, the relay WTRU may notify the network when the number of WTRUs that PC5-RRC is connected to the relay WTRU changes to a certain number. In many of these alternatives, the relay WTRU may include only the information of WTRUs that changed since the last network access, which provides a list of attached PC5-RRC connected WTRUs.
After the relay transmits a resume request message (e.g., for a RAN area update), the relay WTRU may receive updated RAN area information for each of its PC5-RRC connected remote WTRUs. In particular, the relay WTRU may receive one or more updated RAN area configurations (e.g., I-RNTI, RAN area, RNAU timer) for one or more remote WTRUs. In one example, the relay WTRU may receive (e.g., in an RRC release message) a Uu container containing an RRC message with a set of WTRU IDs and corresponding RAN area configurations for each WTRU. Alternatively, the container may contain multiple RRC messages, where each message is encoded using a security key specific to the WTRU. The relay WTRU may forward such a container to all remote WTRUs (e.g., using a group message). Each remote WTRU may decode the RRC message associated with its WTRU ID and apply the new RAN area configuration associated with its WTRU ID. In another example, a relay WTRU may receive multiple containers, each container associated with a particular L2 ID. The relay WTRU may send each container (e.g., in a dedicated PC5-RRC message) to each WTRU separately.
Remote WTRU triggering RAN area update after relay reselection
The remote WTRU may trigger a RAN area update during/after relay reselection. In particular, the remote UE may obtain a new cell ID associated with the target relay. The remote UE may trigger a RAN area update procedure if the cell is outside of a RAN area configured at the remote WTRU.
Remote WTRU tends to do not require relay reselection for RAN area update
According to an embodiment, the WTRU may perform such reselection in view of whether relay reselection would result in a RAN area update. In particular, the remote WTRU may prefer that reselection to the relay WTRU be such that the corresponding reselection does not trigger the RAN area update procedure. For example:
the remote WTRU may be configured to have an offset in RSRP measurements of the old/new relay WTRU and/or an offset in Uu measurements of the old/new relay WTRU and/or an offset in a measurement threshold that triggers reselection (e.g., a first offset/threshold for potential cell reselection that does not require RAN area update, a second offset/threshold for potential cell reselection that does require RAN area update;
if the current/potential relay selection procedure at the WTRU would trigger a RAN area update, the remote WTRU may trigger a new relay discovery/selection procedure (e.g., transmission of discovery messages, monitoring for discovery in a different band/resource group).
-the remote WTRU triggers RAN area update after relay WTRU mobility (HO/reselection)
According to an embodiment, a remote WTRU in rrc_inactive and PC5-RRC connected to a relay WTRU may trigger a RAN area update due to mobility of the relay WTRU. Such mobility may result from the relay WTRU performing any of the following operations:
-the relay WTRU performing a Handover (HO) or a Conditional Handover (CHO);
-the relay WTRU performing cell reselection;
-the relay WTRU performing a RAN area update.
The relay WTRU may notify its remote WTRU of any of the mobility events described above:
by sending explicit/implicit messages on PC5-RRC
a. For example, the remote WTRU may transmit a PC5-RRC message indicating that reselection has been completed and including the new cell in which the relay WTRU camps;
b. for example, the remote WTRU may trigger the transmission of new system information, whereby the new system information corresponds to system information obtained from a new cell that the WTRU has reselected;
c. for example, the remote WTRU may send the SL paging message in the SL paging window of the remote WTRU. Such SL paging messages may have an indication to the remote WTRU to perform a RAN area update. Such a SL paging message may have an indication that triggers the remote WTRU to acquire new system information on the SL;
d. For example, the relay WTRU may change the system information version number upon cell reselection, handover, RAN area update, etc. The relay WTRU may transmit the new system information version number to the remote WTRU in a next discovery message, a periodic control message, or a minimum system information transmission.
The remote WTRU may initiate a RAN area update procedure via the relay WTRU upon receiving the indication from the relay WTRU.
Remote WTRU triggering RAN area update after mobility with respect to relay
According to embodiments, the remote WTRU may maintain its rrc_inactive state when transitioning between a direct connection via Uu and a relay connection via relay, or when transitioning from one relay connection (via a first relay) to another relay connection (via a second relay). In this case, the WTRU may initiate a RAN area update procedure. According to embodiments, a remote WTRU in rrc_inactive may trigger a RAN area update when any of the following events related to its own mobility occur:
switching from a relay connection to a direct Uu connection
a. For example, when transitioning from the rrc_inactive state associated with the relay connection to the rrc_inactive state associated with the direct Uu, it may be the result of a reselection decision (i.e., from relay to cell)
b. For example, in the case where PC5-RRC is connected to the relay WTRU and is within coverage of the cell in Uu, the PC5-RRC connection is released (possibly as a result of upper layer release, PC5 RRC reconfiguration failure, SL RLF, etc.)
i. Specifically, if the remote WTRU declares a SL-RLF with relay while in rrc_inactive, and the remote WTRU selects a cell during/after the SL-RLF such that the cell is appropriate, the remote WTRU may trigger the RAN area update procedure.
c. Such RAN area updates may be performed by the remote WTRU without regard to the cell. Alternatively, such RAN area update may be performed only in the following cases
The WTRU is configured with RAN area or INACTIVE configuration
The RAN area of the target (Uu) cell is different from the RAN area where the previously connected relay WTRU is located
Switching from a direct Uu connection to a relay connection, or from a first relay connection to a second relay connection
a. For example, when establishing a PC5-RRC connection with a relay WTRU
b. For example, upon successful configuration to have a PC5-RLC channel configuration, or successful establishment of such PC5 RLC channel
c. Such RAN area update may be performed by the remote WTRU at all times. Alternatively, such RAN area update may be performed only in the following cases
The WTRU is configured with RAN area or INACTIVE configuration
The RAN area of the relay WTRU is different from the RAN area of the cell in which the WTRU resides, or from the RAN area of a previously connected relay WTRU
-relay WTRU performs on behalf of remote WTRURAN area update or similar RRC message transmission
According to an embodiment, the relay WTRU may perform a RAN area update on behalf of the remote WTRU. In particular, the relay WTRU may notify the network of a change in RAN area associated with the attached remote WTRU. The relay WTRU may trigger such RAN area update:
-when establishing a PC5-RRC connection with a remote WTRU
a. Possibly when the RAN area associated with the remote WTRU prior to the PC5-RRC connection is different from the RAN area of the relay WTRU
Upon receiving a sidelink reconfiguration message from the peer WTRU (possibly a first sidelink reconfiguration after PC5-RRC connection establishment)
For example, the remote WTRU may provide the relay WTRU with its previously associated RAN area or cell ID (where such association is via direct camping on Uu, or represents the cell/RAN area to which the relay WTRU to which the remote WTRU was previously attached is attached). If the relay WTRU is in rrc_inactive, it may trigger a RAN area update procedure when a PC5-RRC connection is established, provided that the relay WTRU's RAN area is different from the previous RAN area associated with the remote WTRU. For example, if the relay WTRU is in rrc_connected, the PC5-RRC connection may trigger transmission of an RRC message.
-establishing a PC5-RRC connection or relay WTRU RAN area update after receiving SL reconfiguration
According to another embodiment, the relay WTRU may perform a similar procedure (RAN area update, or similar RRC message transmission, while remaining in rrc_inactive) to inform the network of the new PC5-RRC connection with the remote WTRU in rrc_idle. Specifically, the relay WTRU may trigger a RAN area update or similar NW access when a PC5-RRC connection is established with the remote WTRU for relay, or when a first reconfiguration message is received after the PC5-RRC connection is established. The relay WTRU may further indicate as part of the access
RRC state (e.g., IDLE or INACTIVE) of remote WTRU
NW identification of remote WTRU
a. For example, S-TMSI (e.g., for a remote WTRU at IDLE) or I-RNTI (e.g., for a remote WTRU at INACTIVE), or L2 ID or a new ID capable of identifying a remote WTRU to the network
-a previous cell/RAN area of a remote WTRU provided by the remote WTRU
Relay WTRU RAN area update using 2-step RACH
The relay WTRU may further perform a 2-step RACH procedure upon establishment of a PC5-RRC connection, upon receipt of a SL reconfiguration message from the remote WTRU, or sometime after establishment of a PC5-RRC connection with the remote WTRU. The relay WTRU may include RRC messages corresponding to the above in a two-step RACH procedure. The relay WTRU may further perform such a two-step RACH procedure, but not other procedures (4-step RACH, or full connection establishment) based on the following decisions:
-RRC state of the remote WTRU, or any information provided by the remote WTRU that may indicate its RRC state to the network:
a. for example, if the remote WTRU was previously in rrc_inactive or rrc_idle, the relay WTRU may trigger a 2-step RACH procedure. Otherwise, if the remote WTRU was previously in rrc_connected, the relay WTRU may trigger a connection setup or a 4-step RACH procedure. The remote WTRU may implicitly/explicitly provide an indication of its RRC state, e.g., in a first PC5 RRC reconfiguration message after connection establishment
-previous RAN area of remote WTRU
a. For example, if the RAN area of the remote WTRU is not changed due to a PC5-RRC connection, the relay WTRU may trigger a 2-step RACH procedure. The remote WTRU may provide the RAN area or cell ID in a first reconfiguration message after the PC5-RRC connection
Size of RRC message to be transmitted
a. For example, if the RRC message to be transmitted is less than the preconfigured number of bits, the relay WTRU may trigger a 2-step RACH procedure. The relay WTRU may determine the size of the message based on the data/ID to be sent to the network, etc
Whether the relay WTRU receives SL configuration for data transmission
a. For example, the relay WTRU may trigger a 2-step RACH procedure upon receiving an RRC reconfiguration message received from the peer WTRU. If such a message does not configure RLC bearers for data transmission or does not contain a configuration that requires a Uu connection to be established, the relay WTRU may trigger a 2-step RACH procedure. Otherwise, the relay WTRU may trigger a normal RACH procedure and may transition to the rrc_connected state.
Remote WTRU triggering release procedure after relay RAN area update
According to embodiments, the remote WTRU may trigger a release procedure (e.g., a PC5-RRC release and/or Uu RRC release procedure) after a RAN area update of the relay WTRU. Alternatively, the remote WTRU may initiate the re-establishment, restoration, or RAN area update directly via Uu. For example, a remote WTRU within Uu coverage may release a PC5-RRC connection with a relay WTRU when the relay WTRU moves and trigger a RAN area update (or similar NW access) directly via Uu.
-the relay WTRU informing the remote WTRU when the RAN area update should be triggered
According to an embodiment, a relay WTRU may determine whether one or more remote WTRUs should trigger a RAN area update after a mobility event (e.g., handover (HO), cell reselection) occurs at the relay WTRU. Specifically, the relay WTRU may obtain Uu RAN area configuration from the remote WTRU in PC5-RRC signaling. The relay WTRU may send an indication to the remote WTRU if the relay WTRU reselects a cell outside of the remote WTRU RAN area or if the relay WTRU is handed over to a cell outside of the remote WTRU RAN area. The relay WTRU may further send such an indication only to remote WTRUs that are in rrc_inactive and that need a RAN area update. Alternatively, the relay WTRU may send messages/indications to all remote WTRUs. Any of the mechanisms described herein may be used to send an indication on the PC 5. The remote WTRU may trigger a RAN area update upon receiving the indication. Alternatively, the remote WTRU may first determine if it needs a RAN area update when it receives the message. For example, a remote WTRU in rrc_inactive may read information (e.g., a cell ID) in the system information and/or indication and trigger a RAN area update if the cell ID is outside its RAN area.
PC5 link management (SL-RLF) for IDLE/INACTIVE
Remote/relay WTRU performs transmission within DRX of peer WTRU for link management
The relay and/or remote WTRU may perform periodic or half-periodic transmissions for purposes of link monitoring. In particular, the relay/remote WTRU may configure one or more transmissions to occur within IDLE/INACTIVE DRX periods of the peer WTRU. Such emissions may be any of the following:
-RSRP measurement;
-discovery message transmission;
-virtual data transmission;
-CQI reporting;
-side link paging message transmission;
SL system information or system information update.
The transmitting WTRU may ensure that such transmissions fall within the DRX active period of the peer WTRU. For example, a transmitting WTRU may perform resource selection during DRX active periods of a peer WTRU. For example, a transmitting WTRU may be provided with authorization for configuration of such transmissions.
The transmitting WTRU may perform HARQ based RLF mechanisms using HARQ feedback received from such transmissions. Specifically, if the number of received DTX exceeds a (pre) configured threshold, the transmitting WTRU may trigger the SL-RLF procedure.
The WTRU may enable HARQ feedback for certain transmissions when those transmissions occur during DRX on periods. The WTRU may further enable HARQ feedback for such transmissions within DRX without performing any data, system information, or other SL transmissions within the DRX on period.
Transmitting WTRU performs retransmission whenever DTX is received
The transmitting WTRU may determine the number of transmissions/retransmissions of the "pulsed" signal during the DRX on period based further on receiving HARQ feedback from the peer WTRU. In particular, the transmitting WTRU may be (pre) configured to have a minimum number of transmissions (e.g., 1 transmission) per DRX on cycle. The transmitting WTRU may perform additional transmissions and/or retransmissions of the pulsed signal based on HARQ feedback received from one of the (pre) configured transmissions (e.g., the last transmission). For example, the transmitting WTRU may retransmit the RSRP measurement report during the DRX on cycle whenever the transmitting WTRU receives HARQ DTX, or until the SL-RLF fails (e.g., the number of consecutive HARQ DTX reaches a maximum threshold). Such retransmissions may fall outside of the pulse signal. Alternatively, retransmissions may be scheduled such that they fall within the DRX active time of the peer WTRU.
Performing SL-RLF by a receiving WTRU based on transmission quality in DRX periods
The receiving WTRU may perform SL-RLF based on the quality of such periodic measurements when configured with SL-DRX and when the periodic/half-periodic transmissions (e.g., RSRP) described above are received during the on-duration. Specifically, the WTRU may trigger SL-RLF:
If RSRP is below the threshold, it is possible to transmit for a plurality of (possibly consecutive) transmissions
The WTRU may enable such quality-based SL-RLF measurements when the WTRU transitions to Uu IDLE/INACTIVE with PC5 connected to the relay. When the WTRU is in rrc_connected, it may perform HARQ-based RLF and disable measurement-based SL-RLF.
Triggering SLRLF when PC5-RRC is connected to the relay/remote WTRU
Upon triggering the SL RLF with the remote WTRU, the relay WTRU may perform any actions after removing the remote WTRU from the list of remote WTRUs connected at the relay. Such actions that may be performed in any order may be:
relay may perform network access (connection setup/restoration/RAN area update) to inform NW;
the relay WTRU may record/keep track of the remote WTRU (e.g., L2 ID) for which RLF was triggered and may indicate this to the network on the next access (restoration, RAN area update, etc.);
the relay WTRU may stop monitoring for pages (on Uu) associated with the remote WTRU;
the relay WTRU may cease reading the system information and/or cease updating the remote WTRU with the system information update;
-the relay WTRU may remove the remote WTRU from its connected remote WTRU list;
-if the relay WTRU is in rrc_connected and there are no more remote WTRUs in the CONNECTED remote WTRU list, or if all CONNECTED remote WTRUs are in rrc_idle/rrc_inactive, the relay WTRU may:
a. transition to rrc_idle/rrc_inactive-if the WTRU has a remote WTRU in at least one connection with rrc_inactive, the WTRU may transition to rrc_inactive, otherwise it may transition to rrc_idle;
b. initiating/enabling an inactivity timer associated with rrc_idle/rrc_inactive
-if the relay WTRU is in rrc_inactive and no longer has a connected remote WTRU, or all connected remote WTRUs are in rrc_inactive, the relay WTRU may:
a. transition to rrc_idle
b. Starting/enabling an inactivity timer associated with rrc_inactive
The remote WTRU may perform one of a set of different procedures after the SL-RLF, where the performed procedure will depend on its Uu RRC state at the time of the SL-RLF and/or the reselection results (cell or relay, and the same cell or different cells) after the SL-RLF. The remote WTRU may perform the following actions, possibly in any order, after triggering the PC5-RLF of the relay WTRU:
the remote WTRU may trigger relay reselection. For example, if the remote WTRU is able to find another relay WTRU that may be connected to the same cell, and/or if the remote WTRU is in OOC, the remote WTRU may perform any of the following actions:
a. Once the remote WTRU connects to another relay via PC5-RRC, the remote WTRU may notify the new peer WTRU of the previous RLF by providing the L2 ID of the previous relay WTRU
b. Alternatively, once the remote WTRU connects to another relay via PC5-RRC, the remote WTRU may trigger an RRC procedure with the network, possibly indicating the cause of the procedure, or possibly informing the network of previous RLFs on PC5-RRC and providing relevant information (e.g., previous L2 ID of relay):
i. if the remote WTRU was previously in RRC_INACTIVE/RRC_CONNECTED, the remote WTRU may trigger RNAU/recovery procedures via a new relay
if the remote WTRU was previously in RRC_IDLE, the remote WTRU may trigger connection setup via a new relay
The remote WTRU may perform a cell selection operation. Such an operation may be performed, for example, if the remote WTRU determines that it is in coverage and/or the remote WTRU cannot find an alternative relay to select and/or determines that the Uu cell is better quality than the relay WTRU based on some criteria
The remote WTRU may perform an access directly to Uu. Specifically:
a. if the remote WTRU is Uu RRC-CONNECTED at SL RLF:
i. if the remote WTRU is in coverage, possibly in coverage of a cell other than the cell to which it is connected via relay, the remote WTRU may transition to RRC_INACTIVE and may initiate a recovery procedure via Uu
1. The remote WTRU may determine the I-RNTI for the resume request message based on one or a combination of the following actions:
a. when performing such recovery after transitioning to INACTIVE due to SL-RLF, the remote WTRU may include a special (dedicated) identity (e.g., a preconfigured set of bit combinations) in a portion of the I-RNTI
b. While in RRC_CONNECTED, the remote WTRU may include an I-RNTI provided to it by the network
c. The remote WTRU may include its C-RNTI or another connection mode identity. Such a C-RNTI may be used, for example, if the remote WTRU may be scheduled via Uu while or immediately after the RRC connection is moved to Uu. Such a connection mode ID may be used, for example, to identify a remote WTRU at the network when the remote WTRU communicates via a relay WTRU).
2. If the remote WTRU reselects to the same cell as it was connected via relay before RLF, the remote WTRU may trigger a 2-step/4-step RACH procedure and provide any of the following information within the 2-step/4-step RACH:
WTRU ID (e.g., C-RNTI)
b. Status reports associated with any of its protocol layers and/or bearers, such as PDCP status reports and RLC status reports, etc
3. If a remote WTRU is in coverage, possibly in coverage of the same cell as it is CONNECTED to via a relay, the remote WTRU may remain in RRC_CONNECTED and may initiate RRC message transmissions to the network (e.g., sidelinkWTRU information)
4. The remote WTRU may initiate a re-establishment procedure
5. The remote WTRU may trigger CHO, possibly assuming that it performs relay selection to its cell with CHO configuration, possibly assuming that it reselects to a cell different from the cell to which the relay is associated/connected
6. If the remote WTRU is in RRC_CONNECTED at SL RLF, the remote WTRU may trigger a re-establishment procedure only when it reselects to a cell different from the cell to which it relays are CONNECTED
if the remote WTRU is in Uu rrc_inactive at SL RLF:
1. possibly when the remote WTRU selects the same cell as its associated cell at the time of SL RLF, the remote WTRU may initiate the recovery procedure directly via Uu
2. The remote WTRU may transition to rrc_idle and may initiate a connection establishment procedure via Uu when the WTRU selects a cell different from the cell it is associated with via relay when SL RLF occurs
The remote WTRU may transmit a PC5-RRC message to the new relay WTRU, wherein such message may include:
Measurement of uu and/or PC5
2. Identity of previously connected/camped cell
3. Identity of a previously connected relay WTRU or any currently connected relay
The remote WTRU may initiate monitoring of Uu PDCCH.
According to an embodiment, the remote WTRU may trigger cell/relay reselection after SL-RLF. Once cell/relay reselection has been completed (and a new cell/relay has been found)
-if the remote WTRU is in rrc_connected
a. If the remote WTRU selects a cell other than the cell to which the previous relay was connected, or selects a relay connected to a cell other than the cell to which the previous relay was connected, the remote WTRU may initiate a re-establishment procedure (transmit a re-establishment request)
i. The re-establishment request on Uu to the cell may be a conventional re-establishment request message
The re-establishment request message to the cell via the relay WTRU may be after the transmission of the SLRRC message and/or may be distinguished from a conventional re-establishment and/or may have information about
1. The relay WTRU may send a message to the relay WTRU,
SL measurements (e.g., CBR, CR, RSRP, CQI, etc.)
b. If the remote WTRU selects to the same cell as the cell to which it was previously connected, or selects to a relay connected to the same cell as the cell to which it was previously connected, the remote WTRU may:
i. For the case of direct Uu, a legacy re-establishment message is triggered
For the case of relay link, no Uu procedure is triggered and only PC5-RRC message is transmitted
-if the remote WTRU is in rrc_inactive
a. For the case of the same cell:
i. in the case of connection via relay, transmitting a PC5-RRC message to a new relay WTRU
Transmitting RAN area updates in case of a connection via Uu, wherein such RAN area updates also identify:
1. previous relay WTRU to which remote WTRU is connected
b. For the case of different cells
i. In the case of connection via relay, transmitting a PC5-RRC message to a new relay WTRU
Transmitting RAN area updates in case of a connection via Uu, wherein such RAN area updates also identify
1. Previous relay WTRU to which remote WTRU is connected
-if the remote WTRU is in rrc_idle
a. For the case of different or the same cells
i. Transmitting PC5-RRC messages to a new relay WTRU
-NW notifying relay WTRU after triggering SLRLF when PC5-RRC connects to relay/remote WTRU
The network may notify the relay WTRU of the attached SL remote WTRU that the SL-RLF has been triggered. The relay WTRU may receive a remote WTRU release message from the network. Such messages may be received as follows:
-if the relay WTRU is in rrc_idle/rrc_inactive, via paging message
-via a dedicated RRC message if the relay WTRU is in rrc_connected.
The relay WTRU may receive the remote WTRU's ID (e.g., L2 ID) in such a message.
Upon receiving such a message, the relay WTRU may perform actions when the remote WTRU is removed from the list of remote WTRUs connected at the relay.
-the remote WTRU triggers SL-RLF after indication from different relay WTRUs or gnbs
SL RLF may be detected by the relay WTRU, but the relay WTRU may not be able to notify the remote WTRU of this. Especially for remote WTRUs in rrc_connected, this may affect the service continuity of DL-only traffic when SL-RLF occurs.
According to an embodiment, a remote WTRU may monitor transmissions from one or more alternative relay WTRUs. An alternative relay may be one where the remote WTRU has another PC5-RRC connection. Alternatively, the message may be transmitted by a WTRU in which the remote WTRU does not have a PC5-RRC connection (i.e., transmitted as a broadcast message). The remote WTRU may determine that the SL-RLF has occurred based on receiving a message from the alternative relay indicating that the SL-RLF has occurred. Such messages may be received directly from the cell via Uu without loss of generality. Upon receiving this message, the remote WTRU may trigger any of the procedures described herein in connection with the detection of SL RLF.
The message may be a SL RRC message transmitted by the relay WTRU or a Uu RRC message transmitted by the cell via the relay WTRU.
The message may identify a unicast link (e.g., source/destination L2 ID) on which the relay WTRU detected the SL RLF.
According to a first embodiment, a remote WTRU may receive such indication from another PC5-RRC connected relay WTRU via PC 5-RRC. The relay WTRU may receive a trigger (e.g., reconfiguration, paging message, DCI, MAC CE, etc.) from the network to transmit such a message using PC 5-RRC.
According to a second embodiment, the remote WTRU may receive such indication from another relay WTRU via broadcast transmission (possibly using PC5-RRC on multicast/broadcast). For example, the remote WTRU may receive such an indication in a discovery message. For example, the remote WTRU may receive such indication in a PC5-RRC transmission by the specific L2 destination ID monitored by the remote WTRU for receiving such a message. Similar to the first embodiment, the relay WTRU may trigger transmission of such messages after an indication from the network
According to a third embodiment, the remote WTRU may receive such indication via a Uu message, possibly wherein such Uu message is relayed by one or more alternative relay WTRUs. In particular, the remote WTRU may receive such a message:
-in system information transmission
a. In particular, a remote WTRU may monitor system information relayed by multiple remote WTRUs, possibly if such system information is embedded/encapsulated within discovery messages on a side link
-in paging messages
a. In particular, the remote WTRU may receive Uu paging messages that may be relayed via the side link, where such Uu paging messages may further indicate that the relay WTRU detects SL-RLF
-in Uu RRC message
a. In particular, the remote WTRU may maintain multiple connections (via the current relay WTRU and via the alternative relay WTRU), possibly in a similar dual connection manner, and may receive indications in Uu RRC messages received on different links
The remote WTRU may be configured to monitor for such indications based on Uu RRC state and transmit/receive activity. For example, the remote WTRU may monitor for the indication only while in rrc_connected. For example, while in rrc_idle/rrc_inactive, the remote WTRU may monitor such indications less frequently, possibly according to some fixed or (pre) configured schedule. For example, the remote WTRU may monitor for such indications (possibly more frequently) when there is no transmission/reception to the relay WTRU.
Method for system information transmission to a remote WTRU
Remote WTRU transmitting SIRrequest on side link
According to an embodiment, the remote WTRU may send an SI request to the relay WTRU on a side link. The remote WTRU may send such a request (when PC5-RRC connected) to the relay WTRU to which it is attached. Alternatively, the WTRU may broadcast an SI request on the side link to reach a relay WTRU to which it has no PC5-RRC connection. Such SI requests may be broadcast when the remote WTRU has no PC5 connection. Such SI requests may be broadcast when a remote WTRU has a PC5 connection but requests SI associated with a cell to which another relay WTRU is connected.
The remote WTRU may set the L2 destination ID of the SI request as follows:
-L2 destination ID associated with (pre) configured SI request
L2 destination ID associated with SI request provided by upper layer
-the WTRU's own L2 source ID
-L2 source ID of relay WTRU from which remote WTRU is requesting SI (if remote WTRU requests SI from single remote WTRU)
Unicast L2 ID of relay WTRU with unicast link with remote WTRU
The remote WTRU may include any of the following in the SI request
-the particular SIB/SI that it is requesting
Sequence number associated with a part/segment of SIB that it is requesting
L2 ID of the relay WTRU that should respond (i.e., L2 ID of the relay WTRU from which the remote WTRU is requesting SI).
The expected time (time slot, group of time slots) or expected resource pool of its expected/requested received SI
-the SI tag of the remote WTRU has a last valid SI or similar indication for the version of SI that the remote WTRU is requesting
-an indication of whether the remote WTRU is in-coverage or out-of-coverage
a. If so, the cell ID of the cell (or equivalent ID broadcast by the cell, such as area ID) of the remote WTRU in its coverage area
i. For example, the remote WTRU may include this information only if the remote WTRU is within coverage of a different cell than the cell to which the relay WTRU is connected.
Uu measurement and/or SL measurement
i. For example, when Uu is connected to another cell via a relay WTRU, the remote WTR may include Uu measurements associated with the cell it is in its coverage area (if the remote WTRU is in coverage)
The WTRU may transmit the SI request using any of the following:
-PC5-RRC message
-MAC CE
SCI transmission indicating SI request
The remote WTRU may request SI in any of the following cases:
during/as part of the relay selection procedure:
a. For example, before selecting a relay, the remote WTRU may use the SI request to obtain the SI of the cell associated with such relay. The remote WTRU may determine whether it is able to select a relay (or whether it does not select a relay) based on the SI of the associated cell. For example, the remote WTRU may select the cell with the best measurement such that the associated cell allows the remote WTRU to attach to the cell via relay (as determined from the content of the SI)
b. For example, the remote WTRU may obtain SI for all relays (e.g., "suitable relays") with RSRP above a threshold. The remote WTRU may then select a relay based on the WTRUs allowed to connect to the cell. Alternatively, the remote WTRU may use information from the SI to select a relay among the appropriate relays. For example, the remote WTRU may select to connect/associate to a relay of the same cell as the cell to which the remote WTRU was previously connected/associated (via relay or directly via Uu), or to select a cell that is part of the same RAN area or similar configuration area
Changes in SI tags broadcast by relay WTRUs (possibly PC5-RRC connected)
-after relay selection and/or after PC5-RRC connection establishment
a. For example, the remote WTRU may transmit a request after establishing a PC5-RRC connection with the relay WTRU
The relay WTRU may respond to the SI request only if the SI request contains the L2 ID of the relay in question. This may avoid transmitting SI multiple times when SI requests are broadcast.
The relay WTRU may multicast SI on the side link, potentially after the remote WTRU receives the SI request.
-the remote WTRU indicates SI request message to both relay and NW
The remote WTRU may transparently transmit the SI request message using the relayed SL RB (e.g., uu SRB 0). In some cases, SI requests transparent to the relay WTRU may cause problems (e.g., the relay WTRU may not know which SI is to be sent to the remote WTRU).
According to one example embodiment of the above embodiments, the remote WTRU may transmit an SI request to the relay WTRU using Uu RRC messages (e.g., using relay SRB 0). In addition, the remote WTRU may further inform the relay WTRU of such transmission of the relay SI request message. For example, the remote WTRU may indicate to the relay WTRU that the SI request is being transmitted on Uu SRB0 that is being relayed by:
indication in SCI
a. For example, an explicit indication (bit, new SCI format, new field in SCI) may be used to indicate that transmission on SRB0 is associated with an SI request
b. For example, the WTRU may reuse the existing field in the SCI to indicate the SI request (e.g., by setting the L2 source/destination address to a (pre) configured or predefined value)
Including MAC CE in side link transmission
a. For example, the WTRU may transmit SL mac ce on Uu SRB0 along with the SI request. Such SL MAC CEs may further contain information about the SI being requested
Use of a dedicated LCH (possibly associated with the SI being requested)
a. For example, the WTRU may transmit the SI request on a dedicated SL LCH associated with the relay LCH. For example, the remote WTRU may indicate the particular SI or SI group requested by selecting the SL LCH or SL RLC bearer on which the SI request message was transmitted. In particular, the WTRU may transmit an SI request on Uu SRB0 and select the SL RLC channel through which to map messages based on the particular SI being requested.
-using specific side link resources
a. For example, the remote WTRU may transmit an SI request message (e.g., possibly a Uu SRB0 message) by using dedicated or predefined side chain resources. Such resources may be:
i. specific time/frequency resources on side links
Specific side link handling reserved for SI requests
Sci reserves resources with a specific reservation period, number of sub-channels or other attribute associated with resource reservation, whereby such attribute is set to a certain (pre) configured or predefined value to distinguish SI requests
b. In any of the embodiments of the above examples, the predefined resource may further indicate the particular SI being requested
Remote WTRU determining a mechanism for transmitting SI requests and/or receiving requested SI
The remote WTRU may send SI requests and/or receive the requested SI using any of a variety of mechanisms. Such mechanisms may be associated with performing the request (and/or receiving SI) directly to the network via Uu or sending the request via a repeater. Such a mechanism may be associated with sending the request using an RRC message associated with one interface or the other (PC 5 RRC versus Uu RRC). Such mechanisms may be associated with requesting SI or requesting the actual SIB. Such mechanisms may be associated with whether the request is transparent or visible to the relay WTRU. Such a mechanism may be associated with whether the remote WTRU needs to include additional information, as may be described herein, into the request. In particular, the determination of such mechanisms may include any of the following:
transmitting the request using a PC5-RRC message or using a Uu SRB message (mapped to relay SL RLC channel)
-including the requested SI message or the specific SIB to be requested in the SI request
a. For example, the remote WTRU may use some factors to determine whether to transmit an SI request message or an SIB request message
b. For example, the remote WTRU may or may not include the requested SIB in the SI request to the relay WTRU based on some factors
-receiving a response in the PC5-RRC message, and/or via a relay DL Uu SRB/RLC channel, and/or directly via Uu
a. For example, the remote WTRU may use a PC5-RRC message to expect/receive a response to the SI request when the relay WTRU is rrc_idle/rrc_inactive, and may use a relay SL-RLC channel (associated with Uu DL transmissions) to expect/receive a response to the SI request when the relay WTRU is rrc_connected.
b. For example, whether the response is received in a PC5-RRC message or via a relay DL RLC channel associated with Uu may depend on the method/mechanism used by the remote WTRU to send the SI request, and thus on some factors described herein
The WTRU may determine one or more factors to determine a mechanism for transmitting an SI request and/or receiving SI after the request as follows:
-based on (status) information from relay
The remote WTRU may determine a mechanism for sending the SI request based on information provided by the relay WTRU (e.g., when connected to the relay WTRU). For example, such information may directly or indirectly inform the remote WTRU to relay the RRC state of the WTRU. Specifically, if the relay WTRU is in rrc_connected, the remote WTRU may send SI requests and/or receive requested SI using a first mechanism, and if the relay WTRU is in rrc_idle/rrc_inactive, the remote WTRU may send SI requests and/or receive requested SI using a second mechanism. The remote WTRU may determine the status of the relay WTRU and/or the required mechanism for sending SI requests based on any of the following:
Explicit information transmitted by relay WTRUs
a. For example, the relay WTRU may transmit a status indication or equivalent to the remote WTRU.
Which may be transmitted in the following cases
i. Upon transition from one state to another (e.g., a PC5-RRC message or PC5 mac ce indicating a state or state change to a remote WTRU).
b. Which may be periodically transmitted by the relay WTRU (e.g., a periodic PC5-RRC message with the current relay state).
c. Which may be transmitted with other relay WTRU transmissions
i. For example, the relay WTRU may include a MAC CE and its own transmissions, possibly when its Uu state has changed
For example, a relay WTRU may include status information and Uu SI broadcast/transmitted to its remote WTRU
For example, the relay WTRU may include its status information with Uu in its discovery transmissions
For example, the relay WTRU may include its status information with Uu in its SLRSRP measurement report
Implicitly based on certain properties of the relay WTRU's transmissions to the remote WTRU
a. For example, the relay WTRU may indicate its Uu status as part of the properties or content of its own transmissions (e.g., data transmissions, discovery transmissions, etc.). For example, the relay WTRU may select its resources for discovery, data, or other transmissions based on its Uu status. For example, the relay WTRU may transmit discovery messages on a periodic basis, depending on its Uu status. For example, when the relay WTRU is in rrc_idle/rrc_inactive, the relay WTRU may include an L2 ID for broadcasting SI in its discovery message.
Based on established/existing SL bearers at the relay and/or remote WTRU
a. For example, the relay WTRU may establish a SL bearer (e.g., SL SRB, relay RLC channel, etc.) and signal the establishment of such bearer/RLC channel to the remote WTRU and do so after establishing/restoring the Uu RRC connection. Conversely, when the relay WTRU is released as rrc_idle/rrc_inactive, the relay WTRU may release such bearers/RLC channels and indicate this to the remote WTRU. In such examples, the remote WTRU may determine the RRC state of its relay WTRU (and thus the mechanism for transmitting SI requests) based on the presence/absence of such SL bearing RLC channels. Upon receiving such an indication from the relay WTRU, the remote WTRU may further create/release a corresponding transmit SL bearer/RLC channel for transmission.
The remote WTRU may use the status information from the relay WTRU to determine a mechanism for sending SI requests or receiving responses.
For example, when the relay WTRU is in rrc_idle/rrc_inactive, the remote WTRU may transmit an SI request (on a non-relay PC5 SLRB) using a PC5-RRC message. Alternatively, the remote WTRU may transmit the SI request using the relay Uu SRB (e.g., SRB0 relayed via the SL RLC channel) when the relay WTRU is in rrc_connected.
Remote WT-basedRU coverage conditions
The remote WTRU may determine its mechanism for sending SI requests to/via the relay WTRU based on its own coverage conditions, which may cover any of the following:
whether the remote WTRU is in or out of Uu's coverage area
Whether the remote WTRU is in or out of coverage of the gNB providing relay and/or sidelink configuration
Whether the remote WTRU is in or out of coverage of the same cell/cell group as the relay WTRU via which the SI request is being sent
-some conditions related to measurements of cells of the remote WTRU in its coverage area and/or measurements possibly on the relay WTRU to which the remote WTRU is connected or the side link from which SI is requested
For example, if the remote WTRU is in the coverage of the same cell as it is connected to via a relay, or in the coverage of the same cell in which the WTRU is connected/camped, the remote WTRU may request SI using a PC5-RRC message. Alternatively, if the remote WTRU is within the coverage of a cell different from the relay WTRU cell, the remote WTRU may send the SI request using Uu RRC messages on the relay SL RLC channel.
For example, if the remote WTRU is within the coverage of a different cell than the relay WTRU and the RSRP measurement of the cell meets the configuration condition, the remote WTRU may send an SI request directly to the network via Uu.
Based on the type of service and/or QoS associated with such services
The remote WTRU may determine its mechanism for sending SI requests based on the type of service currently active at the WTRU and/or the service it is sending SI requests. In particular, the WTRU may be configured with a specific service to which SI requests are sent directly via Uu, whether or not it may be configured with a specific service to which SI requests are sent via the relay WTRU. For example, if one or more bearers of a particular priority or QoS are configured, the WTRU may transmit the SI request directly via Uu.
-based on Uu/SL connection state
The remote WTRU may determine its mechanism for sending SI requests based on its connection status with Uu and/or the side links and/or whether it is configured to transmit/receive services on Uu and PC5 simultaneously. For example, if the WTRU has at least one Uu bearer that is being transmitted directly via the Uu interface (as opposed to being relayed via a relay WTRU), the WTRU may transmit an SI request on Uu.
-network-based configuration
For example, the remote WTRU may be configured as to whether to transmit the SI request using a PC5-RRC message or a Uu RRC message via a relay SL RLC channel. Such configuration may further be implicit if the WTRU is configured with a SL RLC channel dedicated to Uu RRC message transmission.
Based on WTRU type/WTRU capabilities
The remote WTRU may determine a mechanism for transmitting SI requests and/or receiving SI based on the WTRU type and/or the capabilities of the WTRU. For example, a remote WTRU with certain capabilities may be allowed to transmit SI requests directly on Uu, possibly based on other conditions.
Relay WTRU behavior after receiving SI request from a remote WTRU
The relay WTRU may receive SI requests from the remote WTRU. Such SI requests may be in a PC5-RRC message, or may be differentiated by the relay WTRU using any of the mechanisms described above for transmitting requests by remote WTRUs. For example, the relay WTRU may create one or more dedicated SL RLC channels or LCHs associated with the receipt of SI requests, and may trigger any actions associated with the receipt of SI requests upon receipt of a message on such SL RLC channels. For example, upon receiving a message on such a SL RLC channel, the relay WTRU may trigger any actions associated with the receipt of SI requests.
Upon receiving an SI request from a remote WTRU, the relay WTRU may perform any one or a combination of the following:
performing Uu state transitions based on relay's own RRC state
a. For example, the relay WTRU may transition to rrc_connected after receiving an SI request in rrc_idle or rrc_inactive. On the other hand, if the relay WTRU is in rrc_connected, the relay WTRU may simply relay the SI request message without taking further action.
Initiate a Uu SI request and/or forward the request, possibly depending on its own Uu state,
may depend on whether the WTRU stores the requested SI
a. The relay WTRU may perform the SI request via Uu after receiving the SI request from the relay WTRU. Such behavior may further depend on the RRC state of the relay WTRU. Such a request may be performed only if the relay WTRU has not stored the requested SI
i. For example, the relay WTRU may initiate a Uu SI request when the relay WTRU is in rrc_idle/rrc_inactive. On the other hand, if the relay WTRU is in rrc_connected, the relay WTRU may ignore the SI request from the remote WTRU or forward the SI request to the network. For example, the relay WTRU may create/configure a SL RLC channel for receiving SI request messages from the remote WTRU. If the relay WTRU is in RRC_IDLE/RRC_INACTIVE, the relay WTRU may initiate an SI request via Uu after receiving a message from such SL RLC channel. On the other hand, if the relay WTRU is in rrc_connected, the relay WTRU may forward the message on the SL RLC channel to the Uu RLC channel.
For example, a relay WTRU in IDLE/INACTIVE may check after receiving SI if it stores a valid version of SI (by checking SIB 1). If it has a valid version, the relay WTRU may send SI to the remote WTRU. Otherwise, the relay WTRU may initiate an SI request on Uu.
Buffering SI requests by multiple remote WTRUs prior to performing Uu SI requests
a. For example, the relay WTRU may buffer/maintain all SI requests received from the connected/remote WTRUs, possibly for a period of time. For example, the relay WTRU may start a timer upon receiving the first SI request. The relay WTRU may accumulate all SI requests received when the timer is running. After the timer expires, the relay WTRU may send Uu SI requests, including all requested SI from the remote WTRU accumulated during the timer. For example, the relay WTRU may accumulate all SI requests received by the remote WTRU during a predefined period on Uu (e.g., one or more modification periods) or SL (e.g., one or more SL DRX cycles, SL modification periods, or similarly defined time intervals).
-if another remote WTRU makes a similar SI request, ignore/discard the SI request
a. For example, if the SI requested by a remote WTRU is requested by another remote WTRU, possibly for some past period of time, the relay WTRU may ignore/discard the SI request
-if the requested SI is currently being broadcast, ignoring/discarding the SI request
a. For example, if the SI requested by the remote WTRU is currently associated with SI being broadcast by the network (e.g., SI-broadcastStatus in SIB1 is set), the relay WTRU may ignore/discard the SI request
-adding the requested SI as SI of interest for the remote WTRU, as defined herein
-start monitoring/transmitting Uu SI changing its broadcast status
a. For example, the relay WTRU may determine which NW broadcast SI has changed its SI broadcast status to "broadcast" some time after receiving the SI request (possibly without an indication of which SI is requested). The time period may correspond to one or more SI modification periods. The period of time may correspond to expiration of a timer set after receiving the SI request. The relay WTRU may then send these SIs to the remote WTRU that has sent the SI request. Alternatively, the relay WTRU may broadcast/multicast these SIs on the PC 5.
-transmitting all SI broadcasted by NW, possibly after a certain period of time
a. For example, the relay WTRU may trigger transmission of a subset or all of the SIs broadcast by the NW, as determined after a certain period of time after receiving the SI request. Such time may be the number of modification periods or correspond to expiration of a timer.
-converting SI request message into SIB request message or vice versa
a. For example, the relay WTRU may receive an SI request message from the remote WTRU and may transmit a corresponding SIB request message indicating all SIBs in the corresponding SI. For example, the relay WTRU may perform such a transition when it receives an SI request while in rrc_connected.
-the relay WTRU is configured with a dedicated SL RLC channel triggering Uu SI request
According to an embodiment, a relay WTRU may be configured with a dedicated SL RLC channel that triggers SI requests. In particular, the relay WTRU may trigger an SI request (e.g., an MSG 1-based RACH procedure, an MSG 3-based RACH procedure, or the transmission of a dedicatedSIBRequest message) after receiving a PDU associated with a dedicated RLC channel or at some time after receiving a PDU associated with a dedicated RLC channel.
-the relay WTRU uses the information in the received SI request to trigger the UuSI request
The relay WTRU may further derive the content of the SI request from information in the received SI request (possibly in addition to other information it may generate).
-the relay WTRU generating a dedicatedSIBRequest from the received SI request
a. According to an embodiment, the relay WTRU may derive the requested SIB from an SI message requested by the remote WTRU. In particular, the relay WTRU may include all SIBs associated with the SI requested by the remote WTRU in the dedicatedSIBRequest message
-the relay WTRU using the PDU/request message received from the remote WTRU as part of the payload of the SI request
a. According to an embodiment, the relay WTRU may create an SI request RRC message (e.g., an MSG3 based SI request message or a dedicatedsibequest message) by transparently including a PDU (in the case of a relay SL RLC message) or a request message (e.g., a PC5-RRC message) within its own SI request message. The relay WTRU may further indicate the presence of such transparently included PDUs or request messages in its own SI request message on Uu by an RRC message type (e.g., a new RRC message) or by including an explicit indication in the SI request RRC message.
b. The relay WTRU may further include the SI that it wishes to request and the SI requested by the remote WTRU. Any additional SI requested by the relay WTRU itself may use a conventional mechanism to indicate the requested SI, i.e., a bitmap of the SI.
-the relay WTRU includes an identity of the requesting remote WTRU
a. The relay WTRU may include an ID of the remote WTRU (e.g., L2 ID, C-RNTI, remote WTRU ID, etc.) that requested the SI in a Uu SI request message
-the relay WTRU including SI requested from multiple remote WTRUs in a single Uu SI request
a. The relay WTRU may include in its SI/SIB request the requested SIB/SI of all remote WTRUs that may have sent SI requests to the remote WTRUs in the most recent time period.
b. Alternatively, the relay WTRU may include the payload of the SI/SIB request received from the remote WTRU in its own SI request RRC message (e.g., MSG3 based SI request or dedicatedsibequest). In particular, the relay WTRU may create an SI/SIB request RRC message including a payload of SI/SIB request messages received on a dedicated SL RLC channel, possibly from multiple remote WTRUs, as one or more transparent containers,
-the relay WTRU determining the type of Uu SI request to be made after receiving the SL SI request
Upon receiving an SI request from a remote location, the relay WTRU may initiate/transmit the SI request/procedure to the network. The relay WTRU may transmit the SI request using any of the following:
-dedicatedSIBRequest
-SI request based on MSG1, or SI request based on MGS3
The WTRU may determine which type of SI request to use based on a number of factors. Such factors may further determine whether the relay WTRU should perform a connection setup/recovery procedure in order to send one type of SI request instead of another (e.g., able to send a dedicatedSIBRequest).
The relay WTRU may determine the type of SI request based on any one or a combination of the following:
-relay RRC state of WTRU
a. For example, the relay WTRU may send SI requested from the remote WTRU using the dedicatedSIBRequest when the relay WTRU is in rrc_connected, and may use MSG1 or MSG3 based SI requests when the relay WTRU is in rrc_idle/rrc_inactive.
Cell ID/area ID (possibly associated with cell group) provided by remote WTRU in its SI request that remote WTRU is in its coverage area
a. For example, the relay WTRU may determine the type of SI request based on a cell ID or area ID provided by the remote WTRU, which may represent the cell or area within its coverage area, and whether such cell ID/area ID is the same as the cell ID/area ID of the cell to which the relay WTRU is connected/camping.
b. For example, if the relay WTRU camps on the same cell as the coverage cell of the remote WTRU, the relay WTRU may transmit an MSG 1-based or MSG 3-based SI request. Alternatively, if the relay WTRU camps on a different cell or broadcasts a different area ID than the coverage cell of the remote WTRU, the relay WTRU may use the dedicatedSIBRequest message to initiate RRC connection/restoration and/or request SI.
-coverage status (IC or OOC) and/or measurement provided by a remote WTRU
a. For example, the relay WTRU may perform a dedicatedsibequest for the remote WTRU of OOC while in RRC_CONNECTED, and may perform an MSG1/MSG3 based SI request for the remote WTRU within coverage area
b. For example, the relay WTRU may determine the type of request based on whether the measurement provided by the remote WTRU (measurement of the cell on Uu, or side chain measurement) is above/below a threshold. Such measurements may be provided in the request, or in another message prior to the request
-number of remote WTRUs, number of remote WTRUs requesting SI, or number of SI requests that may be received over a period of time
a. For example, the relay WTRU may choose whether to use an MSG 1-based or MSG 3-based SI request based on the number of remote WTRUs, the number of SI transmitted, the number of remote WTRUs that have requested SI, or some other factor related to SI requests made by remote WTRUs.
Alternatively, the relay WTRU may always use one type of request (e.g., MSG3 based SI request while in rrc_idle/rrc_inactive), whether or not such request is triggered by a request sent by the remote WTRU.
-the relay WTRU determining parameters associated with a UuSI request from a remote WTRU si request
The relay WTRU may determine parameters of the Uu SI request based on receiving SI requests from one or more remote WTRUs. Parameters associated with the SI request may include one or any of the following:
preamble or preamble set usable for SI requests
-number of repetitions associated with sending SI request
Initial transmit power (e.g., for transmitting RACH)
-beam configuration, or selected beams for performing RACH procedure
Specific UL resources (e.g., grant of specific configuration, specific carrier) for transmitting SI requests,
including additional information in or with the transmission of the SI request, such as an RRC IE transmitted within the SI request message, a MAC CE multiplexed with the SI request message, or an additional RRC message,
the selection of such parameters may be used to indicate to the gNB any of the following:
the SI request is triggered by the remote WTRU (rather than the relay WTRU itself)
-SI request associated with a specific remote WTRU
SI request is performed by an in-coverage or out-of-coverage WTRU
The SI request is performed by a WTRU that is within coverage of the same cell or a different cell than the relay WTRU
The SI request is associated with a specific priority, qoS, SLRB configuration, etc. that may indicate the importance/criticality/delay required for SI delivery
SI request associated with a specific SL monitoring (e.g., SL DRX) schedule for a remote WTRU
For example, the relay WTRU may be configured with one or more dedicated preambles associated with transmitting SI requests that are triggered by receiving SI requests from remote WTRUs.
-remote WTRU receiving a response to SI request on dedicated SL RLC bearer
The remote WTRU may receive a response to the SI request (e.g., performed on Uu SRB0 and relayed via a relay WTRU connected by PC 5) on the dedicated SL RLC bearer. Such dedicated SL RLC bearers may have a SL RLC configuration for the (pre) configuration of the reception. Alternatively, the remote WTRU may receive such dedicated SL RLC bearer configuration from the relay WTRU.
The relay WTRU may receive TX/RX configuration (e.g., in dedicated RRC signaling) from the network for such SL RLC bearers. The relay WTRU (e.g., in rrc_connected) may map a dedicated Uu RLC bearer (for sending SI responses) to such a SL RLC bearer. Alternatively, the relay WTRU may route all RRC messages it receives that are indicated as destined for the remote WTRU to such SL RLC bearers.
The remote WTRU may send an SI request message (e.g., similar to the MSG 3-based SI request RRC message) on the relayed Uu SRB 0. The remote WTRU may send such SI request message only when the remote WTRU is in rrc_idle/rrc_inactive. In response, the remote WTRU may receive (e.g., in a Uu RRC message) any of the following on the dedicated SL RLC bearer for reception:
-a Uu RRC message containing the requested SIB/SI or a subset of the requested SIB/SI
-an acknowledgement message indicating successful receipt of the SI request by the network
-an indication that the requested SI should be received directly via Uu
a. For example, upon receiving such an indication in a response, the remote WTRU may monitor the Uu interface for the requested SI
The remote WTRU may expect a response to the SI request:
-immediately, or a specific period of time after the request
-one or more SL-DRX cycles after request
-one or more modification periods after the request.
The remote WTRU may retransmit the SI request if no response is received within the expected response time.
Remote WTRU creation of dedicated SL RLC bearer
According to an embodiment, the remote WTRU may create a dedicated SL RLC bearer associated with the receipt of the response to the SI request. The remote WTRU may create such a SL RLC bearer based on a trigger from the relay WTRU. For example, the remote WTRU may create such a SL RLC bearer for reception after the relay WTRU receives a configuration message configured for the SL RLC bearer transmitted at the relay WTRU. For example, the remote WTRU may be in an indication (explicit or implicit) from the relay WTRU: the relay WTRU creates such SL RLC bearers for reception after being (or having transitioned to) rrc_connected. The remote WTRU may maintain such RLC bearers as long as the remote WTRU is in rrc_idle/rrc_inactive. For example, a remote WTRU in rrc_connected may release such bearers and rely on SL RLC bearers that relay SRB1 traffic for requests and responses of SI.
Remote WTRU determines how to receive SI request responses (e.g., SI) based on the presence of dedicated SL RLC bearers
The remote WTRU may determine how to receive a response to the SI request based on the presence of such a dedicated SL RLC bearer. In particular, the remote WTRU may receive such a response from the relay WTRU via a PC5-RRC message without creating a dedicated SL RLC bearer for receiving the SI request response. Alternatively, if such RLC bearers exist at the remote WTRU, the remote WTRU may receive the SI request response via the SL RLC bearer for Uu signaling.
-relay WTRU obtaining SL resources for transmitting SI on side link
Dedicated SR for obtaining SL resources
The relay WTRU may be configured with one or more dedicated SRs to obtain SL resources (in mode 1) for transmitting SI. Specifically, when a relay WTRU needs to transmit SI to one or more remote WTRUs on a side link, the relay WTRU may transmit SR on Uu. In one example, a relay WTRU may be configured with a single SR resource.
-a plurality of dedicated SR resources, each associated with an element of the size of the SL transmission
As another example, a WTRU may be configured with multiple SR resources, where each SR resource is used to give:
Number of remote WTRUs that have requested SI
-number of different SIs that have been requested by one or more remote WTRUs
The size of the requested SI, or the amount of side link resources required by the relay WTRU to transmit SI on the side link
The relay WTRU may trigger the SR when doing any one or a combination of the following operations:
-SR triggered upon receipt of SI request: the relay WTRU receives SI requests from one or more remote WTRUs. The relay WTRU may receive the SI request using any of the methods described herein for the remote WTRU to transmit the SI request such that the SI request is visible to the relay WTRU.
a. For example, the relay WTRU may trigger the SR after receiving the first SI request.SR prohibition determination dedicated to SI request Time device: to avoid triggering multiple SRs, the relay WTRU may be configured with an SR prohibit timer dedicated to SI requests. In particular, the relay may then start a timer, wherein such timer is dedicated to SI request SR. The relay WTRU may avoid triggering additional after receiving subsequent SI requests from other remote WTRUs while the timer is runningIs a SR transmission of (c).
SR triggered sometime after SI request: after expiration of a timer started after receiving the first SI request, or after a (pre) configured time after receiving the first SI request from the remote WTRU. Specifically, the relay WTRU may start a timer after receiving the first SI request message. Then, when the timer expires, the relay WTRU may transmit the SR. Alternatively, the relay WTRU may transmit the SR some fixed/relative time after receiving the SI request, where such time may further depend on the SI modification period, the requested SI, or the DRX configuration on the side link
-SR triggered after determining by the relay that SI needs to be transmitted on the side link: the relay WTRU determines that it needs to be on the side chain
SI is transmitted on the road. Specifically, the relay WTRU may transmit the SR when or due to:
a. the relay WTRU detects changes in SI broadcast by the network (e.g., changes in value tags)
b. The relay WTRU detects a change in the relay specific SI and the relay WTRU is configured to send the relay specific SI only to its remote WTRU
c. A periodic timer. In particular, the relay WTRU may periodically transmit broadcast SI from the cell on the side link and may trigger SR according to the same period
d. The relay WTRU detects a change in the broadcast status (e.g., broadcast versus non-broadcast) of a particular SI over the network
The WTRU includes in the BSR the amount of data for SI transmission on the side-link
Alternatively, the relay WTRU may request resources using a BSR, where the size of SI to be transmitted may be added to the buffer status of one or more logical channels on the side link. Alternatively, the relay WTRU may be configured with a dedicated logical channel for SI transmission. For example, the WTRU may be configured with an LCH for each remote WTRU (i.e., each unicast link and/or source/destination ID pair). Alternatively, the WTRU may be configured with an LCH associated with a broadcast/multicast L2 ID. Such broadcast/multicast L2 IDs may be used to transmit SI to all connected remote WTRUs on a side link.
A WTRU is configured with one or more side links CG due to SI transmission
According to an embodiment, a WTRU may be configured with one or more side-link CGs for SI transmissions. The WTRU may be configured to transmit SI on the side link using the resources of such CG. For example, the WTRU may be configured with LCH restrictions that map only data from dedicated side link logical channels for SI to such CG. For example, the WTRU may be configured with LCH restrictions that do not allow LCHs that are not associated with SI transmissions on the side link to use such CG.
The WTRU may be configured to activate such SL CG when SI needs to be transmitted on the side link. Specifically, the WTRU may activate the SL CG when:
-receiving an SI request from a remote WTRU, using any of the methods of the remote WTRU for transmitting an SI request described herein, such that the SI request is visible at the relay WTRU
The wtru may further activate the SL CG upon receiving a first SI request of the plurality of consecutive SI requests (e.g., based on use of a timer, as described elsewhere herein)
Transmission of SI requests on Uu, where such SI requests are performed on behalf of the remote WTRU (e.g., as a result of receiving SI requests on the side link, or when determining that SI should be transmitted on the side link)
-receiving an acknowledgement of such SI request transmitted on Uu
-a certain (pre) configuration or predefined time after any of the above
a. Such time may be a function of the SI modification period that may be on Uu. For example, the WTRU may activate CG in a modification period after transmitting the SI request. For example, after an SI request, the WTRU may activate CG during a modification period where the WTRU monitors SI on Uu.
Some (pre) configuration or predefined time with respect to SI broadcast on Uu
a. For example, the WTRU may activate the grant of the SL configuration immediately, or at some (pre) configured or predefined time after a modification period associated with one or more SIs, possibly within a modification period where the NW starts broadcasting a particular SI (i.e., the broadcast bits in SIB1 for the SI are switched).
The WTRU may assume that the SL CG remains active for a limited period of time after activation. For example, the WTRU may be (pre) configured with a timer that starts upon CG activation. When the timer expires, the WTRU may disable/deactivate the SL CG. For example, the WTRU may activate one or more single transmission opportunities of the SL CG after any of the triggers described above. For example, the WTRU relay WTRU may deactivate the SL CG when the network stops broadcasting a particular SI (e.g., the broadcast bits in SIB1 for SI are switched).
The WTRU may be configured with multiple CGs and the association of CG with factors related to the requested/broadcasted SI. The WTRU may then activate a particular CG based on such association. Specifically, the WTRU may be configured with a CG to use for a given:
number of remote WTRUs that have requested SI
-number of different SIs that have been requested by one or more remote WTRUs
The size of the requested SI, or the amount of side link resources required by the relay WTRU to transmit SI on the side link
-the WTRU receives SL authorization for SI transmission as part of the SI request procedure
According to an embodiment, the relay WTRU may receive a SL grant for SI transmission during the Uu SI request procedure. In particular, the WTRU may receive such SL grants
-in MSG2/MSG4 of SI request procedure
a. In particular, the relay WTRU may trigger the SI request procedure based on RACH (e.g., based on MSG1 or based on MSG 3) and may receive a SL grant for transmitting SI on the side link
Scheduling SI transmissions on Uu in DCI
a. Specifically, the relay WTRU may receive SI via dedicated signaling. In providing the grant of SI to the relay WTRU, the relay WTRU may further receive a SL grant for transmitting SI on the side link
In MAC CE on Uu
a. Specifically, the relay WTRU may receive SI via dedicated signaling. In providing the relay WTRU with the grant of SI or another grant on DL, the relay WTRU may further receive a MAC CE containing the SL grant for transmitting SI
WTRU triggers resource (re) selection for transmitting SI on side-link
According to an embodiment, the WTRU may trigger a resource (re) selection for transmitting SI received from the cell on the side link. The WTRU may trigger the selection if the WTRU does not have resources for SI transmission. The WTRU may use the single use resources for SI transmission. Alternatively, the WTRU may use multiple resources (periodic set of resources) to transmit SI to its remote WTRU or WTRUs. The WTRU may trigger such resource (re) selection based on any of the triggers provided herein for sending SI on the side link. Further, the relay WTRU may trigger a resource reselection if any of the following conditions are met:
existing SL procedure is inconsistent with SL DRX timing of remote WTRUs to which the SL SI needs to be transmitted
-existing SL procedure is not consistent with the timing of Uu SI reception time
a. In particular, the relay WTRU may trigger resource reselection based on the Uu SI modification period/SI window to align the SL transmit time with the Uu reception of the SI
Relay WTRU transmits SI on the side link using SL SRB
According to an embodiment, a relay WTRU may create a SL SRB for transmitting SI on a side link. Such SL SRBs may be the same SL SRBs used for PC5-RRC signaling (e.g., for PC5 reconfiguration messages). Alternatively, the relay WTRU may create a dedicated SL SRB or SL RLC channel for transmitting SI on the side link. The relay WTRU may create such SL SRB/SL RLC channels when the relay WTRU is in/transitioning to Uu rrc_idle/rrc_inactive, and may release such SL SRB/SL RLC channels when the relay WTRU is in rrc_connected.
The relay WTRU may transmit SI to each connected remote WTRU (i.e., all remote WTRUs with which the relay WTRU has a unicast link) individually. The relay WTRU may determine the connected remote WTRU based on a list of L2 source/destination ID pairs associated with relay-only unicast links. Alternatively, the relay WTRU may maintain a local list of physical WTRU IDs that may be assigned to each remote WTRU (e.g., during link setup/configuration). The relay WTRU may transmit SI to a given remote WTRU using one of the L2 IDs associated with each physical WTRU. Alternatively, the relay WTRU may send SI to all remote WTRUs in multicast.
The relay WTRU may maintain/use one or more dedicated L2 source and/or destination ID pairs for transmitting SI messages, possibly for each remote WTRU, and use the ID for transmitting SI messages on the side link. For example, a source/destination pair may be configured for each remote WTRU. The same or different source/destination pairs may be used for each remote WTRU. Alternatively, the WTRU may be configured with a multicast L2 destination for broadcasting SI to remote WTRUs. The remote WTRU may be configured to monitor transmissions with such source and/or destination IDs to receive SI from one or more relay WTRUs.
Trigger for transmitting SI on side link
The relay WTRU may send SI to one or more remote WTRUs based on any of the following triggers:
-when establishing a PC5-RRC connection with a remote WTRU for relay
a. For example, when establishing a PC5-RRC connection for relaying, the relay WTRU may send a PC5-RRC message containing all/part of the SI received by the relay WTRU from the cell
-when a PC5-RRC reconfiguration message is received from the remote WTRU, a first configuration message may be received, a configuration message indicating SI of interest may be received
Remote WTRU-based request
Periodically, wherein such period may depend on
Modification period of SI on uu
b. DRX configuration for remote/relay WTRU
c. Certain (pre) configurations or predefined periods
d. Period of time, which depends on
i. SL QoS/SLRB configuration for remote/relay WTRU
Measured CBR
1. In particular, the relay WTRU may determine the periodicity of the broadcasted SI based on the measured CBR and may transmit with a larger periodicity in case of a larger CBR
Access class/class for remote WTRU
Relay extracts a portion of SI for transmission in discovery messages
The relay WTRU may broadcast a portion of Uu SI on the discovery message. The relay WTRU may extract such information from the SI received from the cell and include it in the discovery message. Such information may include, but is not limited to, any of the following:
cell ID
-PLMN ID
RAN area ID
-access control parameters
The relay WTRU may further exclude such information in dedicated SI transmissions to its remote WTRU.
Relay broadcast remote WTRU capable of reading system information
The relay WTRU may broadcast (e.g., in a discovery message and/or other message on the SL) information for the remote WTRU to be able to receive/decode/interpret the SI. Such information may include, but is not limited to:
-L2 address for receiving system information from a specific relay
a. For example, the relay WTRU may be configured (e.g., by an upper layer) with an L2 source and/or destination ID for transmitting system information. Upon receiving the discovery message from the relay WTRU, the remote WTRU may store the L2 source and/or destination IDs and use them to receive SI from the particular relay WTRU. The remote WTRU may maintain an association between the L2 source and/or destination IDs of the relay WTRU (e.g., transmitted in the discovery message) and the L2 source and/or destination IDs used to receive SI from the relay WTRU
Time/frequency resources (e.g., DRX cycles) in which the remote WTRU may read SI
a. For example, the relay WTRU may determine a set of time/frequency resources (as described herein) for transmission of the SI and may indicate such time/frequency resources in a discovery message. For example, the relay WTRU may select a time slot and period for SI transmissions that fall within the SL DRX cycle/mode of the relay WTRU. Such indication of resources and/or SL DRX cycle/mode may be transmitted by the relay WTRU in a discovery message of the relay WTRU
Value tags or labels
a. For example, the relay WTRU may broadcast an identity of each version with one or a set of SIs. The relay WTRU may determine the value of such an identity, e.g., based on whether it determines a change in a relay specific element of the SI, as described herein. Alternatively, the relay WTRU may transmit the same tag, or the function of a tag received from the SI on Uu.
The relay WTRU may transmit SI during a particular time window, which may depend on:
-L2 ID of relay WTRU
-DRX cycle (on period) of a relay WTRU or a remote WTRU
Implicit/explicit time indication (e.g. offset) indicated by relay in periodic messages such as discovery messages
Whether the SI tag has changed
a. For example, the relay WTRU may always transmit SI when the broadcasted SI tag has changed
-whether the relay WTRU has a connected remote WTRU
a. For example, if the SI tag has changed and the relay WTRU has a connected remote WTRU, the relay WTRU may always broadcast SI for a given period of time
A remote WTRU is configured with a request for SITime/frequency limitation of the solution
According to an embodiment, the remote WTRU may be configured with an allowable period of time, or an allowable set of frequency resources, in which it may transmit the SI request. For example, the remote WTRU may transmit the SI request only for a limited number of subframes after the discovery message, SI tag (or similar periodic message) is transmitted by the relay WTRU. The set of time/frequency resources in which the remote WTRU may transmit the SI request may further depend on the relay WTRU on which the remote WTRU is transmitting the SI request. In particular, the remote WTRU may configure the limit of the time/frequency resources it may transmit SI requests based on any one or a combination of the following:
-based on the on-duration of the relay WTRU, if the relay WTRU is in DRX
a. For example, the remote WTRU may transmit SI requests to a particular relay WTRU only during relay WTRU SL DRX on periods (which may be determined via, for example, PC5-RRC signaling, or broadcast in a discovery message)
-based on a time period related to periodic/regular transmissions of the relay WTRU
a. For example, the remote WTRU may be allowed to transmit SI requests in a plurality of time slots that occur with respect to transmissions by the relay WTRU, where such transmissions by the relay WTRU may be any of the following: discovery transmissions, SI tag transmissions, or similar periodic transmissions by the relay WTRU used by the remote WTRU before or after the PC5-RRC connection to the relay WTRU. For example, the remote WTRU may transmit SI requests only in X slots after such relay transmissions by the remote WTRU.
-based on an identity associated with the relay WTRU
a. For example, the remote WTRU may derive an offset and/or a number of slots from a predefined time based on the L2 ID of the relay WTRU
Based on the offset or the number of time slots, or similar information provided by the relay
a. For example, a remote WTRU may transmit such information in a discovery message or the like
-relay WTRU broadcasting system informationRelay section
According to an embodiment, a relay WTRU may transmit SI received from its associated cell on a side link. The relay WTRU may further transmit only a subset of the SI of the cell, where such subset may represent the SI required by the remote WTRU to access the cell via the relay WTRU. The WTRU may further transmit the relay subset SI unless otherwise requested, either depending on the type of transmission used to transmit the SI, or depending on the presence of a remote WTRU CONNECTED by the PC5 while in rrc_connected. For example, the relay WTRU may broadcast the relay subset SI in the broadcast, but may transmit the non-relay subset SI (e.g., to support service continuity) when requested by a remote WTRU that is PC5-RRC CONNECTED and rrc_connected to Uu via the relay WTRU.
The relay subset SI may consist of a set of SIBs or a set of IEs within one or more SIBs from the associated cell. These SIBs and/or IEs may be predefined (e.g., in a standard) or (pre) configured. For example, when transmitting SI, the relay WTRU may transmit only a predefined subset of the IEs in the SIBs read from the cell.
The relay WTRU may determine to transmit the relay subset SI or to transmit (possibly additionally) the non-relay subset SI, depending on:
-transmissions used by repeaters to transmit SI
a. For example, the relay WTRU may broadcast only the relay subset SI. If the relay WTRU needs to transmit SI in unicast, the relay may transmit both the relay subset SI and/or the non-relay subset SI
Whether SI is transmitted as a result of SI request or whether the WTRU is PC5-RRC connected
a. For example, if a relay WTRU receives a request for SI from a PC5-RRC connected WTRU, the relay WTRU may transmit a non-relay subset SI. Otherwise, the relay may transmit a relay subset SI
-requesting Uu RRC state and/or PC5-RRC state of the WTRU
a. For example, if the requesting WTRU is a non-PC 5-RRC connected WTRU, or if the Uu RC state of the requesting WTRU is rrc_idle/rrc_inactive, the relay WTRU may broadcast the relay subset SI. If the requesting WTRU is a PC5-RRC CONNECTED WTRU in Uu RRC_CONNECTED, the relay WTRU may transmit a non-relay subset SI (possibly in addition to the relay subset SI)
-type of SI request message, or content of SI request message
a. For example, if the SI request is of a first type, the relay WTRU may broadcast a relay subset SI, and if the request is of a second type, the relay WTRU may broadcast a non-relay subset SI. The request type may include a message type (e.g., PC5-RRC versus MAC CE, PC5-RRC versus broadcast SL transmission, etc.)
b. For example, the remote WTRU may request to relay a particular SI or all cell SIs, and may indicate this in its request message (whether it is requesting to relay a particular SI or all cell SIs). The remote WTRU may be further configured with conditions as to when/if relaying a particular SI or all SI should be requested. For example, such conditions may depend on:
i. coverage conditions for remote WTRUs
1. For example, the remote WTRU may request all cell SI when the remote WTRU is in coverage, and may request only relay portions of SI when the remote WTRU is out of coverage
Cell ID of cell to which relay WTRU is connected
1. For example, if the remote WTRU is in the coverage of the same cell to which the relay WTRU is connected/in its coverage, the remote WTRU may request all cell SIs. Otherwise, the remote WTRU may request only the relay part of the SI
Relay WTRU determination/broadcast SI tag
The relay WTRU may broadcast SI tags associated with SI it obtains from its associated cell. The relay WTRU may periodically broadcast the SI tag in any of the periodic transmissions (e.g., discovery messages) described herein.
The relay WTRU may increment/change the SI tag when either:
Relay WTRU performs cell mobility (cell reselection to a different cell or HO to a different cell)
-the relay part of SI in the associated cell has changed
-the relay WTRU changing its RRC state
Relay WTRU changing from relay to non-relay or vice versa
When a relay WTRU changes its SI tag, it may transmit some or all of the SI of its associated cell. For example, the relay WTRU may decide to transmit only the portion of SI that caused the SI tag change after the SI tag change.
-the relay WTRU transmitting updated SI to the remote WTRU based on the known/interesting SIB/SI
According to an embodiment, the relay WTRU may transmit updated SI to the remote WTRUs based on known/interesting SIBs/SI associated with each or all connected remote WTRUs. For example, a relay WTRU may periodically broadcast all SI broadcast by the network. Possibly in addition to this, the relay WTRU may broadcast all known/interesting SIBs/SIs in a periodic manner. Alternatively, the relay WTRU may broadcast only (e.g., multicast on SL, or unicast to each remote WTRU) the SI broadcast by the network, and the transmission (e.g., sent to a particular WTRU in a dedicated manner, or to all remote WTRUs on SL, or connected remote WTRUs) corresponds to the on-demand SI of the SIB/SI of interest. The WTRUs may transmit these on-demand SI, which is the SI of interest to some WTRUs, either temporarily or only once (upon any such SI change).
-relay WTRU determining SI of interest based on explicit signaling
According to embodiments, the relay WTRU may transmit any updated/changed SI to the relay based on a list of known SIBs/SIs of interest maintained for the remote WTRU and/or multiple remote WTRUs. In particular, the relay WTRU may maintain a list of SIBs/SIs of interest for each remote WTRU or for all connected remote WTRUs. The relay WTRU may obtain such SIB/SI of interest via PC5-RRC signaling with the remote WTRU. For example, the remote WTRU may provide the relay WTRU with a list of its SIBs/SIs of interest. If such a list of interesting SIBs/SIs changes, the remote WTRU may send a new list of interesting SIBs/SIs to the relay WTRU.
-the relay WTRU determining SI of interest based on a request for remote WTRU explicit signaling
Alternatively, the relay WTRU may determine a list of SI of interest likely to be targeted to a particular remote WTRU based on SI requests from the remote WTRUs. For example, the relay WTRU may add a particular SI to a list of SI of interest that may be targeted to the particular remote WTRU when the remote WTRU requests the SI.
-the relay WTRU removing SI of interest based on release of unicast link with remote WTRU
When the connection with the remote WTRU is released, the relay WTRU may remove the particular SI from the list of SI of interest that may be targeted for the particular remote WTRU. If the relay WTRU maintains a list of the SI of interest for the group of remote WTRUs, the relay WTRU may remove the SI of interest only if the released remote WTRU is the last remaining WTRU for which the SI is of interest
Relay WTRU behavior
Upon a change in SI of a connected/associated cell, the relay WTRU may determine whether such changed SI corresponds to any of the SI of interest of one or more of its connected remote WTRUs. If so, the relay WTRU may send the updated SI to the remote WTRU. For example, the relay WTRU may send a unicast PC5-RRC message to a remote WTRU interested in the changed SI. Alternatively, in the case where the SI corresponds to any of the SI of interest of any PC5 connected remote WTRU, the relay WTRU may send a multicast PC5-RRC message to all connected remote WTRUs.
The relay WTRU may request SI from its connected/associated cell based further on the SIB of interest of its remote WTRU. In particular, the relay WTRU may consider the SI of interest of the connected remote WTRUs when detecting SI changes on the connected/associated cells, and may perform SI requests to cells for these SI of interest on behalf of its remote WTRUs. In particular, if an on-demand SI changes (i.e., if the relay WTRU detects a change in the value tag of an SI that is not broadcast by the network (and thus on-demand), the relay WTRU may trigger an SI request for such SI. Upon receiving such an SI, the relay WTRU may send the updated SI to the remote WTRU or WTRUs (possibly the particular WTRU interested in such an SI).
Remote WTRU transmitting (and possibly canceling) SI request when relay WTRU changes SI tag
The remote WTRU may transmit an SI request, possibly after the SI tag is changed by the relay WTRU. The remote WTRU may transmit the SI request immediately after the SI tag change. Alternatively, the remote WTRU may transmit the SI request for a (pre) configured period of time after detecting the SI tag. Such times may depend on:
CBR measured on side chain
a. For example, for larger CBR, the period of time between the change of SI tag and the transmission of SI request may be larger
Speed of WTRU
L2 ID of remote WTRU
-L2 ID of relay WTRU
Random amount of time
b. For example, the WTRU may SI request at random time intervals after SI tag change
The remote WTRU triggers an SI request and may cancel such a request if it detects an SI request transmission performed by another WTRU:
possibly associated with the same relay WTRU;
possibly associated with the same SI tag;
possibly associated with the same cell;
possibly associated with the same SI being requested.
Fig. 4 is a flow chart illustrating a representative method implemented by a WTRU for recovering a radio resource control connection. The representative method may be implemented, for example, by a wireless transmit/receive unit (WTRU) for recovering a Radio Resource Control (RRC) connection with a network, wherein the WTRU connects to a relay WTRU via a PC5-RRC connection and has an active Uu RRC connection with the network via the relay.
Referring to fig. 4, a representative method 400 may include, at block 401, detecting a side link radio link failure (SL-RLF) with a relay WTRU.
The representative method 400 can include, at block 402, performing cell reselection to select a suitable cell.
The representative method 400 may include, at block 403, performing a Random Access Channel (RACH) procedure (e.g., two-step, four-step) under the same conditions of the selected cell as the cell to which the relay WTRU is connected, and providing a Packet Data Convergence Protocol (PDCP) status report in a data portion of the RACH.
In some representative embodiments, the method 400 may include initiating a Conditional Handover (CHO) procedure to a selected cell, provided that the selected cell is different from the cell to which the relay WTRU is connected and the selected cell is configured as a conditional Handover (HO) candidate. For example, the WTRU does not treat the cell as a candidate in its conditional HO list.
In some representative embodiments, the method 400 may include transitioning the RRC state to rrc_inactive and initiating a recovery procedure with the selected cell if the selected cell is different from the cell to which the relay WTRU is connected and the selected cell is not configured as a conditional HO candidate.
In some representative embodiments, the recovery procedure may include using one of a dedicated interactive radio network temporary identity (I-RNTI) including a SL-RLF flag and a cell RNTI (C-RNTI) or another connection mode identity of the WTRU. For example, "dedicated I-RNTI" may mean that the identity is unique to the WTRU and assigned by the Network (NW). For example, the SL-RLF flag may be part of an I-RNTI (e.g., a pre-configured set of bit combinations) when recovery is performed after a transition to INACTIVE due to the SL-RLF.
Fig. 5 is a flowchart illustrating a method for determining whether a relay WTRU/INACTIVE relay WTRU in an rrc_inactive state may provide network-initiated connection services for a remote WTRU based on a coverage state of the remote WTRU, a Channel Busy Ratio (CBR), and access control decisions made by the network; if the network rejects the relay WTRU, then it indirectly rejects the network connection). Providing network initiated connection services may mean that the relay will provide connection services for the remote WTRU. However, regardless of whether the relay provides connection services, the relay may still forward the page to the remote WTRU and cause it to trigger the connection. When a relay can provide a connection service, the connection is via the relay.
Referring to fig. 5, a method 500 may include, at block 501, receiving an in-coverage/out-of-coverage (IC/OoC) indication from a remote WTRU indicating whether the remote WTRU is IC or OoC in a suitable cell.
The method 500 may include, at block 502, receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by a relay WTRU.
The method 500 may include, at block 503, forwarding the paging message on a side link with the remote WTRU associated with the paging message on the condition that the IC and CBR is above a threshold, and instructing the remote WTRU to trigger an RRC connection (with the network) via Uu.
In some embodiments, the method 500 may include, in a condition that the remote WTRU associated with the paging message is IC and CBR is not above a threshold:
-transmitting a recovery request message indicating that paging of the IC remote WTRU is for a recovery reason;
-on receipt of a recovery message from the network:
a. transition to rrc_connected/CONNECTED and forward the paging message on SL using the resource allocation contained in the resume message;
-on receipt of a reject/release message from the network:
a. remain in rrc_inactive/INACTIVE, forward paging messages (e.g., using mode 2 resources) and instruct the remote WTRU to trigger an RRC connection via Uu. Mode 2 (and mode 1) refers to the resource allocation mode in the side link. Mode 1 is the network scheduled resource allocation and mode 2 is the WTRU autonomous resource allocation.
In some embodiments, the method 500 may include, in the case that the remote WTRU associated with the paging message is on OoC:
-transmitting a recovery request message indicating that paging of the OoC remote WTRU is the cause of recovery;
-forwarding the paging message on the SL using the resource allocation set in the recovery message on condition that the recovery message is received from the network;
-discarding the remote WTRU paging message on receipt of a reject/release from the network.
Figure 6 is a flow chart illustrating another embodiment of a method 600 for determining whether a relay WTRU/INACTIVE relay WTRU in an rrc_inactive state may provide network-initiated connection services for a remote WTRU based on a coverage status of the remote WTRU, a Channel Busy Ratio (CBR), and access control decisions made by the network; if the network rejects the relay WTRU, then it indirectly rejects the network connection). Providing network initiated connection services may mean that the relay will provide connection services for the remote WTRU. However, regardless of whether the relay provides connection services, the relay may still forward the page to the remote WTRU and cause it to trigger the connection. When a relay can provide a connection service, the connection is via the relay. The method 600 for providing paging message service may be implemented by an INACTIVE relay wireless receiving transmitting unit WTRU, for example, by a relay in rrc_inactive state. The method comprises the following steps:
-receiving (601) an in-coverage IC indication from the remote WTRU indicating that the remote WTRU is in an IC of a suitable cell;
-receiving (602) a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and
forwarding (603) the paging message on the side link SL on condition that the channel busy ratio CBR is above a threshold and instructing the remote WTRU to trigger a radio resource control, RRC, connection via Uu.
According to another embodiment, the method 600 may include: and transmitting a resume request message indicating that paging of the IC remote WTRU is a cause of resume on condition that the CBR is not above the threshold.
According to another embodiment, the method 600 may include: after transmitting a resume request message indicating that paging of the IC remote WTRU is the cause of the resume, the relay WTRU is transitioned to connected and forwards the paging message on the SL using the resource allocation contained in the resume message on condition that the resume message is received from the network.
According to another embodiment, the method 600 may include: after transmitting a resume request message indicating that paging of the IC remote WTRU is the cause of resume, the relay WTRU is kept INACTIVE (e.g., in rrc_inactive state) on receipt of a reject (or release) message from the network, forwards the paging message, and instructs the remote WTRU to trigger an RRC connection via Uu.
In accordance with an embodiment, a relay wireless transmit/receive unit (WTRU) is also disclosed, the relay WTRU comprising a circuit including a receiver, a transmitter, and at least one processor, the relay WTRU being INACTIVE (e.g., in an rrc_inactive state), and the circuit being configured to: receiving an in-coverage IC indication from the remote WTRU indicating that the remote WTRU is in an IC of a suitable cell; receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by a relay WTRU; and forwarding a paging message on the side link SL on a condition that the channel busy ratio CBR is above a threshold and instructing the remote WTRU to trigger a connection, e.g., a radio resource control, RRC, connection via Uu.
According to another embodiment of the relay WTRU, the circuitry is further configured to transmit a resume request message indicating that paging of the IC remote WTRU is a cause of resume if the CBR is not above a threshold.
According to another embodiment of the relay WTRU, the circuitry is further configured to: after transmitting a resume request message indicating that paging of the IC remote WTRU is the cause of the resume, the relay WTRU is transitioned to connected and forwards the paging message on the SL using the resource allocation contained in the resume message on condition that the resume message is received from the network.
According to another embodiment of the relay WTRU, the circuitry is further configured to: after transmitting a resume message indicating that paging of the IC remote WTRU is the cause of the resume, the relay WTRU is kept INACTIVE (e.g., in state rrc_inactive) on receipt of a reject (or release) message from the network, forwards the page message, and instructs the remote WTRU to trigger a connection via Uu, e.g., an RRC connection.
Fig. 7 is a flowchart illustrating another embodiment of a method 700 for determining whether a relay WTRU/INACTIVE relay WTRU in an rrc_inactive state may provide network-initiated connection services for a remote WTRU based on a coverage status of the remote WTRU, a Channel Busy Ratio (CBR), and access control decisions made by the network; if the network rejects the relay WTRU, then it indirectly rejects the network connection). Providing network initiated connection services may mean that the relay will provide connection services for the remote WTRU. However, regardless of whether the relay provides connection services, the relay may still forward the page to the remote WTRU and cause it to trigger the connection. When a relay can provide a connection service, the connection is via the relay. The method 700 may be implemented by an INACTIVE relay wireless receive transmit unit WTRU (e.g., by a relay WTRU in an rrc_inactive state). The method comprises the following steps:
-receiving (701) an out-of-coverage OoC indication from the remote WTRU indicating OoC of the remote WTRU in a suitable cell;
-receiving (702) a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and
transmitting (703) a recovery request message indicating that paging of the OoC remote WTRU is the reason for recovery.
According to another embodiment, the method 700 may include: after transmitting a recovery request message indicating that paging of the OoC remote WTRU is the cause of recovery, the paging message is forwarded on the side link SL using the resource allocation set in the recovery message on condition that the recovery message is received from the network.
According to another embodiment, the method 700 may include: after transmitting a resume request message indicating that paging of the OoC remote WTRU is the reason for resume, the paging message is discarded on the condition that a reject/release is received from the network.
In accordance with an embodiment, a relay wireless transmit/receive unit (WTRU) is also disclosed, the relay WTRU comprising a circuit including a receiver, a transmitter, and at least one processor, the relay WTRU being INACTIVE (e.g., in an rrc_inactive state), and the circuit being configured to: receiving an out-of-coverage OoC indication from the remote WTRU indicating that the remote WTRU is OoC in a suitable cell; receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by a relay WTRU; and transmitting a recovery request message indicating that paging of the OoC remote WTRU is the reason for recovery.
According to another embodiment of the relay WTRU, the circuitry is further configured to: after transmitting a recovery request message indicating that paging of the OoC remote WTRU is the cause of recovery, the paging message is forwarded on the side link SL using the resource allocation set in the recovery message on condition that the recovery message is received from the network.
According to another embodiment of the relay WTRU, the circuitry is further configured to: after transmitting a resume request message indicating that paging of the OoC remote WTRU is the reason for resume, the paging message is discarded on the condition that a reject/release is received from the network.
Conclusion(s)
Although not explicitly described, embodiments of the invention may be employed in any combination or sub-combination. For example, the principles of the invention are not limited to the described variations and any arrangement of variations and embodiments may be used. Furthermore, the principles of the present invention are not limited to the described channel access methods, and any other type of channel access method with different priority levels is compatible with the principles of the present invention.
Moreover, any feature, variation, or embodiment described for a method is compatible with: an apparatus comprising means for processing elements of the disclosed methods, an apparatus comprising a processor configured to process the disclosed methods, a computer program product comprising program code instructions, and a non-transitory computer readable storage medium storing program instructions.
Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for the WTRU 102, WTRU, terminal, base station, RNC, or any host computer.
Furthermore, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.
Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit. It should be understood that the representative embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.
The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the above-described memories, and that other platforms and memories may support the described methods.
In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of the mobile unit, the network element, and/or any other computing device.
There is little distinction between hardware implementations and software implementations of aspects of the system. The use of hardware or software is typically (e.g., but not always, because in some contexts the choice between hardware and software may become important) a design choice representing a tradeoff between cost and efficiency. There may be various media (e.g., hardware, software, and/or firmware) that may implement the processes and/or systems and/or other techniques described herein, and the preferred media may vary with the context in which the processes and/or systems and/or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a medium of mainly hardware and/or firmware. If flexibility is paramount, the implementer may opt for a particular implementation of mainly software. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.
The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Where such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.
Although features and elements are provided above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the application, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the application unless explicitly described as such. Functionally equivalent methods and apparatus, other than those enumerated herein, which are within the scope of the present disclosure, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.
It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "WTRU" may mean, as referred to herein: (i) A wireless transmit and/or receive unit, such as described below; (ii) Any of several embodiments of the WTRU, such as those described below; (iii) Devices with wireless capabilities and/or with wired capabilities (e.g., tethered) are configured with some or all of the structure and functionality of a WTRU, in particular, such as described below; (iii) A wireless-capable and/or wireline-capable device may be configured with less than all of the structure and functionality of a WTRU, such as described below; or (iv) etc. Details of an exemplary WTRU that may represent any of the WTRUs described herein are provided below with respect to fig. 1A-1D.
In certain representative implementations, portions of the subject matter described herein can be implemented via an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), and/or other integrated format. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media such as digital and/or analog communication media (e.g., fiber optic cable, waveguide, wired communications link, wireless communication link, etc.).
The subject matter described herein sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, physically mateable and/or physically interactable components and/or wirelessly interactable components and/or logically interactable components.
With respect to substantially any plural and/or singular terms used herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly listed herein.
It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will be further understood by those with skill in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the following appended claims and/or the description herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation object by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation object to embodiments containing only one such recitation object. Even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations).
In addition, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). It should also be understood by those within the art that virtually any separate word and/or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B". In addition, as used herein, the term "…" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" or "group" is intended to include any number of items, including zero. In addition, as used herein, the term "number" is intended to include any number, including zero.
Additionally, where features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will recognize thereby that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.
As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as sufficiently descriptive and so that the same range can be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, and the like. As will also be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc., include the recited numbers and refer to ranges that may be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the scope includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, or the like.
Furthermore, the claims should not be read as limited to the order or elements provided, unless stated to that effect. In addition, use of the term "means for …" in any claim is intended to invoke 35U.S. C. ≡112,6 or suitThe format of the claims plus functions is set forth and any claims without the term "means for …" are not intended to be so.
A processor associated with the software may be used to implement the use of a radio frequency transceiver in a Wireless Transmit Receive Unit (WTRU), a User Equipment (UE), a terminal, a base station, a Mobility Management Entity (MME) or an Evolved Packet Core (EPC) or any host. The WTRU may be used in combination with a module, and may be implemented in hardware and/or software including: software Defined Radio (SDR) and other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, and the like,A module, a Frequency Modulation (FM) radio unit, a Near Field Communication (NFC) module, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.
Although the present invention has been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.
In addition, while the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.
Throughout this disclosure, those skilled in the art will appreciate that certain representative embodiments can be used in alternative forms or in combination with other representative embodiments.
Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.
Furthermore, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.
Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit.
The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the above-described memories, and that other platforms and memories may support the described methods.
Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.
Although the present invention has been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer. In addition, while the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.
Claims (14)
1. A method (600) for processing paging messages, the method being implemented by an inactive relay wireless receive transmit unit, WTRU, and the method comprising:
Receiving (601) an in-coverage IC indication from a remote WTRU, the IC indication indicating an IC of the remote WTRU in a suitable cell;
receiving (602) a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and
forwarding (503) the paging message on a side link SL and instructing the remote WTRU to trigger a radio resource control, RRC, connection via Uu on a condition that the channel busy ratio, CBR, is above a threshold.
2. The method of claim 1, further comprising: and transmitting a resume request message indicating that paging of the IC remote WTRU is a cause of resume on condition that the CBR is not above the threshold.
3. The method of claim 2, further comprising: after the transmission of the resume request message indicating that paging of the IC remote WTRU is the reason for resume,
on receipt of a resume message from the network:
the relay WTRU is switched to connected and forwards the paging message on SL using the resource allocation contained in the resume message.
4. The method of claim 2, further comprising: after the transmission of the resume request message indicating that paging of the IC remote WTRU is the reason for resume,
On receipt of a reject/release message from the network:
keep the relay WTRU inactive, forward the paging message, and instruct the remote WTRU to trigger an RRC connection via Uu.
5. A method (700) for processing paging messages, the method being implemented by an inactive relay wireless receive transmit unit, WTRU, the method comprising:
receiving (701) an out-of-coverage OoC indication from a remote WTRU, the OoC indication indicating OoC of the remote WTRU in a suitable cell;
receiving (702) a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and
a recovery request message is transmitted (703) indicating that paging of the OoC remote WTRU is the reason for recovery.
6. The method of claim 5, further comprising: after the transmission of the resume request message indicating that paging of the OoC remote WTRU is the reason for resume,
the paging message is forwarded on a side link SL using the resource allocation set in the recovery message on condition that the recovery message is received from the network.
7. The method of claim 5, further comprising: after the transmission of the resume request message indicating that paging of the OoC remote WTRU is the reason for resume,
The paging message is discarded on receipt of a reject/release from the network.
8. A relay wireless transmit/receive unit, WTRU, the relay WTRU comprising circuitry including a receiver, a transmitter, and at least one processor, the relay WTRU being inactive and the circuitry being configured to:
receiving an in-coverage IC indication from a remote WTRU, the IC indication indicating that the remote WTRU is in an IC of a suitable cell;
receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU;
the paging message is forwarded on a side link SL on a channel busy ratio CBR above a threshold and the remote WTRU is instructed to trigger a radio resource control, RRC, connection via Uu.
9. The relay WTRU of claim 8, the circuitry further configured to:
and transmitting a resume request message indicating that paging of the IC remote WTRU is a cause of resume on condition that the CBR is not above the threshold.
10. The relay WTRU of claim 9, the circuitry further configured to: after the transmission of the resume request message indicating that paging of the IC remote WTRU is the reason for resume,
On receipt of a recovery message from the network:
the relay WTRU is switched to connected and forwards the paging message on SL using the resource allocation contained in the resume message.
11. The relay WTRU of claim 9, the circuitry further configured to: after the transmission of the resume message indicating that paging of the IC remote WTRU is the reason for resume, on receipt of a reject/release message from the network:
keep the relay WTRU inactive, forward and indicate the paging message to the remote WTRU to trigger an RRC connection via Uu.
12. A relay wireless transmit/receive unit, WTRU, the relay WTRU comprising circuitry including a receiver, a transmitter, and at least one processor, the relay WTRU being inactive and the circuitry being configured to:
receiving an out-of-coverage OoC indication from a remote WTRU, the OoC indication indicating OoC of the remote WTRU in a suitable cell;
receiving a paging message intended for a remote WTRU of a group of remote WTRUs handled by the relay WTRU; and
a resume request message is transmitted indicating that paging of the OoC remote WTRU is the reason for resume.
13. The relay WTRU of claim 12, the circuitry further configured to: after the transmission of the resume request message indicating that paging of the OoC remote WTRU is the reason for resume:
The paging message is forwarded on a side link SL using the resource allocation set in the recovery message on condition that the recovery message is received from the network.
14. The relay WTRU of claim 12, the circuitry further configured to: after the transmission of the resume request message indicating that paging of the OoC remote WTRU is the reason for resume:
the paging message is discarded on receipt of a reject/release from the network.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311324936.5A CN117641620A (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US63/091,488 | 2020-10-14 | ||
| US202163136430P | 2021-01-12 | 2021-01-12 | |
| US63/136,430 | 2021-01-12 | ||
| PCT/US2021/054811 WO2022081730A1 (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay wtru may indeed serve a network-initiated connection at a remote served wtru |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311324936.5A Division CN117641620A (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116686390A true CN116686390A (en) | 2023-09-01 |
Family
ID=87784133
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202180080333.8A Pending CN116686390A (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU |
| CN202311324936.5A Pending CN117641620A (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311324936.5A Pending CN117641620A (en) | 2020-10-14 | 2021-10-13 | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN116686390A (en) |
-
2021
- 2021-10-13 CN CN202180080333.8A patent/CN116686390A/en active Pending
- 2021-10-13 CN CN202311324936.5A patent/CN117641620A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CN117641620A (en) | 2024-03-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112840733B (en) | Method for resource reservation in vehicle communication | |
| CN111587589B (en) | Method for enhancing protocol in 5G NAS | |
| CN115553058A (en) | Establishment and configuration of device-to-device relay connections | |
| WO2017196611A1 (en) | Devices and methods for power efficient d2d communications for wearables/iot | |
| US20230097552A1 (en) | Method and apparatus for performing simultaneous sidelink discontinuous (drx) and uplink drx in new radio (nr) vehicle to everything (v2x) | |
| CN113039833A (en) | Uplink-based forward mobility | |
| CN113647134A (en) | Congestion control procedure for PC5 communications | |
| CN117202301A (en) | Method and apparatus for link management and recovery for side link relay | |
| JP2023524387A (en) | NR V2X sidelink power saving for unicast and/or groupcast | |
| JP2023537491A (en) | NR relay method to support latency reduction for SL relay | |
| CN115918248A (en) | Methods and apparatus for non-access stratum procedures related to layer 2 relays | |
| CN116830657A (en) | Modifying measurement reporting behavior at a remote WTRU based on a link quality indication associated with a link between a relay WTRU and a network | |
| JP2022551599A (en) | Device-to-device discovery via relay devices | |
| CN116848889A (en) | Method for relay measurement | |
| CN117957863A (en) | WTRU-to-network relay associated with MINT | |
| JP2023537490A (en) | Sidelink discovery associated with NR relays | |
| US20240098815A1 (en) | Determining whether an inactive relay wtru may indeed serve a network-initiated connection at a remote served wtru | |
| CN116686390A (en) | Determining whether an inactive relay WTRU is actually capable of providing network-initiated connection service for a served remote WTRU | |
| US20240163934A1 (en) | Method for efficient paging for user equipment to network relays | |
| CN118020346A (en) | Method, architecture, apparatus and system for connection establishment and configuration for multi-hop relay | |
| CN117204112A (en) | Method for efficient paging of user equipment to network relay | |
| CN117917131A (en) | RLF and recovery associated with multi-hop and multi-connection relay | |
| WO2023154366A1 (en) | Paging acquisition in multipath wtru to network relays | |
| CN117897988A (en) | Side link relay cell reselection or handover and measurement | |
| CN117751679A (en) | Transitions associated with deactivated secondary cell groups |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |