Patent Application
20220141756
This disclosure generally relates to wireless communication networks, and more particularly, to a method and apparatus for system information acquisition via UE-to-Network relay in a wireless communication system.
With the rapid rise in demand for communication of large amounts of data to and from mobile communication devices, traditional mobile voice communication networks are evolving into networks that communicate with Internet Protocol (IP) data packets. Such IP data packet communication can provide users of mobile communication devices with voice over IP, multimedia, multicast and on-demand communication services.
An exemplary network structure is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput in order to realize the above-noted voice over IP and multimedia services. A new radio technology for the next generation (e.g., 5G) is currently being discussed by the 3GPP standards organization. Accordingly, changes to the current body of 3GPP standard are currently being submitted and considered to evolve and finalize the 3GPP standard.
A method and device are disclosed for a remote User Equipment (UE) to receive system information. In one embodiment, the method includes the remote UE receiving a system information from a network node via a relay UE, wherein a sidelink transmission of the system information is sent with a common Layer-2 Identity (ID) as Destination Layer-2 ID and a Layer-2 ID of the relay UE as Source Layer-2 ID, and wherein the common Layer-2 ID is associated with a purpose of delivering or forwarding the system information from the network node.
The exemplary wireless communication systems and devices described below employ a wireless communication system, supporting a broadcast service. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP LTE (Long Term Evolution) wireless access, 3GPP LTE-A or LTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra Mobile Broadband), WiMax, 3GPP NR (New Radio), or some other modulation techniques.
In particular, the exemplary wireless communication systems and devices described below may be designed to support one or more standards such as the standard offered by a consortium named “3rd Generation Partnership Project” referred to herein as 3GPP, including: TS 38.331 V16.2.0, “NR; Radio Resource Control (RRC) protocol specification (Release 16)”; TS 38.300 V16.1.0, “NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)”; TR 23.752 V0.5.1, “Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS) (Release 17)”; R2-2008922, “On-demand SI Delivery for Remote UE”, CATT. The standards and documents listed above are hereby expressly incorporated by reference in their entirety.
Each group of antennas and/or the area in which they are designed to communicate is often referred to as a sector of the access network. In the embodiment, antenna groups each are designed to communicate to access terminals in a sector of the areas covered by access network 100.
In communication over forward links 120 and 126, the transmitting antennas of access network 100 may utilize beamforming in order to improve the signal-to-noise ratio of forward links for the different access terminals 116 and 122. Also, an access network using beamforming to transmit to access terminals scattered randomly through its coverage causes less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to all its access terminals.
An access network (AN) may be a fixed station or base station used for communicating with the terminals and may also be referred to as an access point, a Node B, a base station, an enhanced base station, an evolved Node B (eNB), a network node, a network, or some other terminology. An access terminal (AT) may also be called user equipment (UE), a wireless communication device, terminal, access terminal or some other terminology.
In one embodiment, each data stream is transmitted over a respective transmit antenna. TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.
The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions performed by processor 230.
The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 220 then provides NT modulation symbol streams to NT transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.
Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. NT modulated signals from transmitters 222a through 222t are then transmitted from NT antennas 224a through 224t, respectively.
At receiver system 250, the transmitted modulated signals are received by NR antennas 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.
An RX data processor 260 then receives and processes the NR received symbol streams from NR receivers 254 based on a particular receiver processing technique to provide NT“detected” symbol streams. The RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 260 is complementary to that performed by TX MIMO processor 220 and TX data processor 214 at transmitter system 210.
A processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.
The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 238, which also receives traffic data for a number of data streams from a data source 236, modulated by a modulator 280, conditioned by transmitters 254a through 254r, and transmitted back to transmitter system 210.
At transmitter system 210, the modulated signals from receiver system 250 are received by antennas 224, conditioned by receivers 222, demodulated by a demodulator 240, and processed by a RX data processor 242 to extract the reserve link message transmitted by the receiver system 250. Processor 230 then determines which pre-coding matrix to use for determining the beamforming weights then processes the extracted message.
Turning to
3GPP TS 38.331 introduced the following:
System Information (SI) is divided into the MIB and a number of SIBs and posSIBs where:
[Figure 5.2.2.1-1 of 3GPP TS 38.331 V16.2.0, Entitled “System Information Acquisition” is Reproduced as FIG. 5]
The UE applies the SI acquisition procedure to acquire the AS, NAS- and positioning assistance data information. The procedure applies to UEs in RRC_IDLE, in RRC_INACTIVE and in RRC_CONNECTED.
The UE in RRC_IDLE and RRC_INACTIVE shall ensure having a valid version of (at least) the MIB, SIB1 through SIB4, SIB5 (if the UE supports E-UTRA), SIB11 (if the UE is configured for idle/inactive measurements), SIB12 (if UE is capable of NR sidelink communication and is configured by upper layers to receive or transmit NR sidelink communication), and SIB13, SIB14 (if UE is capable of V2X sidelink communication and is configured by upper layers to receive or transmit V2X sidelink communication).
The UE shall apply the SI acquisition procedure as defined in clause 5.2.2.3 upon cell selection (e.g. upon power on), cell-reselection, return from out of coverage, after reconfiguration with sync completion, after entering the network from another RAT, upon receiving an indication that the system information has changed, upon receiving a PWS notification, upon receiving request (e.g., a positioning request) from upper layers; and whenever the UE does not have a valid version of a stored SIB or posSIB or a valid version of a requested SIB.
When the UE acquires a MIB or a SIB1 or an SI message in a serving cell as described in clause 5.2.2.3, and if the UE stores the acquired SIB, then the UE shall store the associated areaScope, if present, the first PLMN-Identity in the PLMN-IdentityInfoList for non-NPN-only cells or the first NPN identity (SNPN identity in case of SNPN, or PNI-NPN identity in case of PNI-NPN) in the NPN-IdentityInfoList for NPN-only cells, the cellIdentity, the systemInformationAreaID, if present, and the valueTag, if present, as indicated in the si-SchedulingInfo for the SIB. The UE may use a valid stored version of the SI except MIB, SIB1, SIB6, SIB7 or SIB8 e.g. after cell re-selection, upon return from out of coverage or after the reception of SI change indication. The value tag for posSIB is optionally provided in LPP signalling [49].
The UE shall:
A modification period is used, i.e. updated SI message (other than SI message for ETWS, CMAS and positioning assistance data) is broadcasted in the modification period following the one where SI change indication is transmitted. The modification period boundaries are defined by SFN values for which SFN mod m=0, where m is the number of radio frames comprising the modification period. The modification period is configured by system information. The UE receives indications about SI modifications and/or PWS notifications using Short Message transmitted with P-RNTI over DCI (see clause 6.5). Repetitions of SI change indication may occur within preceding modification period. SI change indication is not applicable for SI messages containing posSIBs.
UEs in RRC_IDLE or in RRC_INACTIVE shall monitor for SI change indication in its own paging occasion every DRX cycle. UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13. ETWS or CMAS capable UEs in RRC_IDLE or in RRC_INACTIVE shall monitor for indications about PWS notification in its own paging occasion every DRX cycle. ETWS or CMAS capable UEs in RRC_CONNECTED shall monitor for indication about PWS notification in any paging occasion at least once every defaultPagingCycle if the UE is provided with common search space on the active BWP to monitor paging.
For Short Message reception in a paging occasion, the UE monitors the PDCCH monitoring occasion(s) for paging as specified in TS 38.304 [20] and TS 38.213 [13].
If the UE receives a Short Message, the UE shall:
The UE shall:
Upon receiving the MIB the UE shall:
Upon receiving the SIB1 the UE shall:
The UE shall:
[Figure 5.3.5.1-1 of 3GPP TS 38.331 V16.2.0, Entitled “RRC Reconfiguration, Successful”, is Reproduced as
[ . . . ]
The UE shall perform the following actions upon reception of the RRCReconfiguration, or upon execution of the conditional reconfiguration (CHO or CPC):
[ . . . ]
[ . . . ]
UL-CCCH-Message
The UL-CCCH-Message class is the set of 48-bits RRC messages that may be sent from the UE to the Network on the uplink CCCH logical channel.
UL-DCCH-Message
The UL-DCCH-Message class is the set of RRC messages that may be sent from the UE to the network on the uplink DCCH logical channel.
BCCH-BCH-Message
The BCCH-BCH-Message class is the set of RRC messages that may be sent from the network to the UE via BCH on the BCCH logical channel.
BCCH-DL-SCH-Message
The BCCH-DL-SCH-Message class is the set of RRC messages that may be sent from the network to the UE via DL-SCH on the BCCH logical channel.
[ . . . ]
RRCSystemInfoRequest
The RRCSystemInfoRequest message is used to request SI message(s) required by the UE as specified in clause 5.2.2.3.3.
DedicatedSIBRequest
The DedicatedSIBRequest message is used to request SIB(s) required by the UE in RRC_CONNECTED as specified in clause 5.2.2.3.5.
RRCReconfiguration
The RRCReconfiguration message is the command to modify an RRC connection. It may convey information for measurement configuration, mobility control, radio resource configuration (including RBs, MAC main configuration and physical channel configuration) and AS security configuration.
SystemInformation
The SystemInformation message is used to convey one or more System Information Blocks or Positioning System Information Blocks. All the SIB8 or posSIBs included are transmitted with the same periodicity.
3GPP TS 38.300 introduced the following:
System Information (SI) consists of a MIB and a number of SIBs, which are divided into Minimum SI and Other SI:
Figure 7.3-1 below summarises System Information provisioning.
[Figure 7.3-1 of 3GPP TS 38.300 V16.1.0, entitled “System Information Provisioning”, is reproduced as
For a cell/frequency that is considered for camping by the UE, the UE is not required to acquire the contents of the minimum SI of that cell/frequency from another cell/frequency layer. This does not preclude the case that the UE applies stored SI from previously visited cell(s).
If the UE cannot determine the full contents of the minimum SI of a cell by receiving from that cell, the UE shall consider that cell as barred.
In case of BA, the UE only acquires SI on the active BWP.
The MIB is mapped on the BCCH and carried on BCH while all other SI messages are mapped on the BCCH, where they are dynamically carried on DL-SCH. The scheduling of SI messages part of Other SI is indicated by SIB1.
For UEs in RRC_IDLE and RRC_INACTIVE, a request for Other SI triggers a random access procedure (see clause 9.2.6) where MSG3 includes the SI request message unless the requested SI is associated to a subset of the PRACH resources, in which case MSG1 is used for indication of the requested Other SI. When MSG1 is used, the minimum granularity of the request is one SI message (i.e. a set of SIBs), one RACH preamble and/or PRACH resource can be used to request multiple SI messages and the gNB acknowledges the request in MSG2. When MSG 3 is used, the gNB acknowledges the request in MSG4.
For UEs in RRC_CONNECTED, a request for Other SI may be sent to the network in a dedicated manner (i.e., via UL-DCCH) and the granularity of the request is one SIB. The gNB may respond with an RRCReconfiguration including the requested SIB(s). It is a network choice to decide which requested SIBs are delivered in a dedicated or broadcasted manner.
The Other SI may be broadcast at a configurable periodicity and for a certain duration. The Other SI may also be broadcast when it is requested by UE in RRC_IDLE/RRC_INACTIVE.
For a UE to be allowed to camp on a cell it must have acquired the contents of the Minimum SI from that cell. There may be cells in the system that do not broadcast the Minimum SI and where the UE therefore cannot camp.
Change of system information (other than for ETWS/CMAS, see clause 16.4) only occurs at specific radio frames, i.e. the concept of a modification period is used. System information may be transmitted a number of times with the same content within a modification period, as defined by its scheduling. The modification period is configured by system information.
When the network changes (some of the) system information, it first notifies the UEs about this change, i.e. this may be done throughout a modification period. In the next modification period, the network transmits the updated system information. Upon receiving a change notification, the UE acquires the new system information from the start of the next modification period. The UE applies the previously acquired system information until the UE acquires the new system information.
3GPP TR 23.752 introduced the following:
The solution addresses the following aspect highlighted in key issue #3 (Support UE-to-Network Relay UE):
The solution proposes a protocol architecture to support a Layer 2 UE-to-Network Relay UE (see Annex A).
This solution works only for NR/5GC network relays. It does not apply when the UE-to-Network Relay UE is out of coverage of NR/5GC.
In this clause, the protocol architecture supporting a L2 UE-to-Network Relay UE is provided. The L2 UE-to-Network Relay UE provides forwarding functionality that can relay any type of traffic over the PC5 link.
The L2 UE-to-Network Relay UE provides the functionality to support connectivity to the 5GS for Remote UEs. A UE is considered to be a Remote UE if it has successfully established a PC5 link to the L2 UE-to-Network Relay UE. A Remote UE can be located within NG-RAN coverage or outside of NG-RAN coverage.
The control and user plane protocols stacks are based on the architectural reference model described in Annex A.
Network selection comprises PLMN selection and access network selection. Access network selection for a Remote UE comprises UE-to-Network relay discovery and selection. The Remote UE performs PLMN selection in accordance with the PLMN selected by the UE-to-Network Relay. The Relay UE provides serving PLMN information and other PLMNs information in System Information to the Remote UE in order to perform PLMN selection during discovery.
The Remote UE and UE-to-Network Relay UE are by definition served by the same NG-RAN.
In order to enable a (Remote) UE out of coverage to gain connectivity to the network, it is important to allow such UE by means of (pre)configuration to discover potential UE-to-Network Relay UEs through which it could gain access to the 5GS. To do so:
Parameters for UE-to-Network Relay UE discovery and for communication over NR PC5 may be made available to the Remote UE as follows:
It is also important that a UE be authorized to operate as a UE-to-Network Relay UE. A UE may only operate as a UE-to-Network Relay UE when served by the network.
Parameters for a UE to operate as a UE-to-Network Relay UE, for discovery of Remote UEs over NR PC5 and for communication over NR PC5 may be made available to the UE as follows:
It should be possible for the HPLMN PCF to provide authorization for a UE to operate as a Remote UE or as a UE-to-Network Relay UE on a per PLMN basis. It should also be possible for the Serving PLMN to provide/revoke such authorization in which case it shall override any corresponding information provided by the HPLMN.
PCF based service authorization and provisioning solution for Layer-2 UE-to-Network Relay could reuse Solution #35.
Registration Management for the UE-to-Network Relay UE follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8]. The UE-to-Network Relay is served by a first AMF.
Registration Management for the Remote UE follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8]. The Remote UE is served by a second AMF that may or may not be the same as the first AMF.
Connection Management for the UE-to-Network Relay UE follows at least the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8].
Connection Management for the Remote UE follows the principles and procedures defined in TS 23.501 [6] and TS 23.502 [8].
The UE-to-Network Relay may only relay data/signaling for the Remote UE(s) when the UE-to-Network Relay is in CM-CONNECTED/RRC Connected states. If the UE-to-Network Relay in CM_IDLE state receives the PC5 connection request from the Remote UE for relay, the UE-to-Network Relay shall trigger Service Request procedure to enter CM_CONNECTED state before relaying the signalling.
When Remote UE is CM-IDLE or CM-CONNECTED, Relay UE and Remote UE keeps the PC5 link. For paging Remote UE, the concluded solution in clause 6.6.2 of TR 23.733 [26] can be reused based on the assumption that option 2 of TR 36.746 [27] is adopted by RAN WG2.
The UE-to-Network Relay may experience NAS level congestion control, as specified in clause 5.19.7 of TS 23.501 [6].
When NAS Mobility Management congestion control is activated, i.e. the UE-to-Network Relay receives Mobility Management back-off timer from the AMF, the UE-to-Network Relay is not able to properly serve the Remote UE after the UE-to-Network Relay enters CM_IDLE state. In that case, the UE-to-Network Relay needs to inform the Remote UE that there is a Mobility Management back-off timer running at the UE-to-Network Relay, so that the Remote UE is able to (re)select to another UE-to-Network Relay.
The Remote UE may also subject to NAS level congestion control. The existing behavior defined in TS 23.501 [6] shall apply.
As shown in Annex A, the NAS endpoints between a Remote UE and the network are as currently specified such that the operation via a UE-to-Network Relay UE should be transparent to the network NAS, with the exception of authorization/provisioning identified in clause 6.7.2.4.
This means that the 5GS flow-based QoS concept in particular should be reused between the Remote UE and the network, with necessary adaptation over the radio interface i.e. PC5 (for the Remote UE and UE-to-Network Relay UE) and Uu (for the UE-to-Network Relay UE). RAN performs QoS enforcement for PC5 interface and Uu interfaces when it gets QoS profile from the CN. For example, RAN performs QoS enforcement with AS layer configuration with necessary adaptation over PC5 interface and Uu interface. In other words, QoS flows established between the network and the Remote UE will be mapped to PC5 “radio bearers” seen by the Remote UE and to normal Uu radio bearers seen by the network, whereby the UE-to-Network Relay UE performs the necessary adaptation between Uu and PC5.
The Remote UE is expected to operate within the boundaries of the Mobility Restrictions applicable to the UE to Network Relay UE.
Mobility restriction in CM-IDLE state is executed by the UE based on the information received from the network. For the UE-to-Network Relay case, the Remote UE may not obtain the mobility restrictions related information if Remote UE is out of coverage. The Remote UE can get the mobility restrictions related information, e.g., tracking area, from the Relay UE, and the Remote UE itself performs network selection and access control in CM_IDLE state based on the received information.
Forbidden Area:
Mobility of a Remote UE within an NG-RAN node will be handled by the NG-RAN and the UE-to-Network Relay, allowing the Remote UE to maintain service when changing from a direct network connection to an indirect network connection (i.e. via L2 UE-to-Network Relay UE) and vice-versa without 5GC involvement.
[Figure 6.7.2.6-1 of 3GPP TR 23.752 V0.5.1, Entitled “Intra-NG-RAN Mobility (No 5GC Involvement)”, is Reproduced as
Inter-NG-RAN mobility is depicted below. Mobility is expected to be possible with no impact on NAS and most impact on lower layers i.e. RAN WG2.
[Figure 6.7.2.6-2 of 3GPP TR 23.752 V0.5.1, Entitled “Inter-NG-RAN Mobility”, is Reproduced as
Security (confidentiality and integrity protection) is enforced at the PDCP layer between the endpoints at the Remote UE and the gNB. The PDCP traffic is relayed securely over two links, one between the Remote UE and the UE-to-Network Relay UE and the other between the UE-to-Network Relay UE to the gNB without exposing any of the Remote UE's plaintext data to the UE-to-Network Relay.
UP integrity protection is separated for direct PC5 communication and indirect communication.
For indirect communication, the NG-RAN and Remote UE are the nodes that enforce the UP integrity protection for data transmission between NG-RAN and Remote UE.
For direct PC5 communication, the UE-to-Network Relay UE and Remote UE are the nodes that enforce the UP integrity protection for data transmission between UE-to-Network Relay UE and Remote UE.
Model A and Model B can be applied for Layer-2 UE-to-Network Relay discovery. The detailed UE-to-Network Relay discovery and selection solution for Layer-2 UE-to-Network Relay could reuse Solution #19, with the difference that slicing and DNN information do not need to be considered. In addition, mobility restrictions related information such as CAG cell and TA may to be included in the discovery message.
For initial access, Remote UE may perform communication path selection between direct Uu path and indirect Uu path based on the link quality and the configured threshold (pre-configured or provided by NG-RAN). For example, if Uu link quality exceeds configured threshold, the direct Uu path is selected. Otherwise, the indirect Uu path is selected by performing the UE-to-Network Relay discovery and selection.
For path switch case, NG-RAN may perform communication path selection based on the signal level/quality of different paths, which may be based on the path switch solution.
[Figure 6.7.3-1 of 3GPP TR 23.752 V0.5.1, Entitled “Connection Establishment for Indirect Communication Via UE-to-Network Relay UE”, is Reproduced as
If Remote UE has not performed the Initial Registration, the Remote UE can perform the Initial Registration via the Indirect Network Communication in step 7.
For details of UE-to-Network Relay discovery and selection for Layer-2 UE-to-Network Relay see clause 6.7.2.9 and Solution #19, Solution #41.
How to keep the Relay UE in CM_CONNECTED state is proposed in the clause 6.7.2.5.2.
The solution has impacts in the following entities:
3GPP R2-2008922 introduced the following:
After RAN2#111-e meeting, the long email discussion “[Post111-e][627][Relay] Remaining issues on L2 architecture” was discussed [1]. The proposals of on-demand SI delivery for Remote UE were as below:
In this contribution, we discuss on-demand SI delivery principles for Remote UE.
In [1], on-demand SI principles for remote UE are proposed as below:
In Uu interface, UE supports on-demand SI for all RRC states. The remote UE accesses to network via U2N relay should be treated as a normal UE as much as possible. Therefore, the first principle is reasonable.
Although when the remote UE is in coverage, it can acquire the SI from gNB directly. However, the remote UE and the relay UE may be in different cells. The remote UE can acquire the SIBs of the relay UE's serving cell via on-demand SI manner. Besides this case, on-demand SI for remote UE can also be used for OOC remote UE. Therefore, the fourth principle is reasonable.
For the second and third principles, they should be discussed further.
The Uu on-demand SI procedures for RRC_Connected and for Idle/Inactive states are different. Hence, on-demand SI principles for remote UE should be discussed for RRC_Connected and for Idle/Inactive separately.
In rel-16, the on-demand SI procedure in RRC_Connected is supported. The dedicatedSIBRequest message is introduced to request SIB(s) required by the UE in RRC_Connected. Upon receiving the on-demand SIB request by the UE, the network responds with either an RRCReconfiguration message that includes the requested SIBs (if these are send via dedicated signalling) or broadcast. For the case that the network responds with an RRCReconfiguration message, the on-demand SI procedure in RRC_Connected can be reused for connected remote UE. If the network responds with broadcast, the situation is similar to Idle/Inactive remote UE.
Proposal 1: For Connected remote UE, on-demand SI in RRC_Connected that both SIB request and respond via dedicated signaling can be reused.
For Idle/Inactive remote UE, both Msg1 and Msg3 based on-demand SI can't work.
For Msg1 based on-demand SI, since Uu preamble of remote UE can't be relayed, it can't be used for remote UE.
For Msg3 based on-demand SI, it also can't be used for remote UE, even though RRCSystemInfoRequest message of the remote UE can be relayed to gNB using the same scheme as the first RRC message for connection establishment from Remote UE with gNB. The reasons are as below:
Whether the relay UE needs to request the SI/SIB(s) requested by the remote UE from gNB depending on whether the relay UE has stored a valid version of the SI/SIB(s) requested by remote UE. If the relay UE has stored a valid version of the SI/SIB(s), it can directly forward it to the remote UE; otherwise, the relay UE can request the SI/SIB(s) from the gNB using legacy Uu procedure and then forward it to the remote UE. How to transmit the SI/SIB(s) on PC5 can be further discussed in WI phase.
Proposal 4: Relay UE acquires SI/SIB from the gNB using legacy Uu procedure.
The on-demand SI principles for remote UE can be summarized in proposal 5.
Proposal 5: on-demand SI principles for remote UE are as below:
In 3GPP TS 38.331 and TS 38.300, system information acquisition related procedure(s) and handling were introduced. Accordingly, a UE shall apply the System Information (SI) acquisition procedure as defined in 3GPP TS 38.331 upon cell selection (e.g. upon power on) or cell-reselection, return from out of coverage, after reconfiguration with sync completion, after entering the network from another Radio Access Technology (RAT), upon receiving an indication that the system information has changed, upon receiving a Public Warning System (PWS) notification, upon receiving request (e.g., a positioning request) from upper layers, and whenever the UE does not have a valid version of a stored System Information Block (SIB) or posSIB or a valid version of a requested SIB. On the other hand, when the UE acquires a MIB or a SIB1 or an SI message in a serving cell, and if the UE stores the acquired SIB, then the UE shall store the associated areaScope, the first PLMN-Identity, the cellIdentity, the systemInformationAreaID, and/or the valueTag for the SIB. Basically, the UE could check if a stored SIB is valid or not based on whether the first PLMN-Identity, the systemInformationAreaID, the cellIdentity and/or the valueTag for the SIB received from the serving cell are identical to the PLMN-Identity, the systemInformationAreaID, the cellIdentity and/or the valueTag associated with the stored version of that SIB. These parameters related to sidelink communication could be carried in e.g. SIB12.
According to 3GPP TR 23.752 and R2-2008922, forwarding system information received from the serving cell of a Relay UE to a Remote UE (in RRC_IDLE or RRC_INACTIVE) could be supported in UE-to-Network relay communication. Thus, the step flow used for acquiring system information of a cell via a Relay UE locating at the cell could be considered and illustrated in
Step 1. A Remote UE could find one or more Relay UEs based on received discovery messages sent by these found Relay UEs. And then, the Remote UE could select a Relay UE based on a relay UE selection criteria or procedure.
Step 2. Basically, each Relay UE could (periodically) broadcast the minimum SI (stored in this Relay UE) of the cell serving this Relay UE. The minimum SI could be sent via e.g. a PC5 RRC message. And then, the Remote UE could perform a SI acquisition procedure in order to acquire Minimum SI from the selected Relay UE. The Remote UE's lower layers could use a Layer-2 ID of the selected Relay UE as Source (Layer-2 or Layer-1) ID to monitor a sidelink control information used for scheduling a sidelink reception including Minimum SI of the selected Relay UE. The Remote UE's lower layers could use a common Layer-2 ID as Destination (Layer-2 or Layer-1) ID to monitor the sidelink control information used for scheduling a sidelink reception including Minimum SI of the selected Relay UE. The Remote UE could then receive a minimum SI forwarded by the selected Relay UE. The Remote UE could then store the minimum SI. The Layer-2 ID of the Relay UE could be found in the discovery message of the Relay UE. The Layer-2 ID of the Relay UE (or partial of the Layer-2 ID of the Relay UE, i.e. Layer-1 ID) could be used as a Source (Layer-2 or Layer-1) ID for sending/receiving the minimum SI. The common Layer-2 ID (or partial of the common Layer-2 ID, i.e. Layer-1 ID) could be used as a Destination (Layer-2 or Layer-1) ID for sending/receiving the minimum SI. The common Layer-2 ID could be associated with a purpose of delivering or forwarding system information. The common Layer-2 ID could be preconfigured or specified in the Remote UE and the Relay UE.
Step 3. According to the minimum SI, the Remote UE could send SI request to the Relay UE for acquiring Other SI. The Remote UE could generate a SI request message (e.g. RRCSystemInfoRequest) and deliver this SI request message to lower layer for transmission. Since the SI request message is to be sent to the Relay UE, the SI request message could be sent on a PC5 RLC bearer preconfigured or specified in the Remote UE. The SI request message could be sent based on the Layer-2 ID of the Relay UE (as Destination ID) and a Layer-2 ID of the Remote UE (as Source ID). The SI request message could be sent via e.g. PC5 RRC message. The Remote UE's lower layers could then use the Layer-2 ID of the selected Relay UE as Source (Layer-2 or Layer-1) ID and the Layer-2 ID of the Remote UE as Destination (Layer-2 or Layer-1) ID to monitor a sidelink control information used for scheduling a sidelink reception including Other SI of the selected Relay UE. Alternatively, the Remote UE's lower layers could then use the Layer-2 ID of the selected Relay UE as Source (Layer-2 or Layer-1) ID and the common Layer-2 ID as Destination (Layer-2 or Layer-1) ID to monitor a sidelink control information used for scheduling a sidelink reception including Other SI of the selected Relay UE. And then, the Remote UE could receive SIB(s) or SI message(s) as indicated in the SI request message from the Relay UE via e.g. PC5 RRC message. The Remote UE could then store the SIB(s) or SI message(s). The sidelink reception of the SIB(s) or SI message(s) could be indicated or scheduled by the sidelink control information used for scheduling a sidelink reception including Other SI of the selected Relay UE.
Step 4. Possibly, the Relay UE could receive an indication that the system information has been changed from gNB. Thus, the Relay UE could send or broadcast a sidelink control information used for indicating system information update. The Relay UE's lower layers could use the Layer-2 ID of the Relay UE as Source (Layer-2 or Layer-1) ID and the Layer-2 ID of the Remote UE as Destination (Layer-2 or Layer-1) ID to send the sidelink control information used for indicating system information update. Alternatively, the Relay UE's lower layers could use the Layer-2 ID of the Relay UE as Source (Layer-2 or Layer-1) ID and the common Layer-2 ID as Destination (Layer-2 or Layer-1) ID to send the sidelink control information used for indicating system information update.
Step 5. Similar to Step 2 discussed above, the Relay UE could then (periodically) broadcast the updated minimum SI. The Remote UE could then receive the updated minimum SI from the Relay UE.
Step 6. Similar to Step 3 discussed above, according to the updated minimum SI, the Remote UE could send SI request to the Relay UE for acquiring updated Other SI, if needed; and receive the updated SIB(s) or the updated SI message(s) from the Relay UE, if any.
Since the Remote UE may move, the Remote UE would reselect another Relay UE according to relay UE selection criteria or procedure. It is possible that the new Relay UE's serving cell could be different from the old one's serving cell. This scenario could be illustrated in
Possibly, the system information acquisition procedure specified in 3GPP TS 38.331 could be reused for the Remote UE. However, the Remote UE would not be able to perform the system information acquisition procedure since there is no condition for the Remote UE to trigger the system information acquisition procedure (when the Remote UE has selected the Relay UE but the Remote UE is out-of-coverage). Thus, it would be better for the Remote UE to perform the system information acquisition procedure when the current serving relay UE is changed or reselected.
More specifically, the Remote UE could perform system information acquisition procedure if or when a Relay UE is selected or reselected. The Remote UE could perform system information acquisition procedure upon selection or reselection of a Relay UE. The Remote UE could perform system information acquisition procedure in response to selection or reselection of a Relay UE.
More specifically, within the system information acquisition procedure, the Remote UE could monitor and/or receive a sidelink control information used for scheduling sidelink reception of Minimum SI from the Relay UE. This sidelink control information used for scheduling sidelink reception of Minimum SI could include a field indicating a Layer-2 ID or a Layer-1 ID (i.e. partial of the Layer-2 ID) of the Relay UE (as Source ID). This sidelink control information used for scheduling sidelink reception of Minimum SI could include a field indicating a common Layer-2 ID or a common Layer-1 ID (i.e. partial of the common Layer-2 ID) used for forwarding system information (as Destination ID). This sidelink control information used for scheduling sidelink reception of Minimum SI could include a field indicating the scheduled sidelink reception is for Minimum SI reception.
More specifically, within the system information acquisition procedure, the Remote UE could send a SI request message to the Relay UE. In the SI request message, the Remote UE could indicate which SIB or which SI message (including one or more SIBs) is required. The SI request message could be sent by using the Layer-2 ID or the Layer-1 ID of the Relay UE (as Destination ID). Alternatively, the SI request message could be sent by using the common Layer-2 ID or the common Layer-1 ID used for forwarding system information (as Destination ID). The SI request message could be sent by using the Layer-2 ID or the Layer-1 ID of the Remote UE (as Source ID). The Remote UE could send a sidelink control information used for scheduling sidelink transmission of the SI request message. The sidelink control information used for scheduling sidelink transmission of the SI request message could include a field indicating the Layer-2 ID or the Layer-1 ID of the Relay UE (as Destination ID). Alternatively, the sidelink control information used for scheduling sidelink transmission of the SI request message could include a field indicating the common Layer-2 ID or the common Layer-1 ID used for forwarding system information (as Destination ID). The sidelink control information used for scheduling sidelink transmission of the SI request message could include a field indicating the Layer-2 ID or the Layer-1 ID of the Remote UE (as Source ID). This sidelink control information used for scheduling sidelink transmission of the SI request message could include a field indicating the scheduled sidelink transmission is for SI request.
In response to reception of the SI request message, the Relay UE could send a sidelink control information used for scheduling sidelink reception for Other SI to the Remote UE. The sidelink reception for Other SI carries a transport block. The Relay UE could include one or more SIBs as requested by the Remote UE according to the SI request message in the transport block. Alternatively, the Relay UE could include one or more SI messages as requested by the Remote UE according to the SI request message in the transport block.
More specifically, within the system information acquisition procedure, the Remote UE could monitor and/or receive the sidelink control information used for scheduling sidelink reception of Other SI from the Relay UE. This sidelink control information used for scheduling sidelink reception of Other SI could include a field indicating the Layer-2 ID or the Layer-1 ID of the Relay UE (as Source ID). This sidelink control information used for scheduling sidelink reception of Other SI could include a field indicating the Layer-2 ID or the Layer-1 ID of the Remote UE (as Destination ID). Alternatively, this sidelink control information used for scheduling sidelink reception of Other SI could include a field indicating the common Layer-2 ID or the common Layer-1 ID used for forwarding system information (as Destination ID). This sidelink control information used for scheduling sidelink reception of Other SI could include a field indicating the scheduled sidelink reception is for Other SI reception.
More specifically, the sidelink control information used for indicating system information update could include a field indicating the Layer-2 ID or the Layer-1 ID of the Relay UE (as Source ID). The sidelink control information used for indicating system information update could include a field indicating the Layer-2 ID or the Layer-1 ID of the Remote UE (as Destination ID). Alternatively, the sidelink control information used for indicating system information update could include a field indicating the common Layer-2 ID or the common Layer-1 ID used for forwarding system information (as Destination ID). The sidelink control information used for indicating system information update could also include a field indicating the purpose of this sidelink control information is used for system information update.
The following exemplary text proposals for the invention could be proposed for 3GPP TS 38.331:
Text Proposal 1
The UE shall apply the SI acquisition procedure as defined in clause 5.2.2.3 upon relay UE (re-) selection, upon cell selection (e.g. upon power on), cell-reselection, return from out of coverage, after reconfiguration with sync completion, after entering the network from another RAT, upon receiving an indication that the system information has changed, upon receiving a PWS notification, upon receiving request (e.g., a positioning request) from upper layers; and whenever the UE does not have a valid version of a stored SIB or posSIB or a valid version of a requested SIB.
Text Proposal 2
The UE shall apply the SI acquisition procedure as defined in clause 5.2.2.3 upon selecting or reselecting a relay UE (in capable of supporting SI delivery), upon cell selection (e.g. upon power on), cell-reselection, return from out of coverage, after reconfiguration with sync completion, after entering the network from another RAT, upon receiving an indication that the system information has changed, upon receiving a PWS notification, upon receiving request (e.g., a positioning request) from upper layers; and whenever the UE does not have a valid version of a stored SIB or posSIB or a valid version of a requested SIB.
According to 3GPP R2-2008922, on-demand SI delivery could be supported for Relay UE and Remote UE they are in different cells. Different cells could belong to different areas. It is possible that the Remote UE could locate at a first cell (belonging to a system information area) and the Relay UE could locate at a second cell (belonging to the system information area or another system information area). It is supposed that the Remote UE firstly camps on the first cell and then selects the Relay UE later. This scenario could be illustrated in
According to 3GPP TS 38.331, the system information acquisition procedure would be triggered upon receiving an indication that the system information has changed. In this case, the Remote UE will be triggered to perform a system information acquisition procedure to acquire system information from the first cell that is not necessary since the Remote UE has already selected the Relay UE for acquiring system information (of the second cell). Therefore, to address this situation, it is proposed that the Remote UE could determine whether to perform a system information acquisition procedure for acquiring system information from a cell based on whether the Remote UE has selected a Relay UE (for acquiring system information from this Relay UE), upon receiving an indication about system information update from the cell. If the Remote UE has selected or reselected a Relay UE and it receives the indication about system information update from a cell, the Remote UE could ignore this indication and does not perform the system information acquisition procedure for acquiring system information from the cell. If the Remote UE does not find any Relay UE or there is no proper Relay UE can be selected, the Remote UE could still perform the system information acquisition procedure for acquiring system information from the cell. The above concept could be also applied for the case of receiving a PWS notification that also triggers the system information acquisition procedure for acquiring system information from serving cell.
The following exemplary text proposal for the invention could be proposed for 3GPP TS 38.331:
Text Proposal
The UE shall apply the SI acquisition procedure as defined in clause 5.2.2.3 upon cell selection (e.g. upon power on), cell-reselection, return from out of coverage, after reconfiguration with sync completion, after entering the network from another RAT, upon receiving an indication that the system information has changed and no relay UE (in capable of supporting SI delivery) is selected, upon receiving a PWS notification and no relay UE (in capable of supporting SI delivery) is selected, upon receiving request (e.g., a positioning request) from upper layers; and whenever the UE does not have a valid version of a stored SIB or posSIB or a valid version of a requested SIB.
In one embodiment, the system information may be a minimum or essential system information broadcasted by the network node. The Layer-2 ID of the relay UE may be known to the remote UE by receiving a discovery message from the relay UE.
In one embodiment, the common Layer-2 ID associated with the purpose of delivering or forwarding the system information could be preconfigured or specified in the remote UE. The network node may be a gNB or a base station.
Referring back to
In one embodiment, the system information may be a minimum or essential system information broadcasted by the network node. The relay UE could broadcast or transmit at least a discovery message, wherein the discovery message is sent with the Layer-2 ID of the relay UE.
In one embodiment, the common Layer-2 ID associated with the purpose of delivering or forwarding the system information could be preconfigured or specified in the relay UE. The network node may be a gNB or a base station.
Referring back to
In one embodiment, the remote UE could receive a first message from the relay UE in the system information acquisition procedure, wherein the first message includes a minimum system information of a cell serving the relay UE. The remote UE could transmit a second message to the relay UE in the system information acquisition procedure, wherein the second message indicates at least a System Information Block (SIB) or a SI message is requested by the remote UE. The remote UE could receive a third message from the relay UE in the system information acquisition procedure, wherein the third message includes the SIB or the SI message as requested by the remote UE.
In one embodiment, the first/second/third message may be a PC5 Radio Resource Control (RRC) message.
Referring back to
In one embodiment, the remote UE could perform the system information acquisition procedure for acquiring the system information from the first cell if the remote UE does not select any relay UE for acquiring system information. The remote UE may not perform the system information acquisition procedure for acquiring the system information from the first cell if the remote UE selects or reselects the relay UE for acquiring system information.
In one embodiment, the remote UE could perform the system information acquisition procedure for acquiring the system information from the first cell with a base station (e.g. gNB of the first cell). The remote UE could perform a second system information acquisition procedure for acquiring system information from the relay UE if the remote UE selects or reselects the relay UE for acquiring system information. The remote UE could perform the second system information acquisition procedure for acquiring the system information from the relay UE with the relay UE.
In one embodiment, the system information received from the relay UE could belong to a second cell.
In one embodiment, the indication could be sent via a paging message. the indication is sent by the base station.
Referring back to
Various aspects of the disclosure have been described above. It should be apparent that the teachings herein could be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein could be implemented independently of any other aspects and that two or more of these aspects could be combined in various ways. For example, an apparatus could be implemented or a method could be practiced using any number of the aspects set forth herein. In addition, such an apparatus could be implemented or such a method could be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the above concepts, in some aspects concurrent channels could be established based on pulse repetition frequencies. In some aspects concurrent channels could be established based on pulse position or offsets. In some aspects concurrent channels could be established based on time hopping sequences. In some aspects concurrent channels could be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.
Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein, for convenience, as “software” or a “software module”), or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.
In addition, the various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or performed by an integrated circuit (“IC”), an access terminal, or an access point. The IC may comprise a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute codes or instructions that reside within the IC, outside of the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
It is understood that any specific order or hierarchy of steps in any disclosed process is an example of a sample approach. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module (e.g., including executable instructions and related data) and other data may reside in a data memory such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. A sample storage medium may be coupled to a machine such as, for example, a computer/processor (which may be referred to herein, for convenience, as a “processor”) such the processor can read information (e.g., code) from and write information to the storage medium. A sample storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in user equipment. In the alternative, the processor and the storage medium may reside as discrete components in user equipment. Moreover, in some aspects any suitable computer-program product may comprise a computer-readable medium comprising codes relating to one or more of the aspects of the disclosure. In some aspects a computer program product may comprise packaging materials.
While the invention has been described in connection with various aspects, it will be understood that the invention is capable of further modifications. This application is intended to cover any variations, uses or adaptation of the invention following, in general, the principles of the invention, and including such departures from the present disclosure as come within the known and customary practice within the art to which the invention pertains.
The present application claims the benefit of U.S. Provisional Patent Application Ser. Nos. 63/107,723 and 63/107,754 filed on Oct. 30, 2020, the entire disclosures of which are incorporated herein in its entirety by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63107723 | Oct 2020 | US | |
| 63107754 | Oct 2020 | US |
