CN118215087A - Network node in a wireless communication system and method for a network node - Google Patents
Network node in a wireless communication system and method for a network node Download PDFInfo
- Publication number
- CN118215087A CN118215087A CN202311698393.3A CN202311698393A CN118215087A CN 118215087 A CN118215087 A CN 118215087A CN 202311698393 A CN202311698393 A CN 202311698393A CN 118215087 A CN118215087 A CN 118215087A
- Authority
- CN
- China
- Prior art keywords
- handover
- configuration
- request
- gnb
- 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 title claims abstract description 116
- 238000004891 communication Methods 0.000 title abstract description 37
- 230000004044 response Effects 0.000 claims abstract description 175
- 230000011664 signaling Effects 0.000 description 200
- 238000002360 preparation method Methods 0.000 description 82
- 239000000126 substance Substances 0.000 description 27
- 238000010586 diagram Methods 0.000 description 15
- 238000005259 measurement Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 9
- 230000033001 locomotion Effects 0.000 description 8
- 230000002441 reversible effect Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 230000001960 triggered effect Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 5
- 150000001875 compounds Chemical class 0.000 description 5
- 230000007774 longterm Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 5
- 230000010363 phase shift Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000013468 resource allocation Methods 0.000 description 5
- 230000009977 dual effect Effects 0.000 description 4
- 230000001364 causal effect Effects 0.000 description 3
- 230000001143 conditioned effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 239000011159 matrix material Substances 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 241000700159 Rattus Species 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 239000002245 particle Substances 0.000 description 2
- 230000001105 regulatory effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 101100150275 Caenorhabditis elegans srb-3 gene Proteins 0.000 description 1
- 101150014328 RAN2 gene Proteins 0.000 description 1
- 108091005487 SCARB1 Proteins 0.000 description 1
- 101150096310 SIB1 gene Proteins 0.000 description 1
- 102100037118 Scavenger receptor class B member 1 Human genes 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
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000003090 exacerbative effect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- XIGAUIHYSDTJHW-UHFFFAOYSA-N mefenacet Chemical compound N=1C2=CC=CC=C2SC=1OCC(=O)N(C)C1=CC=CC=C1 XIGAUIHYSDTJHW-UHFFFAOYSA-N 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 239000005022 packaging material Substances 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 235000019527 sweetened beverage Nutrition 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
The invention provides a network node and a method for a network node in a wireless communication system, the method comprising: receiving a first configuration from a second network node; broadcasting the first configuration via system information in the first cell; transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in the handover command; in response to transmitting the handover request, receiving a handover command in a handover request acknowledgement from the second network node, wherein the handover command includes the second configuration and does not include the first configuration; and transmitting a handover command to the user equipment.
Description
Cross reference to related applications
The present application claims priority and benefit of U.S. provisional patent application Ser. No. 63/433,320, U.S. provisional patent application Ser. No. 63/434,880, and U.S. provisional patent application Ser. No. 63/436,856, and U.S. provisional patent application Ser. No. 2023, 1/3; each of the applications and publications cited therein are fully incorporated by reference herein.
Technical Field
The present disclosure relates generally to a network node and a method for a network node in a wireless communication system, and more particularly, to a method and apparatus for handling handover preparation in a wireless communication system.
Background
With the rapid increase in demand for large amounts of data to and from mobile communication devices, conventional mobile voice communication networks evolve into networks that communicate using internet protocol (Internet Protocol, IP) data packets. Such IP packet communications may provide voice over IP, multimedia, multicast, and on-demand communication services to users of mobile communication devices.
An exemplary network structure is an evolved universal terrestrial radio access network (Evolved Universal Terrestrial Radio Access Network, E-UTRAN). The E-UTRAN system may provide high data throughput to implement the above-described IP-bearing voice and multimedia services. Currently, the third generation partnership project (3rd Generation Partnership Project,3GPP) standards organization is discussing new next generation (e.g., 5G) radio technologies. Thus, current bodies of changing 3GPP standards are currently being submitted and considered to evolve and ultimately determine the 3GPP standards.
Disclosure of Invention
Methods, systems, and devices are provided for handling handover preparation in a wireless communication system. In various embodiments, the network may perform public handover, group handover, and/or 2-step handover (for a group of User Equipment (UE)) in a non-terrestrial network (NTN). The target next generation node B (gNB) may know what handover configuration should be provided to the source gNB, e.g., in the case of group handover, common handover, and/or 2-step handover. The source gNB may process the UE context information in a handover request for a common handover. The source gNB may request a configuration for a different type of handover. In various embodiments, signaling overhead for earth moving cells, such as (group) handovers in NTNs, may be further reduced.
Systems and apparatus are provided for a method for a first network node in a wireless communication system, the method comprising: receiving a first configuration from a second network node; broadcasting the first configuration via system information in the first cell; transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in the handover command; in response to transmitting the handover request, receiving a handover command in a handover request acknowledgement from the second network node, wherein the handover command includes the second configuration and does not include the first configuration; and transmitting a handover command to a User Equipment (UE).
Systems and apparatus are provided for a method for a second network node in a wireless communication system, the method comprising: receiving a request from a first network node, wherein the request contains a plurality of UE context information or does not contain UE context information; transmitting a response containing the first configuration to the first network node in response to receiving the request; receiving a handover request from the first network node, wherein the handover request comprises an indication of a public handover and/or a request for a second configuration; and/or in response to receiving the handover request: determining that the first configuration is not included in the handover command; and transmitting a handover command including the second configuration without the first configuration to the first network node in a handover request acknowledgement.
Drawings
Fig. 1 shows a diagram of a wireless communication system in accordance with an embodiment of the present invention;
fig. 2 is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an embodiment of the present invention;
fig. 3 is a functional block diagram of a communication system according to an embodiment of the present invention;
FIG. 4 is a functional block diagram of the program code of FIG. 3 according to an embodiment of the present invention;
FIG. 5 is a reproduction of FIG. 16.14.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": general description of NTN;
FIG. 6 is a reproduction of FIG. 9.2.3.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": an inter-gNB handover procedure;
FIG. 7 is a reproduction of FIG. 9.2.3.2.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": AMF/UPF internal switching;
FIG. 8 is a reproduction of FIG. 9.2.3.4.2-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": switching the conditions in the AMF/UPF;
Fig. 9 is a reproduction of fig. 5.3.5.1-1 from 3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification": RRC reconfiguration, success;
fig. 10 is a reproduction of fig. 5.3.5.1-2 from 3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification": RRC reconfiguration, failure;
Fig. 11 is a rendition of fig. 8.2.1.2-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": switching preparation and successful operation;
Fig. 12 is a rendition of fig. 8.2.1.3-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": switching preparation, unsuccessful operation;
Fig. 13 is a reproduction of fig. 8.4.1.2 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": xn is established, and the operation is successful;
Fig. 14 is a rendition of fig. 8.4.2.2-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": NG-RAN node configuration update, successful operation;
fig. 15 is a rendition of fig. 8.4.1.2-1 from 3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)": switching preparation: successful operation;
Fig. 16 is a rendition of fig. 8.4.2.2-1 from 3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)": switching resource allocation: successful operation;
fig. 17 is a diagram of a source gNB transmitting a first handover command with a UE-specific configuration to a first UE and a second handover command with a UE-specific configuration to a second UE, according to an embodiment of the invention;
FIG. 18 is a diagram in which a source gNB may indicate whether a target gNB provides a second configuration (in a first configuration) through a handover request, and the source gNB may provide an indication in the handover request, according to an embodiment of the present invention;
FIG. 19 is a diagram in which a target gNB may communicate a second configuration and/or a message including the second configuration if various conditions are met (or based) in accordance with an embodiment of the present invention;
Fig. 20 is a diagram of a common portion (e.g., a second configuration) in which a source gNB requests a handover configuration without UE context information (or with multiple UE context information), according to an embodiment of the invention;
FIG. 21 is a diagram in which a source gNB provides an indication to a target gNB in a handover request requesting a handover configuration (e.g., for a public handover or a legacy handover), in accordance with an embodiment of the present invention;
fig. 22 is a flow chart of a method of a first network node according to an embodiment of the invention, comprising: receiving a first configuration from a second network node; broadcasting the first configuration via the system information; transmitting a handover request to the second network node; receiving a handover command in response to transmitting a handover request; and transmitting a handover command to the UE;
Fig. 23 is a flow chart of a method of a second network node according to an embodiment of the invention, comprising: receiving a request from a first network node; transmitting a response including the first configuration in response to receiving the request; receiving a handover request from a first network node; and/or in response to receiving the handover request: determining that the handover command does not contain the first configuration; and transmitting a handover command including the second configuration.
Detailed Description
The invention described herein may be applied to or implemented in exemplary wireless communication systems and devices described below. In addition, the present invention is mainly described in the context of a 3GPP architecture reference model. However, it should be understood that with the aid of the disclosed information, one skilled in the art can readily adapt to use and implement aspects of the present invention in 3GPP2 network architectures, as well as other network architectures.
The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. 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 long term evolution (Long Term Evolution, LTE) wireless access, 3GPP long term evolution-advanced (Long Term Evolution Advanced, LTE-a) wireless access, 3GPP2 ultra mobile broadband (Ultra Mobile Broadband, UMB), wiMax, 3GPP New Radio (NR), or some other modulation technique.
In particular, the exemplary wireless communication systems and devices described below may be designed to support one or more standards, such as those provided by a complex referred to herein as the 3GPP entitled "third generation partnership project," including: [1] RP-221819, "NR NTN (non-terrestrial network) enhancement"; [2]3GPP TR 38.821 V16.1.0, "solution for NR support non-terrestrial network (NTN)"; [3]3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN general description, phase 2"; [4]3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification"; [5]3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)"; [6] r2-2209711, "signaling and congestion reduction in satellite switch"; and [7]3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)". The standards and documents listed above are expressly and fully incorporated herein by reference in their entirety.
Fig. 1 illustrates a multiple access wireless communication system according to one embodiment of the present invention. Access network 100 (AN) includes multiple antenna groups, one group including 104 and 106, another group including 108 and 110, and additional groups including 112 and 114. In fig. 1, only two antennas are shown for each antenna group, however, more or fewer antennas may be utilized for each antenna group. An Access Terminal (AT) 116 is in communication with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 over forward link 120 and receive information from access terminal 116 over reverse link 118. AT 122 is in communication with antennas 106 and 108, where antennas 106 and 108 transmit information to AT 122 over forward link 126 and receive information from AT 122 over reverse link 124. In a frequency division duplex (Frequency Division Duplexing, FDD) system, communication links 118, 120, 124 and 126 can use different frequencies for communication. For example, forward link 120 may use a different frequency than that used by reverse link 118.
Each antenna group and/or the area in which the antenna group is designed to communicate is often referred to as a sector of an access network. In an embodiment, antenna groups each are designed to communicate to access terminals in a sector of the areas covered by access network 100.
In communication via forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve signal-to-noise ratio of forward links for the different access terminals 116 and 122. Also, the use of beamforming by an access network to transmit to access terminals scattered randomly through its coverage typically causes less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to all its access terminals.
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 eNodeB, or some other terminology. An AT may also be referred to as a User Equipment (UE), a wireless communication device, a terminal, an access terminal, or some other terminology.
Fig. 2 is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an Access Terminal (AT) or User Equipment (UE)) in a multiple-input multiple-output (Multiple Input Multiple Output, MIMO) system 200 AT the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a Transmit (TX) data processor 214.
In one embodiment, each data stream is transmitted via 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 (e.g., symbol mapped) based on a particular modulation scheme (e.g., binary phase-shift keying (Binary PHASE SHIFT KEYING, BPSK), quadrature phase-shift keying (Quadrature PHASE SHIFT KEYING, QPSK), multiple PHASE SHIFT KEYING, M-PSK, or Quadrature amplitude modulation (Quadrature Amplitude Modulation, 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. Memory 232 is coupled to 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 N T modulation symbol streams to N T 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. Subsequently, N T modulated signals from transmitters 222a through 222t are transmitted from N T antennas 224a through 224t, respectively.
At receiver system 250, the transmitted modulated signals are received by N R 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 obtain samples, and further processes the samples to obtain a corresponding "received" symbol stream.
RX data processor 260 then receives and processes the N R symbol streams received from N R receivers 254 based on a particular receiver processing technique to obtain N T "detected" symbol streams. 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.
The 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 reverse link message transmitted by receiver system 250. Processor 230 then determines which pre-coding matrix to use for determining the beamforming weights and then processes the acquired message.
Memory 232 may be used to temporarily store some of the buffered/calculated data from 240 or 242 via processor 230, store some of the buffered data from 212, or store some of the specific program code. Also, memory 272 may be used to temporarily store some buffered/calculated data from 260 via processor 270, store some buffered data from 236, or store some specific program code.
Turning to fig. 3, this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the present invention. As shown in fig. 3, UEs (or ATs) 116 and 122 of fig. 1 may be implemented with a communication device 300 in a wireless communication system, and the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a Central Processing Unit (CPU) 308, a memory 310, program code 312, and a transceiver 314. Control circuitry 306 executes program code 312 in memory 310 via CPU 308, thereby controlling the operation of communication device 300. The communication device 300 may receive signals input by a user through an input device 302, such as a keyboard or keypad, and may output images and sounds through an output device 304, such as a display or speaker. The transceiver 314 is used to receive and transmit wireless signals, pass the received signals to the control circuit 306, and wirelessly output signals generated by the control circuit 306.
Fig. 4 is a simplified block diagram of the program code 312 shown in fig. 3 according to an embodiment of the invention. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 typically performs radio resource control. Layer 2 portion 404 typically performs link control. Layer 1 portion 406 typically performs physical connections.
For LTE, LTE-a, or NR systems, layer 2 portion 404 may include a radio link control (Radio Link Control, RLC) layer and a medium access control (Medium Access Control, MAC) layer. Layer 3 portion 402 may include a radio resource control (Radio Resource Control, RRC) layer.
Any two or more of the following paragraphs, prime notation, gist, action, or claims describing each invention may be logically, reasonably, and appropriately combined to form a particular method.
Any sentence, paragraph, (sub) bullets, gist, action, or claim described in each invention below can be implemented independently and individually to form a specific method or apparatus. The following references in the present disclosure to "based on", "rather", "examples", etc., are merely one possible embodiment of a particular method or apparatus.
The general description of the NR non-terrestrial network (NTN) of release 17 is specified in TS 38.300 ([ 3]3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2"):
* The term "x" and "x" refer to the same or different amounts of a compound as defined herein
16.14 Non-terrestrial networks
16.14.1 Overview
From 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, fig. 16.14.1-1 of stage 2" below illustrates an example of a non-terrestrial network (NTN) that provides non-terrestrial NR access to a UE by means of an NTN payload and an NTN gateway, depicting a service link between the NTN payload and the UE, and a feeder link between the NTN gateway and the NTN payload.
FIG. 5 is a reproduction of FIG. 16.14.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": general description of NTN.
The NTN payload transparently forwards the radio protocol received from the UE (via the service link) to the NTN gateway (via the feed link), and vice versa. The following connectivity is supported by the NTN payload:
The NTN gateway may serve multiple NTN payloads;
The NTN payload may be served by multiple NTN gateways.
[…]
Three types of service links are supported:
-earth fixation: provided by beams that constantly cover the same geographic area (e.g., as in the case of GSO satellites);
Quasi-earth fixation: provided by beams that cover one geographic area for a limited period of time and a different geographic area during another period of time (e.g., as in the case of NGSO satellites that produce steerable beams);
-earth movement: provided by beams that slide over the earth's surface in the coverage area (e.g., as in the case of NGSO satellites that produce fixed or non-steerable beams).
For NGSO satellites, the gNB may provide a quasi-earth fixed service link or an earth mobile service link, while a gNB operating with GSO satellites may provide an earth fixed service link.
In this version, the NTN-enabled UE has GNSS functionality.
[…]
Mobility in RRC_CONNECTED
16.14.3.2.1 Switch
[…]
The UE may support mobility between radio access technologies each based on different tracks (GSO, NGSO at different altitudes).
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
The work item for version 18NR NTN is specified in [1] RP-221819, "NR NTN (non-terrestrial network) enhancement".
* The term "x" and "x" refer to the same or different amounts of a compound as defined herein
In release 17, work items are carried out to define a solution that enables new radios and NG-RANs to support non-terrestrial networks (NTNs):
● Addressing at least 3GPP Power class 3 UEs with GNSS capabilities in both fixed and/or Mobile cell configuration based on transparent payload GSO and NGSO network contexts
As part of release 18, new work items are presented to define enhancements to NG-RAN based non-terrestrial networks to:
● Supporting new scenarios covering deployment in frequency bands above 10GHz
● Considering NTN characteristics such as large propagation delay and satellite movement, optimal performance is provided, especially when addressing mobile terminals (including smartphones with more realistic assumptions about antenna gain than 0dBi antenna gain, where specific realistic antenna gain assumptions will be determined at the workgroup level) with respect to coverage.
● Mobility and service continuity enhancements are provided in view of NTN characteristics such as large propagation delay and satellite movement.
● The address requirements, if needed based on the fs_nr_ntn_ netw _ verif _ue_loc study results, authorize the network operator to cross check the UE location reported by the UE, which check needs to be done in order to meet regulatory requirements (e.g. lawful interception, emergency call, public alert system … …) about network verified UE location, i.e. to be able to check the UE reported location information (e.g. estimate the UE location on the network side) and indicate if an organization is needed to meet the regulatory requirements.
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
Some enhancements to NTN are described in TR 38.821 ([ 2]3GPP TR 38.821 V16.1.0, "NR supports solutions to non-terrestrial networks (NTNs)), as provided below:
* The term "x" and "x" refer to the same or different amounts of a compound as defined herein
7.3.2.1.4 Frequent and unavoidable handovers
Satellites in non-GEO orbits move at high speeds relative to fixed locations on the earth, resulting in frequent and unavoidable handovers for both fixed and mobile UEs. This may result in significant signaling overhead and impact power consumption, as well as exacerbating other potential challenges associated with mobility, such as service interruption due to signaling latency.
For a UE traveling at a constant speed and direction, the maximum time it can stay connected to the cell is approximated by dividing the cell diameter by the UE speed. For NTN LEO deployments, the cell size is divided by the relative speed between the satellite and the UE, where the UE moving in the same direction as the satellite is subtracted from the relative speed and the UE moving in the opposite direction increases the relative speed, described by the following equation:
The cell diameter = one 50km diameter beam context will represent a lower bound (i.e., worst case of HO frequencies), and the cell diameter = 1000km will be considered an upper bound (i.e., best case of HO frequencies).
Bringing the reference values from 4.2-2 and 7.1-1 into the above equation, the maximum time that the UE can remain in the NTN cell (i.e., the UE is connected immediately at the cell edge and leaves at the opposite cell edge) for the minimum/maximum cell diameter and relative speed is listed in the following table:
table 7.3.2.1.4-1: HO time for minimum/maximum cell diameter and varying UE speed
Neglecting UE movement, UEs served by NTN LEO cells of diameters 50km and 1000km may remain connected for up to 6.61 seconds and 132.38 seconds, respectively, due to satellite movement. This will vary by approximately +/-4% considering the movement of the UE. By ignoring satellite speeds and setting the UE speed to 500km/hr as per table 7.1-1, this equates to terrestrial UEs being served by cell diameters ranging from approximately 0.918km (note 2) to 18.39 km.
From the above analysis, it is concluded that the HO frequencies in LEO NTN may be similar to those experienced by ground UEs on high speed trains, however this represents the worst scenario and does not indicate a typical ground network. Since larger cell sizes limit the impact of UE speed, it is expected that frequent HO will not occur in GEO. Further assume in the LEO context that given the relative velocity of the satellites, the UE velocity is a negligible factor in the HO frequency, and this would be mainly a problem with LEOs with moving beams.
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
General description of handover procedure is specified in TS 38.300 ([ 3]3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN general description, phase 2"):
* The term "x" and "x" refer to the same or different amounts of a compound as defined herein
Mobility in RRC_CONNECTED
9.2.3.1 Overview
Network controlled mobility applies to UEs in rrc_connected and is classified into two types of mobility: cell-level mobility and beam-level mobility. Beam level mobility includes intra-cell beam level mobility and inter-cell beam level mobility.
Cell level mobility requirements trigger explicit RRC signaling, i.e. handover. For inter-gcb handover, the signaling procedure consists of at least the following basic components shown in fig. 9.2.3.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2":
FIG. 6 is a reproduction of FIG. 9.2.3.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": gNB inter-switching procedure.
1. The source gNB initiates the HANDOVER and issues a HANDOVER REQUEST on the Xn interface.
2. The target gNB performs admission control and provides the new RRC configuration as part of HANDOVER REQUEST ACKNOWLEDGE.
3. The source gNB provides RRC configuration to the UE by forwarding the RRCReconfiguration message received in HANDOVER REQUEST ACKNOWLEDGE. The RRCReconfiguration message contains at least the cell ID and all information needed to access the target cell so that the UE can access the target cell without reading the system information. For some cases, the information needed for contention-based and contention-free random access may be included in the RRCReconfiguration message. The access information to the target cell may contain beam specific information (if present).
The ue moves the RRC connection to the target gNB and replies RRCReconfigurationComplete.
Note 1: user data may also be sent in step 4 if granted permission.
[…]
9.2.3.2 Switch
9.2.3.2.1 Control plane processing
The intra-NR RAN handover performs the preparation and execution phases of the performed handover procedure without involving a 5GC, i.e. the preparation messages are exchanged directly between the gnbs. The release of resources at the source gNB during the handover complete phase is triggered by the target gNB. The following diagram depicts a basic handover scenario where neither AMF nor UPF changes:
FIG. 7 is a reproduction of FIG. 9.2.3.2.1-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": AMF/UPF intra-switching.
0. The UE context within the source gNB contains information about roaming and access restrictions provided at connection establishment or at last TA update.
1. The source gNB configures the UE measurement procedure and the UE reports according to the measurement configuration.
2. The source gNB decides to handover the UE based on the MeasurementReport and RRM information.
3. The source gNB issues a handover request message to the target gNB, passing through the transparent RRC container with the necessary information to prepare for the handover at the target side. This information includes at least the target cell ID, kgNB, the C-RNTI of the UE in the source gNB, RRM configuration including the UE inactivity time, basic AS configuration including antenna information and DL carrier frequency, current QoS flows to DRB mapping rules applied to the UE, SIB1 from the source gNB, UE capabilities for different RATs, PDU session related information, and may include UE reporting measurement information including beam related information if available. The PDU session related information contains slice information and QoS flow class QoS attribute sets. The source gNB can also request DAPS handoff for one or more DRBs.
Note 1: after issuing the handover request, the source gNB should not reconfigure the UE, including performing the reflected QoS flows to DRB mapping.
4. Admission control may be performed by the target gNB. Slice aware admission control should be performed with slice information sent to the target gNB. If a PDU session is associated with an unsupported slice, the target gNB should reject such a PDU session.
5. The target gNB prepares for the handover with L1/L2 and sends HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent as an RRC message to the UE to perform the handover. The target gNB also indicates whether DAPS handoff is accepted.
And (2) injection: data forwarding may be initiated whenever source gNB receives HANDOVER REQUEST ACKNOWLEDGE, or whenever transmission of a handover command is initiated in the downlink.
[…]
6. The source gNB triggers a Uu handover by sending RRCReconfiguration a message to the UE containing information needed to access the target cell: at least a target cell ID, a new C-RNTI, a target gNB security algorithm identifier for the selected security algorithm. It may also contain a set of dedicated RACH resources, an association between RACH resources and SSB, an association between RACH resources and UE-specific CSI-RS configuration, common RACH resources, and system information of the target cell, etc.
[…]
7. For DRBs that are not configured with DAPS, the source gNB sends an SN status transfer message to the target gNB to convey the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB for which PDCP status preservation applies (i.e., for RLC AM). The uplink PDCP SN receiver status includes at least a first missing UL PDCP SDU and may include a bitmap of the reception status of out-of-sequence UL PDCP SDUs that the UE needs to retransmit in the target cell. The downlink PDCP SN transmitter status indicates that the target gNB will be assigned to the next PDCP SN of a new PDCP SDU that does not already have a PDCP SN.
[…]
The ue synchronizes to the target cell and completes the RRC handover procedure by sending RRCReconfigurationComplete a message to the target gNB. In the case of DAPS handoff, the UE does not detach from the source cell after receiving RRCReconfiguration message. The UE releases the source resources and configuration and stops DL/UL reception/transmission with the source after receiving an explicit release from the target node.
[…]
9. The target gNB sends PATH SWITCH REQUEST message to the AMF to trigger 5GC to switch the DL data path towards the target gNB and establish the NG-C interface instance towards the target gNB.
10.5GC switches the DL data path toward the target gNB. The UPF sends one or more "end-marker" packets on the old path to the source gNB per PDU session/tunnel, and then may release any user plane/TNL resources towards the source gNB.
The amf acknowledges PATH SWITCH REQUEST message with PATH SWITCH REQUEST ACKNOWLEDGE message.
12. Upon receiving PATH SWITCH REQUEST ACKNOWLEDGE a message from the AMF, the target gNB sends UE CONTEXT RELEASE to inform the source gNB of the success of the handover. The source gNB may then release the radio and control plane related resources associated with the UE context. Any ongoing data forwarding may continue.
The RRM configuration may contain beam measurement information (for layer 3 mobility) associated to SSBs and CSI-RS for reporting cells, provided that both types of measurements are available. Also, if the CA is configured, the RRM configuration may contain a list of best cells on each frequency for which measurement information is available. And the RRM measurement information may also include beam measurements for listed cells belonging to the target gNB.
The common RACH configuration for beams in the target cell is only associated to SSB. The network may have a dedicated RACH configuration associated to SSB and/or a dedicated RACH configuration associated to CSI-RS within the cell. The target gNB may include only one of the following RACH configurations in the handover command to enable the UE to access the target cell:
i) A common RACH configuration;
ii) common RACH configuration+dedicated RACH configuration associated with SSB;
iii) Common RACH configuration + dedicated RACH configuration associated with CSI-RS.
The dedicated RACH configuration allocates RACH resources together with a quality threshold to use them. When dedicated RACH resources are provided, they are prioritized by the UE and the UE should not switch to contention-based RACH resources as long as the quality threshold for those dedicated resources is met. The order of accessing the dedicated RACH resources depends on the UE implementation.
[…]
9.2.3.4 Conditional switch
9.2.3.4.1 General description
Conditional Handover (CHO) is defined as a handover performed by a UE when one or more handover execution conditions are met. The UE starts evaluating the execution condition upon receiving the CHO configuration and stops evaluating the execution condition upon performing the handover.
The following principle applies to CHO:
the CHO configuration contains the configuration of CHO candidate cells generated by the candidate gNB and the execution conditions generated by the source gNB.
The execution conditions may consist of one or two trigger conditions (CHO event A3/A5). Only a single RS type is supported and at most two different trigger amounts (e.g., RSRP and RSRQ, RSRP and SINR, etc.) may be configured simultaneously for evaluation of CHO execution conditions for a single candidate cell.
Before any CHO execution conditions are met, after receiving the HO command (no CHO configuration), the UE performs the HO procedure as described in clause 9.2.3.2, irrespective of any previously received CHO configuration.
When CHO is performed, i.e. starting from the time when the UE starts synchronizing with the target cell, the UE does not monitor the source cell.
[…]
9.2.3.4.2 Control plane processing
As in intra-NR RAN handover, in intra-NR RAN CHO, the preparation of the conditional handover procedure and execution of the execution phase does not involve 5GC, i.e. the preparation messages are exchanged directly between the gnbs. The release of resources at the source gNB during the conditional handover completion phase is triggered by the target gNB. The following diagram depicts a basic conditional switching scenario in which neither AMF nor UPF changes:
FIG. 8 is a reproduction of FIG. 9.2.3.4.2-1 from 3GPP TS 38.300 V17.2.0, "NR, NR and NG-RAN overall description, phase 2": AMF/UPF internal condition switching.
0/1. Steps 0,1 of FIG. 9.2.3.2.1-1 from clause 9.2.3.2.1 of 3GPP TS 38.300 V17.2.0 are identical.
2. Source gNB decided to use CHO.
3. The source gNB requests CHO for one or more candidate cells belonging to one or more candidate gnbs. A CHO request message is sent for each candidate cell.
4. The same as step 4 of figure 9.2.3.2.1-1 from clause 9.2.3.2.1 of 3GPP TS 38.300 V17.2.0.
5. The candidate gNB sends a CHO response (HO request acknowledgement) containing the configuration of the CHO candidate cells to the source gNB. A CHO response message is sent for each candidate cell.
6. The source gNB sends RRCReconfiguration message containing the CHO candidate cell configuration and CHO execution conditions to the UE.
Note 1: CHO configurations of candidate cells may follow other reconfigurations from the source gNB.
[…]
The ue sends RRCReconfigurationComplete a message to the source gNB.
7A if early data forwarding is applied, the source gNB sends an early status delivery message.
The ue maintains a connection with the source gNB after receiving the CHO configuration and begins evaluating CHO execution conditions of the candidate cells. If at least one CHO candidate cell meets the corresponding CHO execution conditions, the UE detaches from the source gNB, applies the stored corresponding configuration for the selected candidate cell, synchronizes with the candidate cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to the target gNB. The UE releases the stored CHO configuration after the RRC handover procedure is successfully completed.
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
Some configurations related to handover are specified in TS 38.331 ([ 4]3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification"), as provided below:
* The term "x" and "x" refer to the same or different amounts of a compound as defined herein
5.3.5RRC reconfiguration
5.3.5.1 General description
Fig. 9 is a reproduction of fig. 5.3.5.1-1 from 3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification": RRC reconfiguration was successful.
Fig. 10 is a reproduction of fig. 5.3.5.1-2 from 3GPP TS 38.331 V17.2.0, "NR, RRC protocol specification": RRC reconfiguration, failure.
The purpose of this procedure is to modify RRC connections, e.g. establish/modify/release RB/BH RLC channel/Uu relay RLC channel/PC 5 relay RLC channel, perform reconfiguration with synchronization, set/modify/release measurements, add/modify/release SCell and cell group, add/modify/release conditional handover configuration, add/modify/release conditional PSCell change or conditional PSCell addition configuration. NAS specific information may be communicated from the network to the UE as part of the procedure.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
-RRCReconfiguration
RRCReconfiguration message is a command to modify the RRC connection. It may convey information for measurement configuration, mobility control, radio resource configuration (including RB, MAC primary configuration, and physical channel configuration), and AS security configuration.
Signaling radio bearers: SRB1 or SRB3
RLC-SAP：AM
Logical channel: DCCH (DCCH)
The direction is: network to UE
RRCReconfiguration message
/>
* The reference and the reference are the same, and the reference is the same
-CellGroupConfig
CellGroupConfig are used to configure a primary cell group (MCG) or Secondary Cell Group (SCG). The cell group includes one MAC entity, a set of logical channels with associated RLC entities, as well as a primary cell (SpCell) and one or more secondary cells (scells).
CellGroupConfig information element
/>
/>
[...]
[…]
-NTN-Config
The IE NTN-Config provides parameters required for the UE to access the NR via NTN access. NTN-Config information element
/>
[…]
-ServingCellConfig
IE ServingCellConfig are used to configure (add or modify) the UE with a serving cell, which may be a SCell or SCell of an MCG or SCG. The parameters herein are mainly UE-specific, but part is also cell-specific (e.g., in a otherwise configured bandwidth part). Only SCell release and addition support reconfiguration between PUCCH and PUCCH-free SCell.
ServingCellConfig information element
/>
[…]
-ServingCellConfigCommon
IE ServingCellConfigCommon are used to configure cell specific parameters of the serving cell of the UE. The IE contains parameters that the UE will typically acquire from SSB, MIB or SIB when accessing the cell from IDLE. Through this IE, the network provides this information in dedicated signaling when configuring scells or additional cell groups (SCGs) for the UE. The network also provides support for SpCell (MCG and SCG) after synchronous reconfiguration.
ServingCellConfigCommon information element
/>
* The reference and the reference are the same, and the reference is the same
-HandoverCommand
This message is used to communicate the handover command generated by the target gNB.
The direction is: target gNB to source gNB/source RAN.
HandoverCommand message
/>
-HandoverPreparationInformation
This message is used to transmit NR RRC information used by the target gNB, including UE capability information, e.g., during handover preparation or UE context retrieval in case of recovery or re-establishment. This message is also used to pass information between the CU and the DU.
The direction is: source gNB/source RAN to target gNB or CU to DU.
HandoverPreparationInformation message
/>
/>
/>
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
The procedure and configuration for handover preparation is specified in TS 38.423 ([ 5]3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)") as provided below:
* The reference and the sum are the same as the sum of the two
8.2.1 Handover preparation
8.2.1.1 General description
This procedure is used to establish the required resources for the incoming handover in the NG-RAN node. If the program involves conditional switching, then parallel transactions are allowed. When the source UE AP IDs are the same, the target cell ID identifies a possible parallel request.
The procedure uses UE-associated signaling.
8.2.1.2 Successful operation
Fig. 11 is a rendition of fig. 8.2.1.2-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": and (5) switching preparation and successful operation.
The source NG-RAN node initiates the procedure by sending a HANDOVER REQUEST message to the target NG-RAN node. When the source NG-RAN node sends a HANDOVER REQUEST message, it will start timer TXn RELOCprep.
If a conditional HANDOVER information REQUEST IE is contained in the HANDOVER REQUEST message, the target NG-RAN node should consider that the REQUEST relates to conditional HANDOVER and should include a conditional HANDOVER information confirm IE in the HANDOVER REQUEST ACKNOWLEDGE message.
If the target NG-RAN node UE XnAP ID IE is included in the conditional HANDOVER information REQUEST IE included in the HANDOVER REQUEST message, the target NG-RAN node will remove the existing prepared condition HO identified by the target NG-RAN node UE XnAP ID IE and the target cell global ID IE. Depending on the implementation of the target NG-RAN node when HO information is to be removed.
Upon receipt of the HANDOVER REQUEST ACKNOWLEDGE message, the source NG-RAN node will stop timer TXn RELOCprep and terminate the handover preparation procedure. If the procedure is initiated for the current handover, the source NG-RAN node will start timer TXn RELOCoverall. The source NG-RAN node is then defined as a handover with preparation for the Xn UE associated signaling.
[…]
Upon receipt of the HANDOVER REQUEST message, the target NG-RAN node will prepare for configuration of the AS security relationship between the UE and the target NG-RAN node by using the information in the UE security capability IE and the AS security information IE in the UE context information IE, AS specified in TS 33.501[28 ].
[…]
For each PDU session resource successfully established at the target NG-RAN, the target NG-RAN node may allocate resources for the additional Xn-U PDU session resource GTP-U tunnel indicated in the assistance data forwarding information from the target NG-RAN node list IE.
For each PDU session in the HANDOVER REQUEST message, if the substitute QoS parameter set list IE is included in the GBR QoS flow information IE in the PDU session resource list to be established, the target NG-RAN node may accept the establishment of the involved QoS flow upon notification control being enabled, in case at least one of the requested QoS parameter set or the substitute QoS parameter set may be met at a HANDOVER time as specified in TS23.501[7 ]. In case the target NG-RAN node accepts the handover satisfying one of the alternative QoS parameters, it will indicate an alternative QoS parameter set that can currently be satisfied in the current QoS parameter set index IE within the PDU session resource admission list IE of the HANDOVER REQUEST ACKNOWLEDGE message, while setting QoS parameters for the UE according to the requested QoS parameter set as specified in TS23.501[7 ].
For each DRB for which the source NG-RAN node proposes to perform forwarding of downlink data, the source NG-RAN node shall contain a source DRB ID IE and a mapped QoS flow list IE within a source DRB-to-QoS flow mapping list IE contained in the PDU session resource list to be established IE in the HANDOVER REQUEST message. The source NG-RAN node may include a QoS flow mapping indication IE in the source DRB to QoS flow mapping list IE to indicate that only uplink or downlink QoS flows are mapped to DRBs. If the target NG-RAN node decides to use the same DRB configuration and map the same QoS flow as the source NG-RAN node, the target NG-RAN node contains a DL forwarding GTP tunnel endpoint IE within the data forwarding response DRB list IE in the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the proposed forwarding of the downlink data for this DRB.
If at least one of the QoS flows mapped to the DRB meets the redundant transport characteristics, as indicated in a redundant QoS flow indicator IE within the PDU session resource list to be established IE received in the HANDOVER REQUEST message of the QoS flow, the target NG-RAN node may additionally include a redundant DL forwarding UP TNL information IE.
If HANDOVER REQUEST ACKNOWLEDGE message contains UL forwarding TNL information IE for a given DRB in the data forwarding response DRB list IE within the data forwarding information from the target NG-RAN node in the PDU session resource admission list IE and the source NG-RAN node accepts the data forwarding proposed by the target NG-RAN node, then the source NG-RAN node will perform forwarding of uplink data for the DRB.
If the HANDOVER REQUEST contains PDU session resources for a PDU session associated with S-NSSAI not supported by the target NG-RAN, the target NG-RAN node will reject such PDU session resources. In this case, and if at least one PDU session resource entry IE to be established is admitted, the target NG-RAN node will send HANDOVER REQUEST ACKNOWLEDGE message containing a PDU session resource unauthenticated list IE listing the corresponding PDU session rejected by the target NG-RAN.
If mobility restriction list IE
Contained in the HANDOVER REQUEST message, then the target NG-RAN node will
-Storing information received in a mobility restriction list IE in a UE context;
-using this information to determine the target of the UE during a subsequent mobility action, wherein the NG-RAN node provides the UE with information about the target of the mobility action, except when one of the PDU sessions has a specific ARP value (TS 23.501[7 ]), in which case the information will not apply;
using this information to select the appropriate SCG during the dual connectivity operation.
When moving the UE to rrc_inactive, use this information to select the appropriate RNA for the UE.
Not in the HANDOVER REQUEST message, then the target NG-RAN node will
No roaming and no access restrictions are considered applicable to the UE, except PNI-NPN mobility as described in TS23.501[7 ].
[…]
If the RAT/frequency selection priority index IE is contained in the HANDOVER REQUEST message, the target NG-RAN node will store this information and use it as defined in TS23.501[7 ].
If the UE context reference IE at the S-NG-RAN is contained in the HANDOVER REQUEST message, the target NG-RAN node may use it as specified in TS 37.340[8 ]. In this case, the source NG-RAN node may expect the target NG-RAN node to contain a UE context hold indicator IE set to "true" in HANDOVER REQUEST ACKNOWLEDGE message, which would use this information as specified in TS 37.340[8 ].
[…]
For each PDU session in which the security indication IE is contained in the PDU session resource list IE to be established and the integrity protection indication IE or confidentiality protection indication IE is set to "required", the target NG-RAN node will perform user plane integrity protection or ciphering, respectively. If the NG-RAN node is not able to perform user plane integrity protection or ciphering, it will refuse the establishment of PDU session resources with the appropriate cause value.
If the NG-RAN node is a NG-eNB, it will reject all PDU sessions in which the integrity protection indication IE is set to "required".
For each PDU session in which the security indication IE is included in the PDU session resource list IE to be established and the integrity protection indication IE or confidentiality protection indication IE is set to "preferred", the target NG-RAN node shall (if supported) perform user plane integrity protection or ciphering, respectively, and will inform the SMF whether it successfully performs user plane integrity protection or ciphering for the security policy concerned.
For a security indication IE in which the maximum integrity protected data proportion IE is contained in the PDU session resource list IE to be established, the NG-RAN node will store the corresponding information and if integrity protection is to be performed for the PDU session it will force the execution of the traffic for the involved PDU session and the involved UE corresponding to the received maximum integrity protected data proportion IE as specified in TS23.501[7 ].
For each PDU session in which the security indication IE is included in the PDU session resource list to be established and the integrity protection indication IE or confidentiality protection indication IE is set to "not needed", the target NG-RAN node will perform user plane integrity protection or ciphering, respectively, for the involved PDU session.
For each PDU session, if an additional UL NG-U UP TNL information list IE is included in the PDU session resource list IE to be established contained in the HANDOVER REQUEST message, the target NG-RAN node may forward UP transport layer information to the target S-NG-RAN node as an uplink termination point for user plane data split in different tunnels for this PDU session.
If the location reporting information IE is contained in the HANDOVER REQUEST message, the target NG-RAN node should initiate the requested location reporting function as defined in TS 38.413[5 ].
After receiving the UE history information IE in the HANDOVER REQUEST message, the target NG-RAN node will collect the information defined as mandatory in the UE history information IE and (if supported) will collect the information defined as optional in the UE history information IE as long as the UE remains in one of its cells and store the collected information as ready for future HANDOVER.
[…]
If the HANDOVER REQUEST message contains a management based MDT PLMN list IE, the target NG-RAN node should (if supported) store it in the UE context and consider if it contains information about the PLMN serving the UE in the target NG-RAN node.
If the mobility information IE is provided in a HANDOVER REQUEST message, the target NG-RAN node will (if supported) store this information. If supported, the target NG-RAN will store the C-RNTI allocated at the source cell as received in the HANDOVER REQUEST message.
After receiving the UE history information IE from the UE in the HANDOVER REQUEST message, the target NG-RAN node will (if supported) store the collected information and use it for future HANDOVER preparation.
For each QoS flow that has been successfully established in the target NG-RAN node, if the QoS listening REQUEST IE is contained in the QoS flow level QoS parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node will store this information and (if supported) will perform delay measurements and QoS listening as specified in TS23.501[7 ]. If the QoS listening reporting frequency IE is contained in the QoS flow level QoS parameters IE contained in the HANDOVER REQUEST message, the target NG-RAN node will store this information and (if supported) will use this information for RAN part delay reporting.
If the 5GC mobility restriction list container IE is included in the HANDOVER REQUEST message, the target NG-RAN node should (if supported) store this information in the UE context and use it as specified in TS 38.300[9 ].
[…]
If the maximum number of CHO prepared IEs is contained in the conditional handover information confirm IEs contained in the HANDOVER REQUEST ACKNOWLEDGE message, then the source NG-RAN node should not prepare more candidate target cells for CHO for the target NG-RAN node than indicated in the IEs for the same UE.
If the estimated arrival probability IE is contained in the conditional HANDOVER information REQUEST IE in the HANDOVER REQUEST message, the target NG-RAN node may use this information to allocate the required resources for the incoming CHO.
[…]
If the UE radio capability ID IE is contained in the HANDOVER REQUEST message, the target NG-RAN node should (if supported) store this information in the UE context and use it, as defined in TS23.501[7] and TS23.502[13 ].
If the source DL forwarding IP address IE is contained within the data forwarding and offloading information IE from the source NG-RAN node in the PDU session resource list to be established IE contained in the HANDOVER REQUEST message for a given QoS flow, the target NG-RAN node should (if supported) store this information and use it as part of its ACL function configuration actions (if such ACL functions are deployed).
[…]
If the time synchronization assistance information IE is contained in the HANDOVER REQUEST message, the target NG-RAN node should (if supported) store this information in the UE context and use it, as defined in TS23.501[7 ].
If the QMC configuration information IE is contained in the HANDOVER REQUEST message, the target NG-RAN node should (if supported) consider the QoE measurement process as described in TS 38.300[9 ].
If the UE slice-maximum bit rate list IE is contained in the HANDOVER REQUEST message, the target NG-RAN node stores (if supported) the received UE slice maximum bit rate list in the UE context and uses the received UE slice maximum bit rate values for each S-NSSAI of the relevant UE as specified in TS23.501[7 ].
[…]
8.2.1.3 Unsuccessful operation
Fig. 12 is a rendition of fig. 8.2.1.3-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": switching preparation, unsuccessful operation.
If the target NG-RAN node does not admit at least one PDU session resource or fails during handover preparation, the target NG-RAN node sends HANDOVER PREPARATION FAILURE a message to the source NG-RAN node. The message should contain a cause IE with an appropriate value.
If the conditional HANDOVER information REQUEST IE is contained in the HANDOVER REQUEST message and the target NG-RAN node refuses the HANDOVER or fails during HANDOVER preparation, the target NG-RAN node will include the requested target cell ID IE in the HANDOVER PREPARATION FAILURE message.
Interaction with the handover cancel procedure:
If there is no response by the target NG-RAN node to the HANDOVER REQUEST message before timer TXn RELOCprep expires in the source NG-RAN node, the source NG-RAN node should cancel the HANDOVER preparation procedure for the target NG-RAN node by initiating a HANDOVER cancellation procedure with an appropriate value for the cause IE. The source NG-RAN node will ignore any HANDOVER REQUEST ACKNOWLEDGE message or HANDOVER PREPARATION FAILURE message received after the handover cancel procedure initiation and remove any references and release any resources related to the related Xn UE associated signaling.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
9.1.1.1 Handover request
This message is sent by the source NG-RAN node to the target NG-RAN node to request preparation of resources for handover.
The direction is: source NG-RAN node→target NG-RAN node.
/>
/>
| VIII-conditions | IX-interpretation |
| ifCHOmod | If a CHO trigger IE exists and is set to "CHO-replace," then this IE will exist. |
| X-Range Limit | XI-interpretation |
| maxnoofMDTPLMNs | Based on the PLMN list in the managed MDT PLMN list. The value is 16. |
9.1.1.2 Handover request acknowledgement
This message is sent by the target NG-RAN node to inform the source NG-RAN node about the prepared resources at the target.
The direction is: target NG-RAN node→source NG-RAN node.
* The reference and reference are used to refer to the same or different reference and are used to refer to the same reference and different reference
This IE is used to globally identify the NR cell (see TS 38.300[9 ]).
* The reference and the reference are the same, and the reference is the same
9.2.3.25 Target cell Global ID
This IE contains NR CGI or E-UTRA CGI.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
8.4.1Xn establishment
8.4.1.1 General description
The purpose of the Xn setup procedure is to exchange the application level configuration data required by the two NG-RAN nodes to properly interoperate over the Xn-C interface.
[…]
The procedure uses non-UE associated signaling.
8.4.1.2 Successful operation
Fig. 13 is a reproduction of fig. 8.4.1.2 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": xn is established and successfully operated.
The NG-RAN node 1 initiates the procedure by sending an XN setup request message to the candidate NG-RAN node 2. Candidate NG-RAN node 2 replies with an XN setup response message.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
8.4.2NG-RAN node configuration update
8.4.2.1 General description
The purpose of the NG-RAN node configuration update procedure is to update the application level configuration data required by both NG-RAN nodes to properly interoperate over the Xn-C interface.
Note that: in the case where the SN (i.e., the gNB) does not broadcast system information other than radio frame timing and SFN, the update of the application level configuration data also applies between two NG-RAN nodes, as specified in TS 37.340[8 ]. It is not explicitly specified how this information is used when this option is used.
The procedure uses non-UE associated signaling.
8.4.2.2 Successful operation
Fig. 14 is a rendition of fig. 8.4.2.2-1 from 3GPP TS 38.423 V17.2.0, "NG-RAN, xn application protocol (XnAP)": and updating the configuration of the NG-RAN node, and successfully operating.
NG-RAN node 1 initiates the procedure by sending an NG-RAN node configuration update message to peer NG-RAN node 2
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
Handover preparation via NG interface is specified in TS 38.413 ([ 7]3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)"):
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole or in combination with a substance, such as a substance, or a combination of substances
8.4.1 Handover preparation
8.4.1.1 General description
The purpose of the handover preparation procedure is to request the preparation of resources via 5GC on the target side. For a certain UE, only one handover preparation procedure is performed simultaneously. The procedure uses UE-associated signaling.
8.4.1.2 Successful operation
Fig. 15 is a rendition of fig. 8.4.1.2-1 from 3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)": switching preparation: successful operation.
The source NG-RAN node initiates handover preparation by sending HANDOVER REQUIRED a message to the serving AMF. When the source NG-RAN node sends HANDOVER REQUIRED a message, it will start timer TNG RELOCprep. The source NG-RAN node will indicate the appropriate cause value for the handover in the cause IE.
Upon receipt of HANDOVER REQUIRED messages, for each PDU session indicated in the PDU session ID IE, the AMF will transparently migrate the handover required migration IE to the SMF associated with the involved PDU session.
In case of intra-system handover, the information in the source to target transparent container IE will be encoded according to the definition of the source NG-RAN node to target NG-RAN node transparent container IE.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
8.4.2 Handover resource allocation
8.4.2.1 General description
The purpose of the handover resource allocation procedure is to reserve resources at the target NG-RAN node for handover of the UE. The procedure uses UE-associated signaling.
8.4.2.2 Successful operation
FIG. 16 is a diagram from 3GPP TS 38.413 V17.2.0, "NG-RAN, NG application protocol (NGAP)"
8.4.2.2-1 Reproduction: switching resource allocation: successful operation.
The AMF initiates the procedure by sending a HANDOVER REQUEST message to the target NG-RAN node.
* The reference and the reference are used to describe the following elements, which are not intended to limit the scope of the invention
9.2.3.1 Handover requirement
This message is sent by the source NG-RAN node to the AMF to request preparation of the resource at the target.
The direction is: NG-RAN node→amf.
| Range boundaries | Interpretation of the drawings |
| maxnoofPDUSessions | The maximum number of PDU sessions allowed for one UE. The value is 256. |
9.2.3.2 Switch command
This message is sent by the AMF to inform the source NG-RAN node that resources for handover are ready on the target side.
The direction is: amf→ng-RAN node.
| Range boundaries | Interpretation of the drawings |
| maxnoofPDUSessions | The maximum number of PDU sessions allowed for one UE. The value is 256. |
[…]
9.2.3.4 Handover request
This message is sent by the AMF to the target NG-RAN node to request preparation of the resource.
The direction is: amf→ng-RAN node.
/>
/>
| Range boundaries | Interpretation of the drawings |
| maxnoofPDUSessions | The maximum number of PDU sessions allowed for one UE. The value is 256. |
9.2.3.5 Handover request acknowledgement
This message is sent by the target NG-RAN node to inform the AMF about the prepared resources at the target.
The direction is: NG-RAN node→amf.
| Range boundaries | Interpretation of the drawings |
| maxnoofPDUSessions | The maximum number of PDU sessions allowed for one UE. The value is 256. |
[…]
9.3.1.20 Source to target transparent Container
This IE is used to transparently pass radio related information from the handover source to the handover target through the core network; which is generated by the source RAN node and transmitted to the target RAN node.
* The term "x" and "x" refer to the same or different amounts of a substance, such as a substance, or substance, to be treated as a whole
In release 17 New Radio (NR) (e.g., [3]3GPP TS 38.300 V17.2.0) a non-terrestrial network (NTN) is introduced, which is defined as a next generation radio access network (NG-RAN) consisting of next generation node bs (gnbs) that provide non-terrestrial access to User Equipment (UE) by means of NTN payloads embodied on an on-board or off-load NTN vehicle and NTN gateway. The UE may be linked to, camped on, and/or connected to an NTN network involving on-board/off-load for transmission. NTNs may include various platforms, including Low Earth Orbit (LEO) satellites, medium Earth Orbit (MEO) satellites, high Elliptical Orbit (HEO) satellites, geostationary orbit (GEO) satellites, geostationary orbit (GSO) satellites, non-geostationary orbit (NGSO) satellites, and/or high altitude communication platforms (HAPS). LEO satellites may have an earth fixed beam (e.g., a beam that is temporarily fixed in a position over a period of time) or an earth moving beam (e.g., a beam that moves continuously along with the satellite). LEO satellites may serve/provide earth-moving cells (e.g., with earth-fixed beams) and/or (quasi) earth-fixed cells (e.g., with earth-moving beams). NTN may provide large area coverage in situations where a Terrestrial Network (TN) is not feasible (e.g., desert, polar, and/or on-board), and provide Network (NW) access.
Enhancements to NR NTN will be introduced in 3GPP release 18 (e.g., [1] RP-221819). A large number of UEs will need to perform handover in the serving cell, e.g. due to large cell size, satellite movement. Based on section 7.3.2.1.4 in TR 38.821 (e.g., [4]3GPP TS 38.331 V17.2.0 ]), the total number of handovers per second will cause significant signaling/stripping load in the network. Frequent handovers may cause signaling overhead for the UE and affect power consumption.
To reduce signaling for handovers, e.g., especially for earth mobile cells, the network may perform some handover enhancements, e.g., public handovers, group handovers, and/or 2-step handovers. The common target cell configuration will be provided via broadcast. In NTN, the next serving cell may be predicted by the network based on satellite ephemeris and negligible UE mobility compared to satellite motion. Most UEs in the source cell will perform a handover to the same target cell, and most of the information provided to each UE in a Handover (HO) command (e.g., servingCellConfigCommon) describing the target cell configuration is the same. It is assumed that the common handover may comprise at least two different kinds of signaling and/or configuration: a configuration common to all UEs to be handed over (e.g., broadcast in a System Information Block (SIB)) and a configuration specific to the UE (e.g., provided in dedicated signaling). In common handover, group handover, and/or 2-step handover, the network may provide common signaling and/or configuration to the UE, multiple UEs, or a group of UEs. In group handover and/or 2-step handover, the network may provide a UE-specific (pre) configuration of the target cell to each UE, then a group indication to multiple UEs. A specific target cell configuration, such as a cell radio network temporary identifier (C-RNTI) or security key, may be sent to each UE in a dedicated manner. The UE may receive a dedicated configuration (e.g., specific to the UE) and/or a common configuration (e.g., common to the UE for accessing the target cell, specific to the target cell) for handover. Upon receiving the group indication, the UE may trigger a handover procedure. The UE may trigger the handover procedure when both a common configuration (e.g., the second configuration as follows) and a dedicated configuration (e.g., the first configuration as follows) are received.
Conventional handoff procedures can be found in TS 38.300 (e.g., [3]3GPP TS 38.300 V17.2.0) and TS 38.423 (e.g., [5]3GPP TS 38.423 V17.2.0). As shown in fig. 6 (fig. 9.2.3.1-1 from [3]3GPP TS 38.300 V17.2.0), the source gNB will decide to perform the HANDOVER procedure for the UE and transmit a HANDOVER REQUEST (e.g., HANDOVER REQUEST) to the target gNB. The HANDOVER REQUEST (e.g., HANDOVER REQUEST) will include the UE information. In response to receiving the HANDOVER REQUEST (e.g., HANDOVER REQUEST), the target gNB transmits a HANDOVER REQUEST acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE) to the source gNB. The handover request acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE) will include the resources for the handover of the UE. The handover request acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE) will include the handover command (e.g., handoverCommand). In response to receiving the handover request acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE), the source gNB transmits a Radio Resource Control (RRC) reconfiguration message (e.g., RRCReconfiguration) from the handover command (e.g., handoverCommand) to the UE. In response to receiving the RRC reconfiguration message (e.g., RRCReconfiguration), the UE will trigger the handover procedure and transmit an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete) to the target gNB.
Throughout the disclosure herein, the HANDOVER REQUEST (message) may be, be referred to as, or include a HANDOVER REQUEST. The handover request acknowledgement (message) may be, be referred to as, or include HANDOVER REQUEST ACKNOWLEDGE.
Based on the current specifications as described above, the source gNB will perform handover preparation of the UE to request resources from the target gNB before transmitting an RRC reconfiguration message (e.g., RRCReconfiguration) to the UE. In order to trigger a handover, the source gNB needs to perform a handover preparation procedure for the UE with the target gNB. In handover preparation, the source gNB transmits a handover request with UE context information to the target gNB and receives a handover request acknowledgement from the target gNB. A handover command, RRC reconfiguration message (e.g., RRCReconfiguration) with a dedicated configuration (e.g., UE-specific configuration), to be transmitted to the UE will be provided by the target gNB in the handover request acknowledgement. The target gNB generates a handover command (i.e., RRCReconfiguration with reconfigureWithSync) and communicates it to the source gNB via HANDOVER REQUEST ACKNOWLEDGE. The source gNB will forward the handover command to the UE without modification. The source gNB forwards RRCReconfiguration from HandoverCommand in HANDOVER REQUEST ACKNOWLEDGE directly to the UE.
However, to apply common handover, group handover, and/or 2-step handover, the source gNB may not provide handover commands (e.g., configuration for handover) as a whole. Alternatively, different portions of the handover command (e.g., configuration for handover) may be provided separately to the UE. In this case, the source gNB may not deliver the handover command (e.g., configuration for handover) by forwarding the handover command (e.g., configuration for handover) generated by the target gNB as in the current handover procedure and/or handover preparation. If the source gNB REQUESTs a dedicated part configuration for a common HANDOVER via a HANDOVER REQUEST, the same message may be used to REQUEST a dedicated part for a HANDOVER configuration or a legacy HANDOVER configuration. Based on the current HANDOVER REQUEST, the target gNB does not know the type of HANDOVER of the source gNB requested (i.e., whether the target gNB should contain a common part in the HO command).
Examples for common handover (and/or group handover, 2-step handover) are provided in 3gpp RAN2 conference. As shown in fig. 17, the source gNB may transmit a first handover command with a UE-specific configuration to a first UE and a second handover command with a UE-specific configuration to a second UE. Subsequently, the source gNB may transmit a group switch command to both the first UE and the second UE. After transmitting the group switch command, the source gNB and the target gNB perform group switch preparation. However, in this case, the source gNB may not receive the handover resources at the target gNB before performing the handover preparation. The source gNB may not communicate the dedicated configuration and/or the common configuration to the UE in any handover command.
Throughout the disclosure herein, a UE may be one UE in a group of UEs. The UE may be connected to the NTN cell. The UE may be connected to an earth moving cell. The UE group may be configured by the network. Multiple UE groups may exist in a serving cell. There may be multiple UEs in a UE group. The UEs in the same group will be instructed to perform the handover and/or receive the common configuration (for the handover) at the same time.
Throughout the disclosure herein, the source gNB may be the (current) serving UE. The source gNB may serve the UE prior to the (group) handover procedure. The source gNB may serve the source cell. The source gNB may determine to trigger a (group) handover procedure. The source gNB may determine the group of UEs. The source gNB may provide configuration and/or information of the UE group, e.g., to the UE, to the target gNB. The source gNB may transition the UE to the target gNB. The target gNB may serve the UE after the handover procedure. The target gNB may serve the target cell. The UE may be handed over from the source cell to the target cell. The UE may switch from a source gNB to a target gNB. The source gNB and the target gNB may be different gNBs. The source gNB and the target gNB may be linked to the same satellite or different satellites. The source cell and the target cell may be the same cell or different cells. Throughout the disclosure herein, a handover may be or may be referred to as a public handover, a group handover, a 2-step handover, and/or a handover in NTN.
Throughout the disclosure herein, the target gNB may be replaced by an access and mobility management function (AMF). For example, for a handover between gnbs having an Xn interface (e.g., a point-to-point interface between two NG-RAN nodes), the message (and/or configuration) exchanges described in this disclosure may be performed via the Xn interface between the source gNB and the target gNB. For handovers between gnbs without an Xn interface, message (and/or configuration) exchanges may be performed between the source gNB and the AMF.
Throughout the disclosure herein, a handover may be a change of a primary cell (PCell) of a UE in (at least) rrc_connected. The handover may be NW triggered or Conditional Handover (CHO). The handover may be or may be referred to as a public handover, a group handover, a 2-step handover, and/or a handover in NTN.
Throughout the disclosure herein, a handover command may be an indication to trigger a handover. The handover command may (or may include) be used for (all or at least part of the configuration of) the handover. The handover command may be (or include) an RRC reconfiguration message (e.g., RRCReconfiguration) with ReconfigurationWithSync for the PCell.
Throughout the disclosure herein, the first signaling, the second signaling, and/or the third signaling may be signaling and/or messages transmitted from the source gNB to the UE. The source gNB may transmit the first signaling in response to the first handover preparation. The source gNB may transmit the first configuration in the first signaling. In response to the first handover preparation and/or the second handover preparation, the source gNB may transmit (or broadcast) second signaling. The source gNB may transmit the second configuration in the first signaling. In response to the first handover preparation and/or the second handover preparation, the source gNB may transmit (or broadcast) third signaling.
The first configuration, the second configuration, and/or the third configuration may be (or include) a handover configuration. The first configuration and/or the second configuration may be (or include) a configuration for handover (e.g., to a target cell or a gNB). The first configuration, the second configuration, and/or the third configuration may be provided from the target gNB. The first configuration, the second configuration, and/or the third configuration may be provided in a handover command (e.g., handoverCommand). The second configuration may be derived by the source gNB. The second configuration may be part of the first configuration and/or the third configuration. The second configuration may not be part of the first configuration. The first configuration and/or the second configuration may be or include resources reserved at the target gNB for handover.
The first configuration may be or include a dedicated configuration and/or a UE-specific configuration, e.g., in the current specification (e.g., [4]3GPP TS 38.331 V17.2.0 "). The first configuration may be provided to the UE via dedicated signaling, e.g., in the current specification (e.g., [4]3GPP TS 38.331 V17.2.0). The first configuration may be transmitted to a UE (e.g., a single UE). The first configuration may be applied to a particular UE. The first configuration may not be a cell specific configuration. The first configuration may be a configuration specific to the group of UEs. The first configuration may not be common to the cells. The first configuration may be common to the group of UEs. The first configuration may be specific to the UE. The first configuration may be an RRC reconfiguration message (e.g., RRCReconfiguration) and/or a portion of an RRC reconfiguration message (e.g., RRCReconfiguration) and/or a portion of an RRC reconfiguration message (e.g., RRCReconfiguration). The first configuration may be or include the configuration in reconfigurationWithSync in addition to spCellConfigCommon (or ServingCellConfigCommon) and/or NTN-Config. In addition to the second configuration, the first configuration may be (or include) one or more configurations in an RRC reconfiguration message (e.g., RRCReconfiguration) with reconfigurationWithSync (for PCell). The first configuration may be (or include): NTN configuration (e.g., NTN-config), common serving cell configuration (e.g., for PCell、ServingCellConfigCommon、spCellConfigCommon)、t304、smtc、daps-UplinkPowerConfig、sl-PathSwitchConfig、rlf-TimersAndConstants、rlmInSyncOutOfSyncThreshold、lowMobilityEvaluationConnected、goodServingCellEvaluationRLM、goodServingCellEvaluationBFD、deactivatedSCG-Config、newUE-Identity、rach-ConfigDedicated、servCellIndex and/or spCellConfigDedicated).
The second configuration may be or include a public configuration and/or a group configuration. The second configuration may be or include a cell-specific configuration, e.g., in the current specification (e.g., [4]3GPP TS 38.331 V17.2.0). The second configuration may be or include a public configuration and/or a group configuration. The second configuration may be provided to the UE via common signaling, e.g., broadcast, multicast, system information. The second configuration may be transmitted to a plurality of UEs (e.g., more than one UE). The second configuration may be common to the UE to access the target cell. The second configuration may not be common to the cells. The second configuration may be applied to UEs in the same cell. The second configuration may be or include a serving cell configuration (e.g., servingCellConfigCommon) and/or an NTN configuration (e.g., NTN-Config). The second configuration may be or include a portion of an RRC reconfiguration message (e.g., RRCReconfiguration), a serving cell configuration (e.g., servingCellConfigCommon), an NTN configuration (e.g., NTN-Config), a Downlink (DL) configuration (e.g., downlinkConfigCommon), and/or an Uplink (UL) configuration (e.g., uplinkConfigCommon). The second configuration may be part of the first configuration. The second configuration may not be part of the first configuration. In addition to the first configuration, the second configuration may be (or include) one or more configurations in an RRC reconfiguration message (e.g., RRCReconfiguration) with reconfigurationWithSync (for PCell). The second configuration may be (or include): NTN configuration (e.g., NTN-config), common serving cell configuration (e.g., for PCell、ServingCellConfigCommon、spCellConfigCommon)、t304、smtc、daps-UplinkPowerConfig、sl-PathSwitchConfig、rlf-TimersAndConstants、rlmInSyncOutOfSyncThreshold、lowMobilityEvaluationConnected、goodServingCellEvaluationRLM、goodServingCellEvaluationBFD、deactivatedSCG-Config、newUE-Identity、rach-ConfigDedicated、servCellIndex and/or spCellConfigDedicated).
The third configuration may be (or include) one or more configurations in an RRC reconfiguration message (e.g., RRCReconfiguration) with reconfigurationWithSync (for PCell). The third configuration may be (or include) all configurations in an RRC reconfiguration with reconfigurationWithSync (for PCell). The third configuration may be (or include) the first configuration and/or the second configuration. The third configuration may be (or include): NTN configuration (e.g., NTN-config), common serving cell configuration (e.g., for PCell、ServingCellConfigCommon、spCellConfigCommon)、t304、smtc、daps-UplinkPowerConfig、sl-PathSwitchConfig、rlf-TimersAndConstants、rlmInSyncOutOfSyncThreshold、lowMobilityEvaluationConnected、goodServingCellEvaluationRLM、goodServingCellEvaluationBFD、deactivatedSCG-Config、newUE-Identity、rach-ConfigDedicated、servCellIndex and/or spCellConfigDedicated).
The source gNB may receive the first configuration and/or the second configuration in a handover command (e.g., handoverCommand), an RRC reconfiguration message (e.g., (part of) RRCReconfiguration), and/or a new RRC message. The handover command (e.g., handoverCommand), the (part of the) RRC reconfiguration message (e.g., RRCReconfiguration), and/or the new RRC message may be transmitted in the handover request acknowledgement.
The first signaling, the second signaling, and/or the third signaling may be signaling and/or messages transmitted from the network to the UE. The network may transmit the first configuration in the first signaling. The network may transmit the second configuration in second signaling.
The first signaling may be dedicated signaling and/or UE-specific signaling. The first signaling may be transmitted to a single UE. The first signaling may be an RRC message, a Medium Access Control (MAC) Control Element (CE), or Downlink Control Information (DCI). The first signaling may be an RRC reconfiguration message (e.g., RRCReconfiguration) and/or a handover command. The first signaling may be and/or include, for example, a dedicated configuration (e.g., a first configuration) for the UE. The first signaling may be a handover configuration. The first signaling may provide resources to the UE.
The first signaling, the second signaling, and the third signaling may be different.
The second signaling may be common signaling and/or group signaling. The second signaling may be transmitted or broadcast to the plurality of UEs. The second signaling may be an RRC message, MAC CE, or DCI. The second signaling may be an RRC reconfiguration message (e.g., RRCReconfiguration), a handover command, system information (e.g., SIB 19), and/or a paging message. The second signaling may be and/or include, for example, a common configuration (e.g., servingCellConfigCommon, second configuration) for the plurality of UEs. The second signaling may be a (group) handover configuration and/or a (group) handover indication. The second signaling may be third signaling. The second signaling may provide resources to the UE (group) for handover.
The third signaling may be common signaling and/or group signaling. The third signaling may be transmitted or broadcast to the plurality of UEs. The third signaling may be an RRC message, MAC CE, or DCI. The third signaling may be DCI, an RRC reconfiguration message (e.g., RRCReconfiguration), a handover command, system information (e.g., SIB 19), and/or a paging message. The third signaling may not include or may not be configured for handover. The third signaling may be a (group) switch indication. The third signaling may be second signaling. The third signaling may trigger a handover procedure for the UE (group).
To address the problem, the target gNB may separately (e.g., in different messages, in different message containers) provide different portions (e.g., more than one portion) of the configuration for the handover (e.g., a first configuration for the handover and a second configuration for the handover) to the source gNB. The target gNB may provide the first configuration without the second configuration for handover to the source gNB in a message (or message container). The target gNB may provide a second configuration for handover in a message (or message container) to the source gNB without the first configuration.
For example, the source gNB may receive two handover configurations (e.g., a first configuration for handover and a second configuration for handover) from the target gNB, such as in a handover request acknowledgement. The source gNB may communicate the handover request to the target gNB. In response to transmitting the handover request, the source gNB may receive (e.g., from the target gNB) the first configuration and the second configuration in one message or message container (e.g., handoverCommand). In response to transmitting the handover request, the source gNB may receive (e.g., from the target gNB) a first configuration in a first message or message container (e.g., handoverCommand) and a second configuration in a second message or message container (e.g., handoverCommand). A message or message container (e.g., handoverCommand) may be received in a HANDOVER REQUEST acknowledgement, for example, corresponding to a HANDOVER REQUEST (e.g., HANDOVER REQUEST).
The source gNB may send the first configuration to the UE in first signaling. The first configuration and/or the first signaling may be generated by the target gNB and forwarded by the source gNB to the UE. The source gNB may send the second configuration to the UE or the group of UEs in second signaling. The second configuration and/or second signaling may be generated by the target gNB and forwarded by the source gNB to the UE or group of UEs.
In response to transmitting the handover request for the first UE, the source gNB may receive (e.g., from the target gNB) a second configuration. In response to transmitting the handover request for the second UE and the third UE, the source gNB may not receive (e.g., from the target gNB) the second configuration. In response to receiving the second configuration, the gNB may transmit the second configuration to the first UE, the second UE, and/or the third UE. The first UE, the second UE, and the third UE may belong to the same UE group. In response to receiving the second configuration, the gNB may not transmit the second configuration to the fourth UE. The fourth UE and the first UE may belong to different UE groups. The first UE, the second UE, and the third UE may switch to the target gNB. The first UE, the second UE, and the third UE may perform group handover and/or 2-step handover. The fourth UE may not switch to the target gNB. The fourth UE may not perform group handover and/or 2-step handover.
In view of the fact that there may be more than one kind of configuration for handover (e.g., first configuration, second configuration, legacy configuration such as a handover command, configuration for group handover, configuration for legacy handover) that configuration may be provided to source gNB, target gNB may need to know what configuration should be provided in response to a request from source gNB. To this end, the source gNB may indicate to the target gNB (e.g., in a handover request) which configuration for the handover target gNB should be provided as a response. The handover request may include an indication indicating which configuration for handover should be provided in response. The configuration categories for handover may include: a first configuration (e.g., a portion of a handover configuration to be provided to the UE via dedicated signaling), a second configuration (e.g., a portion of a handover configuration to be provided to the UE via common signaling), a legacy handover configuration (e.g., a handover command including a common portion and a dedicated portion of the handover configuration).
The source gNB may instruct the target gNB to provide the second configuration through a handover request. The source gNB may provide an indication in the handover request. The indication may be a parameter and/or a boolean value. The indication may be UE information and/or (target) cell information. The source gNB may provide UE information to request the first configuration. The source gNB may provide (target) cell information to request the second configuration.
To address the problem, a handover command or handover configuration (e.g., first configuration and/or first signaling, second configuration and/or second signaling) to be sent to the UE may be generated by the source gNB (rather than generated by the target gNB and forwarded to the UE by the source gNB). For example, the source gNB may receive the first configuration from the handover request acknowledgement and derive a handover configuration (to be sent to the UE) from the first configuration. The source gNB may communicate the handover request to the target gNB. In response to transmitting the handover request, the source gNB may receive (e.g., from the target gNB) a first configuration in a message or message container (e.g., handoverCommand). A message or message container (e.g., handoverCommand) may be received in a handover request acknowledgement, for example, corresponding to a handover request. The source gNB may not (directly) forward the received first configuration to the UE.
In response to receiving the first configuration, the source gNB may derive a second configuration from the first configuration for the UE or the group of UEs. The source gNB may send a first configuration without the second configuration (e.g., omitting the content of the second configuration in the first configuration) to the UE in the first signaling. The source gNB may send the second configuration to the UE or the group of UEs in second signaling.
In response to receiving the first configuration, the source gNB may divide the first configuration into first signaling and second signaling for the UE or the group of UEs. The source gNB may send a first configuration without the second configuration (e.g., omitting the content of the second configuration in the first configuration) to the UE in the first signaling. The source gNB may send the second configuration to the UE or the group of UEs in second signaling.
In response to receiving the first configuration, the source gNB may configure and/or generate first signaling and second signaling for the UE or the group of UEs. The source gNB may send a first configuration without the second configuration (e.g., omitting the content of the second configuration in the first configuration) to the UE in the first signaling. The source gNB may send the second configuration to the UE or the group of UEs in second signaling.
In response to transmitting the handover request for the first UE, the source gNB may receive a first configuration with content of a second configuration. In response to transmitting a handover request for the second UE and the third UE, the source gNB may receive a first configuration having content of the second configuration. In response to receiving the second configuration, the gNB may transmit the second configuration to the first UE, the second UE, and/or the third UE. The first UE, the second UE, and the third UE may belong to the same UE group. In response to receiving the second configuration, the gNB may not transmit the second configuration to the fourth UE. The fourth UE and the first UE may belong to different UE groups. The first UE, the second UE, and the third UE may switch to the target gNB. The first UE, the second UE, and the third UE may perform group handover and/or 2-step handover. The fourth UE may not switch to the target gNB. The fourth UE may not perform group handover and/or 2-step handover.
The source gNB may indicate whether the target gNB provides the contents of the second configuration (in the first configuration) through a handover request. The source gNB may provide an indication in the handover request. The indication may be a parameter and/or a boolean value. The indication may be UE information and/or (target) cell information. The source gNB may provide (target) cell information to request (the content of) the second configuration.
Fig. 18 provides an example for the above concepts.
To address the problem, the source gNB may perform (at least) two handover preparations (e.g., a first handover preparation and a second handover preparation) for a handover, such as a common handover, a group handover, and/or a 2-step handover. The source gNB may perform two handover preparations (e.g., a first handover preparation and a second handover preparation) for (at least) one UE, e.g., in a group of UEs. The (two) handover preparations are associated with the same (target) cell Identification (ID). The two handover preparations may or may not be in parallel. The two handover preparations may or may not be associated with the same (source) UE ID. Two handover preparations may be performed to handover the UE group. Two handover preparations may be performed to provide common resources and/or configuration for the UE group. The source gNB may receive (e.g., from the target gNB) a first configuration in a first handover preparation. The source gNB may receive the second configuration in a second handover preparation.
The source gNB may transmit the first handover request to the target gNB in a first handover preparation. In response to receiving the first handover request, the target gNB may transmit a first handover request acknowledgement including the first configuration to the source gNB. In response to receiving the first handover request acknowledgement, the source gNB may transmit first signaling with a first configuration to the UE. The first signaling may be generated by the target gNB. The first signaling may be forwarded by the source gNB to the UE. After transmitting the first signaling, the source gNB may transmit a second handover request to the target gNB in a second handover preparation. In response to receiving the second handover request, the target gNB may transmit a second handover request acknowledgement including the second configuration to the source gNB. In response to receiving the second handover request acknowledgement, the source gNB may transmit second signaling with a second configuration to the UE group. The second signaling may be generated by the target gNB. The second signaling may be forwarded by the source gNB to the UE or the group of UEs. After transmitting the second signaling, the source gNB may transmit third signaling to the UE group.
The source gNB may transmit a second handover request to the target gNB in a second handover preparation. In response to receiving the second handover request, the target gNB may transmit a second handover request acknowledgement including the second configuration to the source gNB. In response to receiving the second handover request acknowledgement, the source gNB may transmit second signaling with a second configuration to the UE group. The second signaling may be generated by the target gNB. The second signaling may be forwarded by the source gNB to the UE or the group of UEs. After transmitting the second signaling, the source gNB may transmit a first handover request to the target gNB in a first handover preparation. In response to receiving the first handover request, the target gNB may transmit a first handover request acknowledgement including the first configuration to the source gNB. In response to receiving the first handover request acknowledgement, the source gNB may transmit first signaling with a first configuration to the UE. The first signaling may be generated by the target gNB. The first signaling may be forwarded by the source gNB to the UE. After transmitting the first signaling, the source gNB may transmit third signaling to the UE group.
The source gNB may perform a first handover preparation for each UE in the group of UEs. The source gNB may perform a second handover preparation for the UE group. In the group handover procedure, the source gNB may perform one first handover preparation and a plurality of second handover preparations. The source gNB may perform a first handover preparation for the first UE. The source gNB may not perform the first handover preparation for the second UE and the third UE. In response to receiving the second configuration, the gNB may transmit the second configuration to the first UE, the second UE, and/or the third UE. The first UE, the second UE, and the third UE may belong to the same UE group. In response to receiving the second configuration, the gNB may not transmit the second configuration to the fourth UE. The fourth UE and the first UE may belong to different UE groups. The first UE, the second UE, and the third UE may switch to the target gNB. The first UE, the second UE, and the third UE may perform group handover and/or 2-step handover. The fourth UE may not switch to the target gNB. The fourth UE may not perform group handover and/or 2-step handover.
The source gNB may not transmit the handover request in a handover preparation (e.g., a second handover preparation). The handover request may be omitted or skipped in a handover preparation (e.g., a second handover preparation). The source gNB may receive the handover request acknowledgement and/or the message including the second configuration without transmitting the handover request. The source gNB may receive the second configuration without transmitting the handover request. The target gNB may provide the second configuration without receiving the handover request. The source gNB may receive the second configuration before or after performing the first handover preparation. The source gNB may receive the second configuration without performing handover preparation. The source gNB may receive common resources (e.g., a second configuration) of the target cell without providing the UE information. The target gNB may provide common resources of the target cell (e.g., a second configuration for group handover) without acquiring and/or receiving UE information. In response to receiving the second configuration, the source gNB may broadcast or transmit second signaling to the group of UEs.
The target gNB may transmit the second configuration and/or a message comprising the second configuration if (or based on) one or more of the following conditions are met:
-a first HO preparation has been performed;
-the second configuration is available or updated;
-the UE group is configured;
-the target cell is an NTN cell or an earth moving cell;
-the source cell is an NTN cell or an earth moving cell;
The target gNB has not yet provided a second configuration for the target cell;
-the target gNB has transmitted a first configuration for one UE of the group of UEs; and/or
The target gNB has received an indication of the group/common handover from the source gNB (e.g., in a handover request).
Fig. 19 provides an example for the above concepts.
An example is shown in fig. 20. The source gNB requests a common portion (e.g., a second configuration) of the handover configuration without (or with) the UE context information. The target gNB provides a common handover configuration (e.g., a second configuration) without receiving the UE context information (or in response to receiving the plurality of UE context information). The source gNB transmits the request signal without UE context information (or with multiple UE context information). The request signal may be a new version of the handover request. In response to receiving the request signal, the target gNB provides a common configuration (e.g., a second configuration) of the target cell to the source gNB. The source gNB then broadcasts the common configuration (e.g., the second configuration) to the group of UEs.
An example is shown in fig. 21. The source gNB provides an indication to the target gNB in a handover request requesting a handover configuration (e.g., for a public handover or a legacy handover). The target gNB determines which handover configuration (e.g., the first configuration without the second configuration or the third configuration) to provide to the source gNB based on the indication. The source gNB provides an indication to the target gNB via a handover request indicating what HO command to request (e.g., for a public handover or a legacy handover). In response to receiving the handover request, the target gNB determines which handover configuration (e.g., a second configuration without the first configuration, the third configuration) to provide based on the indication in the handover request. For example, the target gNB provides a handover command to the source gNB that does not have a common portion based on the indication in the handover request. The source gNB then forwards the handover command to the UE.
To address the problem, the target gNB may determine content, information, resources, and/or configuration in the handover request acknowledgement in response to receiving the handover request. The target gNB may provide the first configuration (e.g., without/omitting the content of the second configuration) based on the indication and/or information in the handover request. The target gNB may provide the second configuration based on the indication in the handover request. The target gNB may always provide the first configuration and the second configuration. The target gNB may always provide the first configuration with the content of the second configuration.
The target gNB may determine whether the handover preparation is for the first handover preparation or the second handover preparation based on the indication in the handover request.
The target gNB may determine whether the handover is a public handover or a legacy handover based on the indication in the handover request.
The target gNB may determine to provide the second configuration to the source gNB in a message based on the indication from the source gNB. The second configuration may or may not be transmitted in the handover request acknowledgement. The indication may or may not be transmitted in the handover request. The indication may be a parameter and/or a boolean value. The indication may be UE information and/or (target) cell information.
In one or more examples, the first gNB is a source gNB, the second gNB is a target gNB, the first configuration is a UE-specific configuration, the second configuration is a common configuration of target cells, and/or the second configuration is servingCellConfigCommon. In one or more examples, one or more UEs in a first cell are handed over to a second cell. The first cell is served by a first gNB. The second cell is served by a second gNB.
In one example, the first gNB receives the second configuration from the second gNB. In response to receiving the second configuration, the first gNB broadcasts the second configuration to a plurality of UEs in the first cell via the system information. The first gNB decides to handover at least one UE of the plurality of UEs. The first gNB decides to trigger a common handover for at least the UE of the plurality of UEs. The first gNB transmits a handover request to the second gNB, wherein the handover request indicates that the second configuration is skipped in the handover command. The handover request includes a handover command for a first configuration without a second configuration. The handover request requests the omission of the handover command of the second configuration. The handover request contains an indication. The indication and/or the handover request indicates a common handover. The indication and/or the handover request indicates that the second configuration is skipped. The indication and/or the handover request indication requests the first configuration. In response to transmitting the handover request, the first gNB receives a handover command in a handover request acknowledgement from the second gNB, wherein the handover command includes a first configuration without the second configuration. In response to receiving the handover command, the first gNB transmits the handover command to a UE of the plurality of UEs.
In one example, the first gNB broadcasts the second configuration to a plurality of UEs in the first cell via system information. The first gNB decides to handover at least one UE of the plurality of UEs. The first gNB decides to trigger a common handover for at least a UE of the plurality of UEs. The first gNB transmits a handover request to the second gNB, wherein the handover request indicates that the second configuration is skipped in the handover command. The handover request includes a handover command for a first configuration without a second configuration. The handover request requests the omission of the handover command of the second configuration. The handover request contains an indication. The indication and/or the handover request indicates a common handover. The indication and/or the handover request indicates that the second configuration is skipped. The indication and/or the handover request indication requests the first configuration. In response to transmitting the handover request, the first gNB receives a handover command in a handover request acknowledgement from the second gNB, wherein the handover command includes a first configuration without the second configuration. In response to receiving the handover command, the first gNB transmits the handover command to a UE of the plurality of UEs.
In one example, the first gNB receives the second configuration from the second gNB. In response to receiving the second configuration, the first gNB broadcasts the second configuration to a plurality of UEs in the first cell via the system information. The first gNB decides to handover at least one UE of the plurality of UEs. The first gNB decides to trigger a legacy handover for at least a UE of the plurality of UEs. The first gNB transmits a handover request to the second gNB, wherein the handover request does not indicate to skip the second configuration in the handover command. The handover request includes a legacy handover command for the first configuration and the second configuration. The handover request requests the entire or legacy handover command, e.g. the second configuration is not omitted. The handover request does not contain an indication of a common handover and/or skip for the second configuration. In response to transmitting the handover request, the first gNB receives a handover command in a handover request acknowledgement from the second gNB, wherein the handover command includes a first configuration having a second configuration. In response to receiving the handover command, the first gNB transmits the handover command to a UE of the plurality of UEs.
In one example, the first gNB transmits a request signal to the second gNB to request the second configuration. The request signal does not contain UE context information. In response to transmitting the request signal, the first gNB receives the second configuration in the response signal. In response to receiving the second configuration, the first gNB broadcasts the second configuration to a plurality of UEs in the first cell via the system information. The first gNB decides to handover at least one UE of the plurality of UEs. The first gNB transmits a handover request to the second gNB, wherein the handover request indicates that the second configuration is skipped in the handover command. The handover request includes a handover command for a first configuration without a second configuration. The handover request requests the omission of the handover command of the second configuration. The handover request contains an indication. The indication and/or the handover request indicates a common handover. The indication and/or the handover request indicates that the second configuration is skipped. The indication and/or the handover request indication requests the first configuration. In response to transmitting the handover request, the first gNB receives a handover command in a handover request acknowledgement from the second gNB, wherein the handover command includes a first configuration without the second configuration. In response to receiving the handover command, the first gNB transmits the handover command to a UE of the plurality of UEs. The request signal is another handover request. The response signal acknowledges the further handover request.
In one example, the first gNB decides to handover one or more of the plurality of UEs. The first gNB transmits a request signal to the second gNB to request the second configuration, wherein the request signal includes a plurality of UE context information. In response to transmitting the request signal, the first gNB receives the second configuration in the response signal. In response to receiving the second configuration, the first gNB broadcasts the second configuration to a plurality of UEs in the first cell via the system information. After receiving the response signal, the first gNB receives (at least) a handover command in (at least) a handover request acknowledgement from the second gNB, wherein the handover command includes a first configuration without the second configuration. In response to receiving the handover command, the first gNB transmits the handover command to one of the plurality of UEs. The request signal is a handover request. The response signal acknowledges the further handover request.
In one example, the second gNB communicates the second configuration to the first gNB. The second gNB receives a handover request from the first gNB, wherein the handover request indicates that the second configuration is skipped in the handover command. The handover request includes a handover command for a first configuration without a second configuration. The handover request requests the omission of the handover command of the second configuration. The handover request contains an indication. The indication and/or the handover request indicates a common handover. The indication and/or the handover request indicates that the second configuration is skipped. The indication and/or the handover request indication requests the first configuration. In response to receiving the handover request, the second gNB determines whether to provide the second configuration in a handover command. In response to receiving the handover request, the second gNB determines which handover configuration to provide in the handover command, e.g., based on the indication. In response to receiving the handover request, the second gNB determines a type of handover or handover command, e.g., based on the indication. In response to receiving the handover request, the second gNB transmits a handover command to the first gNB in a handover request acknowledgement, wherein the handover command includes a first configuration without the second configuration.
In one example, the second gNB receives a request signal from the first gNB to request the second configuration. The request signal does not contain UE context information. In response to receiving the request signal that does not contain the UE context information, the second gNB determines to provide the second configuration to the first gNB. In response to receiving the request signal, the second gNB transmits the second configuration in a response signal. The second gNB receives a handover request from the first gNB, wherein the handover request indicates that the second configuration is skipped in the handover command. The handover request includes a handover command for a first configuration without a second configuration. The handover request requests the omission of the handover command of the second configuration. The handover request contains an indication. The indication and/or the handover request indicates a common handover. The indication and/or the handover request indicates that the second configuration is skipped. The indication and/or the handover request indication requests the first configuration. In response to receiving the handover request, the second gNB determines to provide the first configuration without the second configuration in the handover command, e.g., based on the indication. In response to receiving the handover request, the second gNB determines that the handover is a public handover, e.g., based on the indication. In response to receiving the handover request, the second gNB transmits a handover command to the first gNB in a handover request acknowledgement, wherein the handover command includes a first configuration without the second configuration. The request signal is another handover request. The response signal acknowledges the further handover request.
In one example, the second gNB receives a request signal from the first gNB to request the second configuration and/or to request the handover. The request signal contains a plurality of UE context information. In response to receiving the request signal containing the plurality of UE context information, the second gNB determines to switch to a common switch, e.g., based on the indication. The second gNB provides the second configuration to the first gNB. The second gNB then transmits a handover command to the first gNB in a handover request acknowledgement, wherein the handover command includes a first configuration without the second configuration. The request signal is another handover request. The response signal acknowledges the further handover request.
In one example, the UE receives system information from a first gNB in a first cell, wherein the system information includes a second configuration. The UE receives a handover command from a first gNB in a first cell, wherein the handover command includes a first configuration. In response to receiving the handover command, the UE performs a handover procedure for the second cell based on both the first configuration and the second configuration.
Throughout the disclosure herein, a handover request may indicate/request a handover type (e.g., common handover, handover enhancement, UE-specific handover, legacy handover) and/or a configuration type (e.g., first configuration, second configuration, third configuration, first configuration without second configuration, second configuration without first configuration).
One or more of the embodiments, concepts, methods, and/or examples above and herein may be fully or partially combined with or implemented separately from one or more of the other embodiments, concepts, methods, and/or examples.
Throughout the summary herein, one, some, and/or all instances of "signaling" may correspond to, may be supplemented with, and/or may be replaced by "messages" or similar terms.
The UE may be in a cell of NTN and/or narrowband internet of things (NB-IoT) NTN. The UE may connect to cells of NTN and/or (NB-) IoT NTN. The UE may be connected to LEO, GEO, MEO, HEO and/or HAPS. Throughout the inventive content herein, a cell may be and/or may refer to an NTN cell.
The UE may be referred to as a UE or an RRC entity of the UE.
The UE may be an NR device. The UE may be an NR lightweight device. The UE may be a Long Term Evolution (LTE) device. The UE may be a reduced capability device. The UE may be a mobile phone. The UE may be a wearable device. The UE may be a sensor. The UE may be a fixed device.
NW may be a network node. The NW may be a base station. The NW may be an access point. NW may be or include an evolved node B (eNB). NW may be or include gNB. The NW may be a gateway. NW may be NG-RAN node. Throughout the summary herein, the gNB may be replaced by an eNB. The gNB may be or may be referred to as NR-RAN.
Providing a common cell-specific part of the handover configuration in common signaling may reduce signaling overhead for the handover. Especially advantageous in case of a UE group handover together, e.g. a handover of a feeder link between LEO mobile cells. For the dedicated part of the UE-specific handover configuration, it may still be necessary to provide the configuration to the UE using dedicated signaling, since different UEs may already be configured with different values. However, the cell-specific portion of the handover configuration may be limited and the reduced overhead may be negligible. To further reduce the signaling overhead for the handover, more enhancements should be considered.
To address the issue, at least the UE-specific configuration (e.g., first configuration) for the handover may be included in common signaling (e.g., second signaling) and/or absent (or omitted) from dedicated signaling (e.g., first signaling). The UE may apply UE-specific configuration in common signaling (for handover) for handover. The UE-specific configuration for handover may be optional in common signaling (for handover). The UE-specific configuration for handover may be mandatory in common signaling (for handover). Dedicated signaling (for handover) may not trigger the handover. After receiving dedicated signaling (for handover) (or in response thereto), the UE may not trigger handover. The UE may perform handover based on common signaling (for handover) and dedicated signaling (for handover). The UE may trigger a handover after (or in response to) receiving common signaling (for the handover). After receiving the common signaling (for handover) and the dedicated signaling (for handover), the UE may trigger a handover after (or in response to) receiving the handover indication. The UE-specific configuration (e.g., the first configuration) may be for a common handover, a 2-step handover, and/or a group handover. Common signaling, dedicated signaling, and/or handover indications may be used for common handover, 2-step handover, and/or group handover.
The UE-specific configuration (e.g., first configuration) for handover may be allowed to be included in dedicated signaling (e.g., first signaling) for handover. The UE-specific configuration for handover may be optional in dedicated signaling for handover. The UE may consider the UE-specific configuration in common signaling (for handover) as a default value, e.g., shared by the UE group. If the UE-specific configuration is not included in the dedicated signaling (for handover), e.g., the first signaling, the UE may apply the UE-specific configuration in the common signaling (for handover). If the UE-specific configuration is included in dedicated signaling (for handover), e.g., first signaling, the UE may not apply the UE-specific configuration in common signaling (for handover). If the UE-specific configuration is included in dedicated signaling (for handover) (e.g., first signaling), the UE may apply the UE-specific configuration in dedicated signaling (for handover) (e.g., first signaling). The UE may determine whether to apply the UE-specific configuration in the common signaling (for handover) based on whether the UE-specific configuration is included in the dedicated signaling (for handover) (e.g., the first signaling).
The UE-specific configuration (e.g., first configuration) for handover may not be allowed to be included in dedicated signaling (e.g., first signaling) for handover. The UE-specific configuration for handover may not be present (or omitted) in the dedicated signaling (e.g., first signaling) for handover.
At least the non-cell specific configuration for handover (e.g., the first configuration) may be included in common signaling (for handover) (e.g., the second signaling). The configuration for handover may be specific to the UE group. The UE group may be UEs that may receive common signaling. For a group of UEs, the configuration may be common. The configuration may be different for different UE groups.
The UE-specific configuration (e.g., the first configuration) may be a configuration included in dedicated signaling that triggers handover (e.g., an RRC reconfiguration message including reconfigurationWithSync for PCell or primary cell group (MCG)). The UE-specific configuration (e.g., the first configuration) may not be (allowed to be) included in the system information. For (UE-specific) handover and/or NW-triggered handover, the UE-specific configuration is provided by dedicated signaling that triggers the handover (e.g., an RRC reconfiguration message containing reconfigurationWithSync for PCell or MCG). The (UE-specific) handover may be a handover in which the handover command is dedicated to the UE. The NW-triggered handover may be a handover triggered by a handover command (e.g., an RRC reconfiguration message containing reconfigurationWithSync for PCell or MCG).
The UE-specific configuration (e.g., first configuration) may be (or include) one or more of the following:
-T304
Configured as a value for timer T304. A timer or configuration may be used to determine handover failure. The UE may consider the handover to fail after (or in response to) expiration of timer T304.
-smtc
A measurement timing configuration (e.g., configured as SSB-MTC), e.g., a UE measures timing of a Synchronization Signal Block (SSB). SSB periodicity/offset/duration configuration for NR primary secondary cell (PSCell) change and NR PCell change target cells. If the first active DL bandwidth portion (BWP) included in this RRC message is configured with nonCellDefiningSSB-r17 for reduced capability (RedCap), then the network sets periodicityAndOffset to indicate the same periodicity as ssb-periodicityServingCell in spCellConfigCommon or to the same periodicity as ssb-Periodicity-r17 in nonCellDefiningSSB-r 17.
For the case of NR PCell changes, smtc is based on the timing reference of the (source) PCell. For the case of NR PSCell changes, it is based on the timing reference of the source PSCell.
-daps-UplinkPowerConfig
Power-related configuration for Dual Active Protocol Stack (DAPS) handoff. The configuration may be (or include) a maximum total transmit power to be used by UEs in the Source cell group during a DAPS handoff (e.g., p-DAPS-Source), a maximum total transmit power to be used by UEs in the Target cell group during a DAPS handoff (e.g., p-SAPS-Target), an uplink power sharing Mode used by the UEs in the DAPS handoff (e.g., uplinkPowerSharingDAPS-Mode).
-sl-PathSwitchConfig
Configuration for side link path switching. The configuration may be (or include) a layer 2 (L2) source Identification (ID) (e.g., targetRelayUE-Identity) of a target L2UE to network (U2N) relay UE during path transitions, a timer value (e.g., T420) of T420 to be used during path transitions.
-rlf-TimersAndConstants
Timers and constants for detecting and triggering cell-level radio link failures. The configuration may be (or include) T310 (e.g., a timer upon expiration of which the UE sees a Radio Link Failure (RLF)), N310 (e.g., a maximum number of consecutive "out of sync" indications for special cells (spcells) received from a lower hierarchy), N311 (e.g., a maximum number of consecutive "in sync" indications for spcells received from a lower hierarchy), T311 (e.g., a timer controlling the duration of the RRC connection re-establishment procedure).
-rlmInSyncOutOfSyncThreshold
A block error rate (BLER) threshold pair index for In Service (IS)/out of service (OOS) indication generation. n1 corresponds to the value 1. When there is no field, the UE applies a value of 0. Every time it is reconfigured, the UE resets N310 and N311 and stops T310 (if it is running). The network does not contain this field.
-lowMobilityEvaluationConnected
The criteria are configured to instruct the UE to detect low mobility in rrc_connected in SpCell. S-SEARCHDELTAP-Connected is the parameter "S SearchDeltaP-connected". The value dB3 corresponds to 3dB, dB6 corresponds to 6dB, and so on. T-SEARCHDELTAP-Connected is the parameter "T SearchDeltaP-Connected". The value s5 means 5 seconds, the value s10 means 10 seconds, and so on. For the case of NR independent (SA)/NR Carrier Aggregation (CA)/NR-E-ULTRA dual connectivity (NE-DC)/NR-DC, a low mobility criterion is configured in the NR PCell, and for the case of E-ULTRA dual connectivity (EN-DC), a low mobility criterion is configured in the NR PScell.
-goodServingCellEvaluationRLM
The configuration instructs the UE to detect a standard for good serving cell quality for radio link listening (RLM) relaxation in SpCell in rrc_connected. When the network implements RLM relaxation for UEs in this SpCell, the fields are always configured.
-goodServingCellEvaluationBFD
The criteria indicating that the UE detects good serving cell quality for Beam Failure Detection (BFD) relaxation in SpCell in rrc_connected are configured. When the network implements BFD relaxation for UEs in this SpCell, the fields are always configured.
-deactivatedSCG-Config
The configuration is applicable when the Secondary Cell Group (SCG) is deactivated. The network always configures this field before or at the time of instructing the SCG to deactivate in RRCReconfiguration, RRCResume, evolved universal terrestrial radio access network (E-UTRA) RRCConnectionReconfiguration, or E-UTRA RRCConnectionResume messages.
-newUE-Identity
The RNTI value configuration may be a C-RNTI of the UE to be used in the target cell.
-rach-ConfigDedicated
As a UE-specific (or non-cell-specific) random access configuration. To be used for Random Access (RA) configuration (e.g., handover) with synchronized reconfiguration. The UE performs RA according to these parameters in firstActiveUplinkBWP. The configuration may be (or include) a contention-free random access related configuration.
-servCellIndex
The configuration may be a serving cell index of the target PCell.
-spCellConfigDedicated
Dedicated configuration of the target PCell.
For at least some of the above and herein configurations, the configuration may be included in common signaling (for handover) (e.g., second signaling). The configuration may not be (allowed to) included in dedicated signaling (for handover) (e.g., first signaling). The UE may apply the configuration in the common signaling (for handover) (e.g., regardless of whether the configuration is included in the dedicated signaling (for handover)). The configuration may be (or include): t304, smtc, daps-UplinkPowerConfig and/or sl-PathSwitchConfig.
For at least some of the above and herein configurations, the configuration may be included in common signaling (for handover) (e.g., second signaling). The configuration may be included (allowed) in dedicated signaling (for handover), e.g., first signaling. The UE may apply the configuration in the common signaling (for handover) based on whether the configuration is included in the dedicated signaling (for handover). If the configuration is not included in the dedicated signaling (for handover), the UE may apply the configuration in the common signaling (for handover). If the configuration is included in dedicated signaling (for handover), the UE may not apply the configuration in common signaling (for handover). The configuration may be (or include )：Rlf-TimersAndConstants、rlmInSyncOutOfSyncThreshold、lowMobilityEvaluationConnected、goodServingCellEvaluationRLM、goodServingCellEvaluationBFD and/or DEACTIVATEDSCG-Config.
For at least some of the above and herein configurations, the configuration may not (allowed to) be included in common signaling (for handover) (e.g., second signaling). The configuration may be included in dedicated signaling (for handover). The configuration may be (or include): newUE-Identity, random Access Channel (RACH) -ConfigDedicated, servCellIndex and/or spCellConfigDedicated.
The target gNB may determine content, information, resources, and/or configuration in a HANDOVER REQUEST acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE) in response to receiving a HANDOVER REQUEST (e.g., HANDOVER REQUEST). The target gNB may provide the first configuration (e.g., without/omitting the content of the second configuration) based on the indication and/or information in the HANDOVER REQUEST (e.g., HANDOVER REQUEST). The target gNB may provide the second configuration based on an indication in a HANDOVER REQUEST (e.g., HANDOVER REQUEST). The target gNB may always provide the first configuration and the second configuration. The target gNB may always provide the first configuration with the content of the second configuration.
The target gNB may determine whether the HANDOVER preparation is a first HANDOVER preparation or a second HANDOVER preparation based on an indication in a HANDOVER REQUEST (e.g., HANDOVER REQUEST).
The target gNB may determine to provide the second configuration to the source gNB in a message based on the indication from the source gNB. The second configuration may or may not be transmitted in a handover request acknowledgement (e.g., HANDOVER REQUEST ACKNOWLEDGE). The indication may or may not be transmitted in a HANDOVER REQUEST (e.g., HANDOVER REQUEST). The indication may be a parameter and/or a boolean value. The indication may be UE information and/or (target) cell information.
The handover procedure enables a UE in rrc_connected to change its serving cell (e.g., PCell) from a source cell to a target cell. The source cell may be controlled by the source gNB and the target cell may be controlled by the target gNB. The conventional (or conventional UE-specific) handover procedure may be as shown in fig. 6 (fig. 9.2.3.1-1 from 3]3GPP TS 38.300 V17.2.0). When (or in response to) the source gNB decides to perform a handover procedure for the UE, the source gNB transmits a handover request to the target gNB, e.g., for preparing for a handover. The handover request may include UE information (e.g., UE ID, UE context information). In response to receiving the handover request, the target gNB transmits a handover request acknowledgement to the source gNB. The handover request acknowledgement may include a configuration (and/or resources) for the handover. The handover request acknowledgement may include a message (e.g., RRC reconfiguration) for a handover (e.g., handover command HandoverCommand) to be transmitted to the UE. The message may be used to trigger a handover of the UE. In response to receiving the handover request acknowledgement, the source gNB may transmit an RRC reconfiguration message (e.g., RRCReconfiguration) from the handover command (e.g., handoverCommand) to the UE. In response to receiving the RRC reconfiguration message (e.g., RRCReconfiguration), the UE may trigger a handover procedure and/or transmit an RRC reconfiguration complete message (e.g., RRCReconfigurationComplete) to the target gNB.
The exchange of (direct) messages between the source and target gnbs (e.g., handover request acknowledgement defined in [5]3GPP TS 38.423 V17.2.0 ]) requires an Xn interface between the source and target gnbs. For handovers without an Xn interface between the source and target gnbs, signaling for handover preparation may need to be exchanged via a Core Network (CN) (e.g., AMF). For example, when (or in response to) the source gNB decides to perform a HANDOVER procedure for the UE, the source gNB may perform a HANDOVER preparation procedure for the AMF by transmitting a HANDOVER REQUEST (e.g., HANDOVER REQUIRED (e.g., [7]3GPP TS 38.413 V17.2.0) ] message and receiving a HANDOVER COMMAND (e.g., [7]3GPP TS 38.413 V17.2.0) message as a response, the AMF may perform a HANDOVER resource allocation procedure for the target gNB (e.g., in response to receiving a HANDOVER REQUEST acknowledgement (e.g., [7]3GPP TS 38.413V17.2.0) ] in response to receiving a HANDOVER REQUEST acknowledgement message) by transmitting a HANDOVER REQUEST (e.g., HANDOVER REQUIRED) (e.g., 7]3GPP TS 38.413 V17.2.0) message as a response) to the AMF, the source gNB may transmit an RRC reconfiguration message (e.g., RRCReconfiguration) (e.g., with ReconfigurationWithSync for PCell) for HANDOVER based on a HANDOVER COMMAND message received from the AMF to UE. in response to receiving an RRC reconfiguration message (e.g., RRCReconfiguration), the UE may trigger the RRC reconfiguration procedure and/or may complete the RRC reconfiguration procedure (e.g., RRCReconfigurationComplete) to the target gNB.
For handover enhancements (e.g., common handover, group handover, and/or 2-step handover), various enhancements may be applied to the current handover procedure. The legacy handover may be a handover without handover enhancements (e.g., common handover, group handover, and/or 2-step handover). The common handover may be a handover with handover enhancements. The legacy handover may be a UE-specific handover.
For example, the configuration of a handover initially included in a dedicated handover command (e.g., a common handover and/or a group handover) may be divided into a common portion (e.g., a cell-specific configuration) and a dedicated portion (e.g., a UE-specific configuration). The common portion of the configuration for handover (to the UE) may be provided in common signaling (e.g., broadcast, multicast, and/or system information). The dedicated portion of the configuration for the handover (to the UE) may be provided in dedicated signaling (e.g., RRC reconfiguration message). Common signaling may be transmitted to more than one UE (e.g., a group of UEs). Dedicated signaling may be communicated to a particular UE. The network may transmit common signaling to the first UE and the second UE. The network may transmit first dedicated signaling to a first UE and second dedicated signaling to a second UE. The first UE and the second UE may be different UEs (e.g., in the same UE group).
For example (e.g., a 2-step handover and/or a group handover), the network may provide configuration for the handover (to the UE) in advance without triggering the handover. After receiving the configuration for handover, the UE stores the configuration for handover. The configuration for handover may be a common configuration (e.g., cell-specific configuration) and/or a dedicated configuration (e.g., UE-specific configuration). After providing the configuration for the handover, the network may transmit a handover indication to trigger the handover. The UE may trigger a handover after (or in response to) receiving the handover indication. The handover indication may be common to at least one group of UEs. The handover indication may be broadcast, multicast, and/or system information. The handover indication may be DCI and/or MAC CE. The handover indication may or may not comprise (part of) the handover configuration. In this case, the UE group.
To address the problem, considering that there may be more than one set of configurations for handover (e.g., first configuration, second configuration, legacy configuration such as HandoverCommand, configuration for group handover, configuration for legacy handover), these configurations may be provided to the source gNB (or first network node, network node requesting handover configuration of the UE), the target gNB (or second network node, network node providing handover configuration for the UE) needs to know which set or sets of configurations should be provided for handover in response to a request from the source gNB (or first network node, network node requesting handover configuration of the UE).
The source gNB may indicate (e.g., by providing an indication to) the target gNB (e.g., in a first message, in a message for requesting a handover configuration, in a message for preparing for a handover, in a handover request) to provide at least one set of specific configurations (e.g., a first configuration, a second configuration, and/or a third configuration) for the handover. After receiving the first message (or in response thereto), the target gNB may provide (or include) what (or which) group configuration to use for the handover, e.g., based on the indication, in a second message, in a response message to the first message, in a message providing the handover configuration, and/or in a handover request acknowledgement. A particular set of configurations may be included in a response message to the first message. A particular set of configurations may be included (or encoded) in a message container. The message container may be forwarded (or relayed) by the source gNB to the UE. The message container may be extracted by the source gNB and/or received by the UE. A particular set of configurations may be applied (or stored) by the UE for handover, e.g., upon (or in response to) receipt of a message container.
Throughout the disclosure herein, the following are interchangeable: a/the HANDOVER REQUEST, a/the first message, a/the message for requesting HANDOVER configuration, a/the message for preparing HANDOVER, a/the HANDOVER REQUEST, a/the HANDOVER required message.
Throughout the disclosure herein, the following are interchangeable: a/the second message, a/the response message of the first message, a/the message providing a HANDOVER configuration, a/the HANDOVER REQUEST acknowledgement, a/the HANDOVER REQUEST, a/the HANDOVER command.
The source gNB may indicate (e.g., by providing an indication to) the AMF (e.g., in a first message, in a message for requesting a handover configuration, in a message for preparing for a handover, in requesting a handover) to provide at least one set of specific configurations (e.g., a first configuration, a second configuration, and/or a third configuration) for the handover. After receiving the first message (or in response thereto), the AMF may (determine) what (or which) group configuration to provide (or include) for the handover, e.g., in the second message, in a response message to the first message, in a message providing the handover configuration, and/or in a handover command, based on the indication. The AMF may provide a set of specific configurations to the source gNB based on a message received from the target gNB (e.g., a handover request acknowledgement), for example, the AMF may forward the set of specific configurations received from the target gNB. A particular set of configurations may be included in a response message to the first message. Sets of specific configurations may be included (or encoded) in a message container. The message container may be forwarded (or relayed) by the source gNB to the UE. The message container may be extracted by the source gNB and/or received by the UE. A particular set of configurations may be applied (or stored) by the UE for handover, e.g., upon (or in response to) receipt of a message container.
The AMF may indicate (e.g., by providing an indication to) the target gNB (e.g., in a first message, in a message for requesting a handover configuration, in a message for preparing for a handover, in a handover request) to provide at least one set of specific configurations (e.g., a first configuration, a second configuration, and/or a third configuration) for the handover. The AMF may provide an indication based on a message received from the source gNB (e.g., requiring a handover). For example, the AMF may forward the indication received from the source gNB. After receiving the first message (or in response thereto), the target gNB may provide (or include) what (or which) group configuration to use for the handover, e.g., based on the indication, in a second message, in a response message to the first message, in a message providing the handover configuration, and/or in a handover request acknowledgement. A particular set of configurations may be included in a response message to the first message. A particular set of configurations may be included (or encoded) in a message container. The message container may be forwarded (or relayed) by the AMF to the source gNB. The message container may be extracted by the source gNB and/or received by the UE. A particular set of configurations may be applied (or stored) by the UE for handover, e.g., upon (or in response to) receipt of a message container.
The indication may indicate (request) the first configuration. A particular set of configurations may be (or include) a first configuration. The first configuration may be (or include) a portion of the handover configuration to be provided to the UE via dedicated signaling and/or a portion of the handover configuration to be provided to the UE in one of the first steps of the handover (e.g., the first signaling mentioned above, the second signaling mentioned above, the third signaling mentioned above). Upon receiving the indication (for the first configuration) (or in response thereto), the target gNB (or AMF) may provide (or include) the first configuration in a response message (e.g., a second message). The response message (e.g., second message) may not include another/other handover configuration (e.g., second configuration). For example, a first value (e.g., in a first message) (e.g., by the source gNB or AMF) is used to request a first configuration (e.g., for handover). After receiving the first value (or in response thereto), the target gNB (or AMF) includes the first configuration in a response message (e.g., a second message). The first value may be a causal value. The first value may be a value of a handover type.
The indication may indicate (request) the second configuration. A particular set of configurations may be (or include) a second configuration. The second configuration may be (or include) a portion of the above-mentioned second configuration, a handover configuration to be provided to the UE via common signaling, and/or a portion of the handover configuration to be provided to the UE in one of the second steps of the handover (e.g., the above-mentioned first signaling, the above-mentioned second signaling, the above-mentioned third signaling). Upon receiving the indication (for the second configuration) (or in response thereto), the target gNB (or AMF) may provide (or include) the second configuration in a response message (e.g., a second message). The response message (e.g., second message) may not include another/other handover configuration (e.g., first configuration). For example, a second value (e.g., in the first message) (e.g., by the source gNB or AMF) is used to request a second configuration (e.g., for handover). Upon receiving (or in response to) the second value, the target gNB (or AMF) includes the second configuration in a response message (e.g., a second message). The second value may be a causal value. The second value may be a value of a handover type.
The indication may indicate (request) a third configuration. A particular set of configurations may be (or include) a third configuration. The third configuration may be (or include) a handover command including a common part and a dedicated part of the handover configuration, a (complete) handover configuration to be provided to the UE triggering the handover, all configurations required for the handover and/or HandoverCommand (as defined in [4]3GPP TS 38.331 V17.2.0 "). Upon receiving the indication (for the third configuration) (or in response thereto), the target gNB (or AMF) may provide (or include) the third configuration in a response message (e.g., a second message). For example, a third value (e.g., in the first message) (e.g., by the source gNB or AMF) is used to request a third configuration (e.g., for handover). After receiving the third value (or in response thereto), the target gNB (or AMF) includes the third configuration in a response message (e.g., a second message). The third value may be a causal value. The third value may be a value of a handover type.
The indication may indicate (request) what set of configurations (among the first configuration, the second configuration, and/or the third configuration). Upon (or in response to) receiving the indication, the target gNB (or AMF) may provide (or include) a plurality of sets of specific configurations indicated by the indication.
The indication may indicate the type of handover (or signaling for the handover). For example, the indication may indicate a common portion of the handover, and/or one of the first steps (e.g., in a 2-step handover or group handover). The indication may correspond to the second configuration (or the first configuration). For example, the indication may indicate a dedicated portion of the handover, and/or one of the second steps (e.g., in a 2-step handover or group handover). The indication may correspond to the first configuration (or the second configuration). For example, the indication may indicate a public handoff, a group handoff, a 2-step handoff, and/or a traditional handoff.
The indication may be explicit or implicit. For example, the cause value may be indicated (indicated), such as in a request message (e.g., a first message). For example, the handover type may be indicated (indicated), such as in a request message (e.g., a first message). For example, the presence or absence of UE context information (or RRC context) may be indicated (indicated), such as in a request message (e.g., a first message). For example, the presence or absence of a (new) Information Element (IE) or field may indicate (indicate), such as in a request message (e.g., a first message). The (new) information element or field may be or may be information about the UE and/or the UE group. The (new) information element or field may be enhanced with respect to the handover.
To address the problem, different (request) messages may be used to request different sets of configurations (e.g., first configuration, second configuration, and/or third configuration) for the handover. Different (response) messages may be used to provide (requested) different sets of configurations for handover.
Messages other than the handover request may be used to request the configuration(s) for handover. The (set of) configurations for switching may be (or include) the first configuration and/or the second configuration. For example, an Xn setup request message may be used to request the (set of) configurations for handover.
Messages other than a handover request acknowledgement may be used to provide the configuration(s) for handover. The (set of) configurations for switching may be (or include) the first configuration and/or the second configuration. For example, an Xn setup response message, NG-RAN node configuration update, RAN configuration update, and/or AMF configuration update may be used to provide the (set of) configurations for the handover. The configuration(s) for the handover may be provided without a request. The configuration(s) for the handoff may be provided at (or in response to) the update of the configuration(s).
Throughout the disclosure herein, the first network node may be an NG-RAN node, a CN node, (source) gNB, (target) gNB, AMF, a network node requesting handover configuration of the UE.
Throughout the disclosure herein, the second network node may be an NG-RAN node, a CN node, (source) gNB, (target) gNB, AMF, network node providing handover configuration of the UE.
A first network node (e.g., source gNB) may use (or transmit) a first request message for a second network node (e.g., target gNB) to request a first set of configurations for a handover. Upon receiving the first request message (or in response thereto, or in this case, the target gNB, for example) may provide (or include) a first set of configurations for handover in the first response message (for the first network node (source gNB, for example)). The first request message may not (can) request the second set of configurations for handover and/or the third set of configurations for handover.
The first network node (e.g., source gNB) may use (or transmit) a second request message for a second network node (e.g., target gNB) to request a second set of configurations for the handover. Upon receiving the second request message (or in response thereto, or in this case, the target gNB, for example) may provide (or include) a second set of configurations for the handover in a second response message (for the first network node (source gNB, for example)). The second request message may not (can) request the first set of configurations for handover and/or the third set of configurations for handover.
The first network node (e.g., source gNB) may use (or transmit) a third request message for the second network node (e.g., target gNB) to request a third set of configurations for the handover. Upon receiving the third request message (or in response thereto, or in this case, the target gNB, for example) may provide (or include) a third set of configurations for the handover in the third response message (for the first network node (source gNB, for example)). The third request message may not (can) request the first set of configurations for handover and/or the second set of configurations for handover.
The second network node (e.g., target gNB) may provide (or include) what (or which) set of configurations to use for the handover based on which message is received.
The first set of configurations, the second set of configurations, and/or the third set of configurations may be included (or encoded) in a message container. The message container may be forwarded (or relayed) to the UE by a first network node (e.g., source gNB). The message container may be extracted by a first network node (e.g., source gNB) and/or received by the UE. A particular set of configurations may be applied (or stored) by the UE for handover, e.g., upon (or in response to) receipt of a message container. The message container may not include other sets of configurations (e.g., the first set of configurations, the second set of configurations, and/or the third set of configurations).
The first, second and/or third request messages may be a handover request, an Xn setup request and/or a (new) message for requesting a handover configuration (e.g. a group handover request).
The first, second and/or third response messages may be a handover request acknowledgement, an Xn setup response and/or a (new) message for providing a handover configuration (e.g. a group handover request acknowledgement).
The first, second, and/or third set of configurations may be the first, second, and/or third configurations.
For example, a group-specific handover request (or group-specific handover requirement) message may be used (by a first network node (e.g., source gNB)) to request a first configuration (from a second network node (e.g., target gNB)). The group-specific handover request acknowledgement (or group-specific handover command) message may be used (by the second network node (e.g., target gNB)) to provide the first configuration (to the first network node (e.g., source gNB)).
For example, a group public handover request (or group public handover requirement) message may be used (by a first network node (e.g., source gNB)) to request a second configuration (from a second network node (e.g., target gNB)). The group public handover request acknowledge (or group specific handover command) message may be used (by the second network node (e.g., target gNB)) to provide a second configuration (to the first network node (e.g., source gNB)).
For example, a handover request (or handover requirement) message may be used (by a first network node (e.g., source gNB)) to request a third configuration (from a second network node (e.g., target gNB)). The handover request confirm (or handover command) message may be used (by the second network node (e.g., target gNB)) to provide a third configuration (to the first network node (e.g., source gNB)).
For example, an Xn setup request message may be used (by the source gNB) to request the second configuration (from the target gNB). The Xn setup response message may be used (by the target gNB) to provide the second configuration (to the source gNB).
Based on the current Xn application protocol specification (e.g., [5]3GPP TS 38.423 V17.2.0), the handover request message needs to contain one and only one UE context information for the UE. The UE context information is used to indicate handover for the UE and its corresponding UE context. Based on the current NG application protocol specification (e.g., [7]3GPP TS 38.413 V17.2.0), the handover required message (from source gNB to AMF) and/or the handover request message (from AMF to target gNB) needs to contain one and only one message container for the UE. The message container may be used to (transparently) communicate radio related information from the handover source to the handover target through the core network. If the source gNB REQUESTs a common partial configuration of a common HANDOVER via a HANDOVER REQUEST, the source gNB needs to include UE context information for one UE in the HANDOVER REQUEST. However, for public handover, group handover, and/or 2-step handover, the configuration for the handover (to be provided from the target gNB to the source gNB via AMF or not via AMF) may not be specific to the UE (e.g., for public handover). The common part configuration of the common handover is common to all UEs to be handed over. It is not clear how to include UE context information in the "HANDOVER REQUEST" for public HANDOVER. Furthermore, the source gNB may need to prepare a large number of UEs (e.g., for group handover) simultaneously or in a short time. Based on the current specifications, one handover request (or handover requirement) message may be prepared for only one UE's handover, which appears to be inefficient.
To solve the problem, the handover request message (or the message requesting the handover configuration) may contain a plurality of UE context information (for a plurality of UEs) or no UE context information. The handover request message (or a message requesting a handover configuration) may contain multiple UE IDs (for multiple UEs) or no UE IDs. The UE ID may be associated with UE context information. One UE ID may be associated with one UE context information. The UE ID may be an NG-RAN node UE Xn application protocol (XnAP) ID. The UE ID may be used to identify the UE (e.g., via an Xn interface).
The UE context information may be (or include): UE capabilities (e.g., security capabilities), UE security information (e.g., access Stratum (AS) security information), UE aggregate maximum bit rate, protocol Data Unit (PDU) session resources (e.g., PDU session resource list to be established), RRC context (e.g., handoverPreparationInformation), and/or UE history information
The handover required message, the handover request message, and/or the message requesting the handover configuration may contain multiple message containers (for multiple UEs) or no message containers. The handover required message, the handover request message, and/or the message requesting the handover configuration may contain multiple UE IDs (for multiple UEs) or no UE IDs. The UE ID may be associated with a message container. One UE ID may be associated with one message container. The UE ID may be an AMF UE Next Generation Application Protocol (NGAP) ID, a RAN UE NGAP ID, and/or a target ID. The UE ID may be used to identify the UE or UE association (e.g., within the NG-RAN node via the NG interface). The UE, UE ID, and/or message container may be associated with a PDU session, PDU session ID, and/or PDU session resources.
The message container may (or contains): source to target transparent container (e.g., [7]3GPP TS 38.413 V17.2.0), source NG-RAN node to target NG-RAN node transparent container (e.g., [7]3GPP TS 38.413 V17.2.0), and/or HandoverPreparationInformation (e.g., [4]3GPP TS 38.331 V17.2.0).
The response message to the request (e.g., handover request acknowledgement, handover command) may include a handover configuration for the plurality of UEs and/or a message container for the plurality of UEs.
The message container may (or contains): target NG-RAN node to source NG-RAN node transparent container (e.g., [5]3GPP TS 38.423 V17.2.0), handoverCommand (e.g., [4]3GPP TS 38.331 V17.2.0), target to source transparent container (e.g., [7]3GPP TS 38.413 V17.2.0), and/or target NG-RAN to source NG-RAN node transparent container (e.g., [7]3GPP TS 38.413 V17.2.0).
Throughout the disclosure herein, the first network node may be an NG-RAN node, a CN node, (source) gNB, (target) gNB, AMF.
Throughout the disclosure herein, the second network node may be an NG-RAN node, a CN node, (source) gNB, (target) gNB, AMF.
The second network node (e.g., target gNB) may provide (determine) what (or which) group configuration to use for the handover based on whether the message contains a UE ID, no UE ID, or multiple UE IDs. The second network node (e.g., target gNB) may provide (or include) what (or which) set of configurations to use for the handover based on whether the message includes one, no, or multiple UE context information. The set of configurations may be (or include) the first configuration, the second configuration, and/or the third configuration mentioned above. The second network node (e.g., target gNB) may include the first configuration, the second configuration, and/or the third configuration in a response message to the handover request message (or a message requesting a handover configuration).
For example, a first network node (e.g., source gNB) may communicate a message (e.g., a first message, a handover request message, a message requesting a handover configuration) to a second network node (e.g., target gNB), wherein the message does not include a UE ID and/or does not include UE context information (e.g., associated with a UE ID). A message without a UE ID (or UE context information) may be used to request a first set of configurations (e.g., a first configuration, a second configuration). Upon receiving the message (or in response thereto, or in this case, the target gNB, for example) includes (or provides) a first set of configurations (e.g., first configuration, second configuration) in a response message (e.g., second message, handover request acknowledgement, message for providing handover configuration).
For example, a first network node (e.g., source gNB) may communicate a message (e.g., a first message, a handover request message, a message requesting a handover configuration) to a second network node (e.g., target gNB), wherein the message includes a plurality of UE IDs and/or a plurality of UE context information (e.g., corresponding to a plurality of UE IDs). A message with multiple UE IDs (or UE context information) may be used to request a second set of configurations (e.g., first configuration, second configuration). Upon receiving the message (or in response thereto, or in this case, the target gNB, for example) includes (or provides) a second set of configurations (e.g., first configuration, second configuration) in a response message (e.g., second message, handover request acknowledgement, message for providing handover configuration). A plurality of second set of configurations for a plurality of UEs may be included. A second set of configurations may correspond to a UE.
For example, a first network node (e.g., source gNB) may communicate a message (e.g., a first message, a handover request message, a message requesting a handover configuration) to a second network node (e.g., target gNB), wherein the message includes one UE ID and/or one UE context information (e.g., associated with the UE ID). A message with one UE ID (or UE context information) may be used to request a third set of configurations (e.g., a third configuration). Upon receiving the message (or in response thereto, or in this case, the target gNB, for example) includes (or provides) a third set of configurations (e.g., third configuration) in a response message (e.g., second message, handover request acknowledgement, message for providing handover configuration).
The switching configuration (e.g., first configuration, second configuration, third configuration) may be (or include) one or more of the following:
-spCellConfigCommon (or ServingCellConfigCommon);
Cell specific parameters for a serving cell (e.g., spCell, PCell). The parameters may include: physical Cell ID (PCI), common uplink configuration, common downlink configuration, ssb-PositionsInBurst, ssb-periodicityServingCell, ssbSubcarrierSpacing, and/or common Time Division Duplex (TDD) -UL-DL-configuration.
NTN configuration (or NTN-Config);
The UE accesses parameters required for accessing the NR via the NTN. The parameters may include: epoch time, validity duration, cell specific K offset、Kmac, timing Advance (TA) information, and/or ephemeris information.
-One or more UE-specific configurations as described above.
One or more of the embodiments, concepts, methods and/or examples above and herein may be applied where the target cell is an NTN cell. One or more of the embodiments, concepts, methods and/or examples above and herein may be applied to public handoff, 2-step handoff and/or group handoff.
The first configuration may be included in common signaling and/or dedicated signaling for handover of NTN cells. The first configuration may be included in dedicated signaling for handover of the TN cell. The first configuration may not be included in the common signaling for handover of the TN cell.
The UE may determine whether to apply the first configuration in common signaling (for handover) based on whether the handover is for NTN or TN. The UE may determine whether to apply the first configuration in common signaling (for handover) based on whether the target cell is an NTN cell or a TN cell. The UE may receive the first configuration in common signaling (for handover) based on handover for NTN and/or the target cell being an NTN cell. The UE may not receive the first configuration in common signaling (for handover) based on handover for NTN and/or target cell to TN cell.
With reference to fig. 22, by this and other concepts, systems and methods of the present invention, a method 1000 for a first network node in a wireless communication system includes: receiving a first configuration from a second network node (step 1002); broadcasting a first configuration in a first cell via system information (1004); transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in the handover command (step 1006); in response to transmitting the handover request, receiving a handover command in a handover request acknowledgement from the second network node, wherein the handover command includes the second configuration and does not include the first configuration (step 1008); and transmitting a handover command to the UE (step 1010).
In various embodiments, the method further comprises: transmitting a request to a second network node to request a first configuration, wherein the request contains a plurality of UE context information or does not contain UE context information; and receiving the first configuration in response to the transmission request.
In various embodiments, the request is another handover request, and/or wherein the response is another handover request acknowledgement.
In various embodiments, the first network node is a source gNB, and/or wherein the second network node is a target gNB.
In various embodiments, the first configuration is a common configuration or servingCellConfigCommon for the target cell.
In various embodiments, the second configuration is a dedicated configuration for the UE of the target cell.
In various embodiments, the first configuration is a cell specific configuration.
In various embodiments, the second configuration is a UE-specific configuration.
In various embodiments, the handover command is an RRC reconfiguration message.
In various embodiments, the handover request indicates that the second configuration is provided.
In various embodiments, the handoff request indicates that a common handoff is prepared.
In various embodiments, the RRC reconfiguration message is RRCReconfiguration with reconfigureWithSync.
In various embodiments, the first cell is a source cell.
Referring back to fig. 3 and 4, in one or more embodiments from the perspective of the first network node, the apparatus 300 includes program code 312 stored in the memory 310 of the transmitter. CPU 308 may execute program code 312 to: (i) receiving a first configuration from a second network node; (ii) Broadcasting the first configuration via system information in the first cell; (iii) Transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in the handover command; (iv) In response to transmitting the handover request, receiving a handover command in a handover request acknowledgement from the second network node, wherein the handover command includes the second configuration and does not include the first configuration; and (v) transmitting a handover command to the UE. Further, the CPU 308 may execute the program code 312 to perform all of the described acts, steps and methods described above, below or otherwise herein.
Referring to fig. 23, with this and other concepts, systems and methods of the present invention, a method 1020 for a second network node in a wireless communication system includes: receiving a request from a first network node, wherein the request contains a plurality of UE context information or does not contain UE context information (step 1022); in response to receiving the request, transmitting a response containing the first configuration to the first network node (step 1024); receiving a handover request from the first network node, wherein the handover request comprises an indication of a public handover and/or a request for a second configuration (step 1026); and/or in response to receiving the handover request: determining that the first configuration is not included in the handover command; and transmitting a handover command including the second configuration without the first configuration to the first network node in a handover request acknowledgement (step 1028).
Referring back to fig. 3 and 4, in one or more embodiments from the perspective of the second network node, the apparatus 300 includes program code 312 stored in the memory 310 of the transmitter. CPU 308 may execute program code 312 to: (i) Receiving a request from a first network node, wherein the request contains a plurality of UE context information or does not contain UE context information; (ii) Transmitting a response containing the first configuration to the first network node in response to receiving the request; (iii) Receiving a handover request from the first network node, wherein the handover request comprises an indication of a public handover and/or a request for a second configuration; and/or (iv) in response to receiving the handover request: determining that the first configuration is not included in the handover command; and transmitting a handover command including the second configuration without the first configuration to the first network node in a handover request acknowledgement. Further, the CPU 308 may execute the program code 312 to perform all of the described acts, steps and methods described above, below or otherwise herein.
Any combination of the above or the concepts or teachings herein may be combined or formed together, in whole or in part, as a new embodiment. The details and embodiments disclosed may be used to solve at least (but not limited to) the problems set forth above and herein.
It should be noted that any of the methods, alternatives, steps, examples and embodiments set forth herein may be applied independently, individually and/or with multiple methods, alternatives, steps, examples and embodiments combined together.
Various aspects of the disclosure have been described above. It should be understood that the teachings herein may 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 may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method practiced using any number of the aspects set forth herein. In addition, such apparatus may be implemented or such method may be practiced using other structure, functionality, or structure and functionality other than one or more of the aspects set forth herein. As an example of some of the concepts described above, parallel channels may be established based on pulse repetition frequencies in some aspects. In some aspects, parallel channels may be established based on pulse positions or offsets. In some aspects, parallel channels may be established based on a hop sequence. In some aspects, parallel channels may be established based on pulse repetition frequency, pulse position or offset, and time hopping sequence.
Those of ordinary 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 ordinary 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 both, which may be designed using source coding or some other technique), various forms of program or design code with instructions (which may be referred to herein as "software" or "software modules" for convenience), 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.
Additionally, 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. An 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 code or instructions that reside within the IC, outside the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any normal 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 should be understood that any particular order or hierarchy of steps in any disclosed process is an example of an example approach. It should be understood that the particular order or hierarchy of steps in the process may be rearranged based on design preferences 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. Software modules (e.g., including executable instructions and related data) and other data may reside in data storage such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An example storage medium may be coupled to a machine, such as a computer/processor (which may be referred to herein as a "processor" for convenience), such a processor may read information (e.g., code) from, and write information to, the storage medium. An example storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user equipment. In the alternative, the processor and the storage medium may reside as discrete components in a user device. Furthermore, in some aspects, any suitable computer program product may comprise a computer-readable medium comprising code relating to one or more aspects of the present disclosure. In some aspects, the computer program product may include packaging material.
While the application has been described in connection with various aspects, it will be understood that the application is capable of further modifications. This disclosure is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known and customary practice within the art to which the application pertains.
Claims (20)
1. A method for a first network node, comprising:
Receiving a first configuration from a second network node;
Broadcasting the first configuration via system information in a first cell;
Transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in a handover command;
in response to transmitting the handover request, receiving the handover command in a handover request acknowledgement from the second network node, wherein the handover command includes a second configuration and does not include the first configuration; and
And transmitting the switching command to the user equipment.
2. The method as recited in claim 1, further comprising:
Transmitting a request to the second network node to request the first configuration, wherein the request includes a plurality of user equipment context information or does not include user equipment context information; and
In response to transmitting the request, the first configuration is received in a response.
3. The method of claim 2, wherein the request is another handover request, or wherein the response is another handover request acknowledgement.
4. The method of claim 1, wherein the first network node is a source gNB, or wherein the second network node is a target gNB.
5. The method of claim 1, wherein the first configuration is a common configuration or servingCellConfigCommon of a target cell.
6. The method of claim 1, wherein the second configuration is a user equipment specific configuration.
7. The method according to claim 1, wherein the handover command is a radio resource control reconfiguration message.
8. The method of claim 1, wherein the handover request indicates that the second configuration is provided.
9. The method of claim 1, wherein the handover request indicates that a common handover is prepared.
10. A method for a second network node, comprising:
Receiving a request from a first network node, wherein the request contains a plurality of user equipment context information or no user equipment context information;
Transmitting a response containing a first configuration to the first network node in response to receiving the request;
Receiving a handover request from the first network node, wherein the handover request includes an indication of a public handover or a request for a second configuration; and
In response to receiving the handoff request:
determining that the first configuration is not included in the handover command; and
The handover command including the second configuration but not the first configuration is transmitted to the first network node in a handover request acknowledgement.
11. A first network node, comprising:
A memory; and
A processor operatively coupled to the memory, wherein the processor is configured to execute program code to:
Receiving a first configuration from a second network node;
Broadcasting the first configuration via system information in a first cell;
Transmitting a handover request to the second network node, wherein the handover request indicates that the first configuration is skipped in a handover command;
in response to transmitting the handover request, receiving the handover command in a handover request acknowledgement from the second network node, wherein the handover command includes a second configuration and does not include the first configuration; and
And transmitting the switching command to the user equipment.
12. The first network node of claim 11, further comprising:
Transmitting a request to the second network node to request the first configuration, wherein the request includes a plurality of user equipment context information or does not include user equipment context information; and
In response to transmitting the request, the first configuration is received in a response.
13. The first network node of claim 12, wherein the request is another handover request, or wherein the response is another handover request acknowledgement.
14. The first network node of claim 11, wherein the first network node is a source gNB, or wherein the second network node is a target gNB.
15. The first network node of claim 11, wherein the first configuration is a common configuration or servingCellConfigCommon of a target cell.
16. The first network node of claim 11, wherein the second configuration is a user equipment specific configuration.
17. The first network node according to claim 11, wherein the handover command is a radio resource control reconfiguration message.
18. The first network node of claim 17, wherein the radio resource control reconfiguration message is RRCReconfiguration with reconfigureWithSync.
19. The first network node of claim 11, wherein the handover request indicates that the second configuration is provided.
20. The first network node of claim 11, wherein the handover request indicates that a common handover is prepared.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US63/433,320 | 2022-12-16 | ||
| US63/434,880 | 2022-12-22 | ||
| US202363436856P | 2023-01-03 | 2023-01-03 | |
| US63/436,856 | 2023-01-03 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118215087A true CN118215087A (en) | 2024-06-18 |
Family
ID=91448040
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311698393.3A Pending CN118215087A (en) | 2022-12-16 | 2023-12-12 | Network node in a wireless communication system and method for a network node |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118215087A (en) |
-
2023
- 2023-12-12 CN CN202311698393.3A patent/CN118215087A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109309968B (en) | Method and apparatus for recovering radio resource control connection in wireless communication system | |
| US11503634B2 (en) | Method and apparatus for supporting RACH-less mobility with pre-allocated beams in wireless communication system | |
| CN115462007B (en) | User equipment and base station | |
| CN117395768A (en) | Communication system, communication terminal and base station | |
| CN112020897A (en) | User equipment, network node and method in a wireless communication network | |
| US20120250602A1 (en) | Method and apparatus to improve high-speed mobility in a wireless communication system | |
| CN113661748A (en) | Communication system, base station, and host device | |
| CN113597784A (en) | Method for switching network equipment, terminal equipment and network equipment | |
| CN115486134A (en) | Communication system, communication terminal and base station | |
| US20180132294A1 (en) | Radio bearer setup method and device | |
| CN116033600B (en) | Method and apparatus for supporting user equipment to network relay communication in wireless communication | |
| CN115942371B (en) | Method and apparatus for user equipment location reporting in a wireless communication system | |
| EP4175399B1 (en) | Method and apparatus for relay ue sidelink rlc bearer configuration to support ue-to-network relaying in a wireless communication system | |
| CN116033602B (en) | Method and apparatus for supporting user equipment to network relay communication in wireless communication system | |
| CN116963211A (en) | Method and apparatus for supporting direct communication path from PC5 to Uu | |
| Määttänen et al. | Radio interface protocols and radio resource management procedures for 5G new radio non‐terrestrial networks | |
| US20230232300A1 (en) | Ue fallback from dual-active protocol stack to conditional handover | |
| CN116095886A (en) | Method and apparatus for supporting radio resource control connection establishment for user equipment to network relay in wireless communication system | |
| WO2021024948A1 (en) | Communication system, communication terminal, and network | |
| CN118215087A (en) | Network node in a wireless communication system and method for a network node | |
| US20240205760A1 (en) | Method and apparatus for handling handover preparation in a wireless communication system | |
| KR20240096380A (en) | Method and apparatus for handling handover preparation in a wireless communication system | |
| US11564208B1 (en) | Method and apparatus for radio resource allocation to support UE-to-network relaying in a wireless communication system | |
| US20240129826A1 (en) | Method and device used in communication node for wireless communication | |
| EP4319286A1 (en) | Handover of a ue in a cellular network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication |