WO2023177028A1

WO2023177028A1 - Methods and systems for handling trp and beam change mechanism

Info

Publication number: WO2023177028A1
Application number: PCT/KR2022/013082
Authority: WO
Inventors: Neha Sharma; Vikalp Mandawaria; Anshuman Nigam
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2022-03-12
Filing date: 2022-09-01
Publication date: 2023-09-21
Anticipated expiration: 2024-09-12

Abstract

The present subject matter provides a method and system for UE based handover procedure for cell free or cell less or multi TRP per cell system. More particularly, the present subject matter provides a new signalling mechanism to handle cell based and beam level mobility in the cell free system for achieving high latency, high efficiency, and high throughput.

Description

METHODS AND SYSTEMS FOR HANDLING TRP AND BEAM CHANGE MECHANISM

The present subject matter relates to methods and systems for wireless communication and, more particularly, relates to methods and systems for design of TRP and beam change mechanism for Multi TRP (Transmission/Reception Point) system for a mobile station and other devices.

In recent years, several broadband wireless technologies have been developed for providing better applications and services to meet the growing requirements of broadband subscribers. Second generation wireless communication system has been developed to provide voice services while ensuring the mobility of users.

Third generation wireless communication system supports not only the voice service but also data service. In recent years, fourth wireless communication system has been developed to provide high-speed data service. However, currently, the fourth-generation wireless communication system suffers from a lack of resources to meet the growing demand for high-speed data services. This problem is solved by the deployment of fifth generation wireless communication system to meet the ever-growing demand for high speed data services. Furthermore, the fifth-generation wireless communication system provides ultra-reliability and supports low latency applications.

For the next generation of wireless communication systems i.e., 6G various technologies have been under consideration, for example, Visible Light Communication (VLC), Terahertz band (THz) i.e., frequencies from 100 GHz to 3 THz, Infrared wave and Ultraviolet wave, etc. Among all these technologies the THz band is envisioned as a potential technology for a diverse range of applications, which exist within the nano, micro as well as macro scales. The various features of THz band are that it may provide terabits per second (Tbps) data rates, reliable transmission, and minimal latency.

Frequencies from 100 GHz to 3 THz are promising bands for the next generation of wireless communication systems because of the wide range of the unused and unexplored spectrum. As per the literature available for THz band communication system these frequencies also offer the potential for revolutionary applications in the realm of devices, circuits, software, signal processing, and systems. The ultra-high data rates facilitated by mmWave and THz wireless local area and cellular networks enable super-fast download speeds for computer communication, autonomous vehicles, robotic controls, information shower, high-definition holographic gaming, entertainment, video conferencing, and high-speed wireless data distribution in data centers. In addition to the extremely high data rates, there are promising applications for future mmWave and THz systems that are likely to evolve in 6G networks, and beyond.

As per the literature available for THz band communication system, Terahertz band has specific characteristics like high path loss which includes the spreading as well as absorption loss. The terahertz band may be absorbed by raindrops, ice and grass and any medium containing water molecule. The link is more sensitive than the mmWave system so it is more fragile. Therefore, there are high chances that the THz link may be lost easily in such a sensitive system. Further, noise is an important characteristic of the THz band which may impact the interference model and signal-to-interference-plus-noise ratio (SINR) in the THz band. Due to the small wavelength at THz frequencies which is in the order of hundreds of micro-meters, THz waves scatter from almost any object in a real scenario, both indoor as well as outdoor causing scattering and reflection. Due to the characteristics of THz band a highly directional antenna that may generate very narrow beams in case of THz band is required.

The transmission and/or reception in a THz band system are based on narrow beams, which suppress the interference from neighbouring base stations and extend the range of a THz link. However, due to high path loss, heavy shadowing and rain attenuation, reliable transmission at higher frequencies is one of the key issues that need to be overcome to make the THz band wave systems a practical reality.

Cellular wireless networks are based on cellular topologies. The area is divided into cells where each cell is served by one base station (BS) or Access Point (AP) or Transmission/Reception Point (TRP). Each user is served by one or more AP depending upon the technology. There are many limitations of cellular system for example in a case when users who are at the centre of the cell may achieve desired data rates but users at the cell edge fail to experience desired data rates due to inter-cell interference and handover issues which limits the cell-edge performance. Further, the cell may cover a limited number of user terminals, hence has limited capacity. Furthermore, there is an issue of load balancing in cell networks as some APs will be overloaded and other APs relatively idle. Users will be connected to a single cell, so any obstacle in the signal path may impact the signal power. In mmWave bands and high frequencies, this may lead to loss of both signal and data. As the number of users is increasing billion of devices need high throughput to satisfy the ever-increasing need for high data rates. The cellular system based system cannot provide high data rates to the users particularly at the cell edge as these users will always experience interference from neighbouring cells hence impacting the throughput.

A conventional cellular system may not be able to handle the 6G requirements and applications due to the limitation of coverage and capacity. The cell size may further reduce in 6G technologies due to the usage of THz frequency bands. When the cell size is reduced to tens of meters in 5G cellular networks, quickly moving terminals lead to frequent handovers in 5G cellular networks and thus providing additional latency for wireless communications. Furthermore, frequent handovers introduce potential handover failures or constant back-and-forth handovers between adjacent cells which degrades the user experience. THz system may easily be impacted due to human or environmental obstacle; therefore, more communication paths are needed. Thus, there is a need to move from fixed topology to dynamic topology which may break the conventional cellular system design.

As per 3GPP TS 38.300, when Carrier aggregation (CA) is configured, a User Equipment (UE) only has one RRC connection with the network. At Radio Resource Control (RRC) connection establishment/re-establishment/handover, one serving cell provides the Non-Access Stratum (NAS) mobility information, and at RRC connection re-establishment/handover, the destination serving cell provides the security input. This cell is referred to as the Primary Cell (PCell). Depending on UE capabilities, Secondary Cells (SCells) may be configured to form together with the PCell a set of serving cells. The configured set of serving cells for a UE, therefore always consists of one PCell and one or more SCells.

The reconfiguration, addition, and removal of SCells may be performed by RRC. At intra-NR handover, RRC may also add, remove, or reconfigure SCells for usage with the target PCell. When adding a new SCell, dedicated RRC signaling is used for sending all required system information of the SCell i.e., while in connected mode, UEs need not acquire broadcast system information directly from the SCells.

Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell level mobility and beam level mobility. Cell Level Mobility requires explicit RRC signaling to be triggered, i.e., handover. A lot of signaling messages are exchanged during Intra gNB handover, inter-gNB handover. The handover mechanism triggered by RRC requires the UE at least to reset the MAC entity and re-establish Radio link control (RLC). RRC managed handovers with and without Packet Data Convergence Protocol (PDCP) entity re-establishment are both supported. For Dedicated Radio Bearers (DRBs) using RLC Acknowledged Mode (AM) mode, PDCP may either be re-established together with a security key change or initiate a data recovery procedure without a key change. For DRBs using RLC (Unacknowledged) UM mode and for Signaling Radio Bearers (SRBs), PDCP may either be re-established together with a security key change or remain as it is without a key change. Data forwarding, in-sequence delivery and duplication avoidance at handover may be guaranteed when the target gNB uses the same DRB configuration as the source gNB.

Timer based handover failure procedure is supported in new radio (NR). RRC connection re-establishment procedure is used to recover from handover failure.

Beam Level Mobility does not require explicit RRC signaling to be triggered. The gNB provides via the RRC signaling the UE with measurement configuration containing configurations of SSB/CSI resources and resource sets, reports and trigger states for triggering channel and interference measurements and reports. Beam Level Mobility is then dealt with at lower layers by means of a physical layer and MAC layer control signaling, and RRC is not required to know which beam is being used at a given point in time.

The current handover system is defined for cell-based architecture. Thus, when the UE moves from one cell to another cell it may be configured to perform handover procedure and for doing so RRC signaling message is always utilized, thereby increasing overhead of the network. On the other hand, in order to avoid RRC signaling message, beam level mobility may be utilized, however the beam level mobility is only possible within the cell which consist of single TRP.

Cell size may further reduce in 6G due to usage of THz frequency. When the cell size is reduced to tens of meters in 5G cellular NW, there are high chances of frequent HO. Frequent handovers, degrading the user experience in introducing the potential for handover failures or constant back-and forth handovers between adjacent cells. High mobility is challenging both within and between cells as it increases the risk for the service interruption and high signaling overhead. Existing beam management procedures are only applicable within a single cell and the RRC reconfiguration is required when moving between cells.

Thus, there is a need to define a new handover mechanism for the cell free system by defining new signaling mechanisms to handle the UE trigger cell based and beam level mobility to improve latency and efficiency with more usage of dynamic control signaling as opposed to RRC signaling.

Thus, as may be seen, there exists a need to overcome at least one of the aforementioned problems.

A method for managing Transmission Reception Point (TRP) for a user equipment (UE), comprising: receiving (step 402a), by the UE, a Radio Resource Control (RRC) connection reconfiguration message from a network node wherein the RRC connection reconfiguration message comprises one or more of a TRP Set, a Cell ID, a reference set, a candidate TRP set, a preamble, a configuration, a measurement configuration, and a candidate Transmission Configuration indicator (TCI) set, a preamble, a configuration, a measurement configuration, one of a TCI state index, a beam index, and an index, triggering (step 404a), by the UE, a UE based TRP change procedure based on the received RRC connection reconfiguration message, applying (step 406a), by the UE, the received configuration in the RRC connection reconfiguration message for initiating a TRP change to the one or more of the TRP set and the Cell ID upon meeting a pre-determined change condition, and completing (step 408a), by the UE, the TRP change of the UE to the one or more of the TRP Set and the Cell ID based on triggering a Random-Access Channel (RACH) procedure by the UE.

According to the systems and the method for handling trp and beam change mechanism, it can reduce latency and improve efficiency by defining new signaling mechanims to handle the UE trigger cell based and beam level mobility.

These and other features, aspects, and advantages of the present subject matter will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Figure 1 illustrates a fifth and a sixth-generation wireless communication system, in accordance with an existing technique;

Figure 2a illustrates a network topology 200a for multi TRP per cell having a common THz Cell ID and with non-prevalence of TRP identifier, in accordance with an existing technique;

Figure 2b illustrates another embodiment of network topology for multi TRP per cell having a common Cell ID for multiple TRP with a unique identifier for each TRP, in accordance with an existing technique;

Figure 2c illustrates a current handover system for cell based and beam based mobility as defined for cell based architecture, in accordance with an existing technique;

Figure 3 illustrates another embodiment of network topology for multi TRP per cell having a common Cell ID for multiple TRP for configured set of TRPs which may serve the UE, in accordance with an existing technique;

Figure 4a illustrates an operational flow diagram depicting a method for TRP management for a UE in a multi transmission reception point (TRP) network in accordance with an embodiment of the present subject matter; and

Figure 4b illustrates a method for a network to provide the configuration to support the UE based TRP change mechanism, in accordance with an embodiment of the present subject matter;

Figure 5 illustrates an operational diagram depicting a method for performing TRP change procedure based on RACH procedure, according to an embodiment of the present subject matter;

Figure 6 illustrates an operational flow diagram depicting a method for performing the TRP change procedure, in accordance with an embodiment of the present subject matter;

Figure 7 illustrates an operational flow diagram depicting a method performed at the network during TRP change, according to an embodiment of the present subject matter;

Figure 8a illustrates an embodiment depicting the details of MAC Control element (MAC CE) formats which may be used for TRP change or TRP activation/deactivation procedure, in accordance with an embodiment of the present subject matter;

Figure 8b illustrates another embodiment depicting the details of another MAC Control element (MAC CE) format which may be used for TRP change or TRP activation/deactivation or addition/deletion procedure, in accordance with an embodiment of the present subject matter;

Figure 8c illustrates another embodiment depicting the details of another MAC Control element (MAC CE) format, in accordance with an embodiment of the present subject matter;

Figure 8d illustrates another embodiment depicting the details of another MAC Control element (MAC CE) format for a TRP complete procedure, in accordance with an embodiment of the present subject matter;

Figure 9 illustrates details of a UE procedure to perform TRP switching or handover, in accordance with an embodiment of the present subject matter;

Figure 10a and 10b illustrates an operational flow diagram depicting a method for beam failure detection and recovery procedure management for a UE in a multi TRP network, in accordance with an embodiment of the present subject matter; and

Figure 11 illustrates an operational flow diagram depicting a method for beam failure detection and recover procedure when network configures Mmax, S and Mmax, S for BFRQ within the Multi TRP per cell, in accordance with an embodiment of the present subject matter;

Figure 12 illustrates an operational flow diagram depicting a method for a TRP management for a UE in a multi TRP network, in accordance with an embodiment of the present subject matter; and

Figure 13 is a diagram illustrating configuration of a terminal in a wireless communication system, in accordance with an embodiment of the present subject matter.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present subject matter. Furthermore, in terms of the construction of the system, one or more components of the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present subject matter so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

For example, the term "some" as used herein may be understood as "none" or "one" or "more than one" or "all." Therefore, the terms "none," "one," "more than one," "more than one, but not all" or "all" would fall under the definition of "some." It should be appreciated by a person skilled in the art that the terminology and structure employed herein is for describing, teaching and illuminating some embodiments and their specific features and elements and therefore, should not be construed to limit, restrict or reduce the spirit and scope of the claims or their equivalents in any way.

For example, any terms used herein such as, "includes," "comprises," "has," "consists," and similar grammatical variants do not specify an exact limitation or restriction, and certainly do not exclude the possible addition of one or more features or elements, unless otherwise stated. Further, such terms must not be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated, for example, by using the limiting language including, but not limited to, "must comprise" or "needs to include."

Whether or not a certain feature or element was limited to being used only once, it may still be referred to as "one or more features" or "one or more elements" or "at least one feature" or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element do not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, "there needs to be one or more..." or "one or more element is required."

Unless otherwise defined, all terms and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by a person ordinarily skilled in the art.

Reference is made herein to some "embodiments." It should be understood that an embodiment is an example of a possible implementation of any features and/or elements presented in the attached claims. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and/or elements of the attached claims fulfil the requirements of uniqueness, utility, and non-obviousness.

Use of the phrases and/or terms including, but not limited to, "a first embodiment," "a further embodiment," "an alternate embodiment," "one embodiment," "an embodiment," "multiple embodiments," "some embodiments," "other embodiments," "further embodiment", "furthermore embodiment", "additional embodiment" or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and/or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and/or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and/or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and/or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the attached claims. The attached claims and their legal equivalents may be realized in the context of embodiments other than the ones used as illustrative examples in the description below.

Embodiments of the present subject matter will be described below in detail with reference to the accompanying drawings.

Figure 1 illustrates an existing network environment 100 depicting a fifth-generation wireless communication system implemented not only in lower frequency bands but also in higher frequency (mm-Wave) bands, e.g., 10 GHz to 100 GHz bands, to accomplish higher data rates. Various techniques are being considered in the design of fifth generation wireless communication system in order to mitigate propagation loss of the radio waves, increase transmission distance, beamforming, massive Multiple-Input Multiple-Output (MIMO), Full Dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large-scale antenna and the like. In addition, the fifth-generation wireless communication system is required to address different use cases having different requirements in terms of data rate, latency, reliability, mobility, etc. It is further required that the design of the air-interface of the sixth-generation wireless communication system may be flexible enough to serve the UEs having different capabilities depending on the use case and market segment for which a UE cater service to the end customer. There are few examples of the use cases that the sixth-generation wireless communication system is required to address, for example, extreme enhanced Mobile Broadband (eeMBB), extreme massive Machine Type Communication (em-MTC), extreme ultra-reliable low latency communication (eURLLC), etc. In particular, the eeMBB requirements are like tens of Tbps data rate, low latency, high mobility, etc. These eeMBB requirements address the market segment representing the conventional wireless broadband subscribers that needs seamless internet connectivity. The em-MTC requirements are like very high connection density, infrequent data transmission, very long battery life, low mobility, etc. These MTC requirements address the market segment representing the Internet of Things (IoT)/Internet of Everything (IoE) envisioning connectivity to billions of devices. The eURLLC requirements are like very low latency, very high reliability, variable mobility, etc. These eURLLC requirements address the market segment representing the industrial automation application, vehicle-to-vehicle/vehicle-to-infrastructure communication foreseen as one of the enablers for autonomous cars. As seen in figure 1, a user equipment, for example, a smartphone may avail one or more network services using a base station, such as a 6gNode of the wireless communication network. To that end, both the user equipment and the 6gNode may include a processor and a transmitter, a receiver, or a transceiver.

The following description of figure 2a & figure 2b refers to a Multi TRP system per cell may use multiple TRPs (Transmission and Reception Points), together forming a large geographical area with continuous radio-coverage. Each TRP may be composed of 1 or more logical antennas enabling multiple beams to be formed. From the UE perspective, a cell covers a geographical area, but the UE may not be directly aware of the TRPs and of the use of beamforming and the UE mobility within the cell is transparent to the UE. Various options for Multi TRP per cell topology ave been shown with respect to Figure 2a.

Figure 2a illustrates a network topology 200a for multi TRP per cell having a common THz Cell ID and with non-prevalence of TRP identifier, according to an existing technique. Alternatively, a Common C-RAN ID may be there but without TRP identifier. Accordingly, a UE is not aware of TRP ID. In particular, the Figure 2a depicts one of the possible deployment that includes multiple TRPs (TRP1, TRP2 쪋TRPn) which is covered under one common THz cell ID. The region may be defined as one of C-RAN or Central Unit (CU) or core NW or Distributed unit (DU) or TRP controller or any other possible network entity (NW) entity. A range of THz Cell ID depends upon at least one of network topology, services or network architecture. The network may only report the THz cell ID to the UE, and the UE is not aware that which TRP is serving it, i.e., the UE is not aware of TRP ID. There may be other identifiers also for this particular region which may be based on NW decision. For example, the identifiers may be C-RAN ID or CU ID or DU ID. The TRPs under one C-RAN may be of same or different frequency.

Figure 2b illustrates another embodiment of network topology 200b for multi TRP per cell having a common Cell ID for multiple TRP with a unique identifier for each TRP, according to an existing technique. Alternatively, no cell ID may be there, however separate TRP identifier. Accordingly, a UE is aware of TRP ID. Figure 2b considers a scenario depicting, another possible deployment of multi TRP per cell with respect to Fig. 2a. The network topology provides multiple TRPs which may be covered under one common THz cell ID or any other cell ID or C-RAN ID which belongs to 5G or 6G or beyond 5g or any other wireless system. Each TRP may include a unique TRP ID, for example, TRP#1, TRP#2, TRP#3, TRP#4, and TRP#5. The region or area for Cell ID defined by C-RAN or Central Unit (CU) or core NW or Distributed unit (DU) or any other possible NW entity. Range of THz Cell ID depends upon the network topology, services, or network architecture. The network may report THz cell ID or Cell ID as well as TRP ID to the UE alternatively it may only report the TRP ID to the UE. Here cell or area or region may include multiple TRPs. It may be similar to cells include multiple beams. The network may provide the common identifier to decode the data instead of a cell specific RNTI or a UE specific identifier. All the TRPs within the system may be synchronized or not synchronized. The UE may be served with a single TRP or multiple TRP. Multi TRP transmission is a key feature for improving throughput, robustness, and reliability.

Thus, there is a need to define new cell level and beam level procedures to handle new network topology which may be based on cell free system. These new procedures may also be extended to the existing system as the current system are inefficient and cause signaling overhead, interruption in ongoing services. The present subject matter proposes a mechanism where the UE itself take the decision to perform TRP change or beam level change. Thus, there is a need to define a switching procedure associated with multiple TRPs for the following cases:

addition /deletion of TRP

TRP level mobility

Data transmission/reception with multiple TRP

In a non-limiting manner, the proposed solution is designed for below-mentioned deployments for cell less or free or multi TRP per cell system:

Common THz Cell ID, no TRP identifier: the UE is only aware of Cell ID

Common THz Cell ID, Separate TRP identifier: the UE is aware of Cell ID as well as TRP ID

Common C-RAN ID, No TRP identifier: the UE is aware of common identifier which the UE uses for camping and other procedures

Common C-RAN ID, separate TRP identifier: the UE is aware of common RAN ID as well as TRP ID,

Separate TRP identifier: the UE is aware of TRP ID which may act as Cell ID

Common THz Cell ID, same TRP identifier: the UE is aware of Cell ID as well as TRP ID.TRP ID is same within one region or under same central entity.

Furthermore, the deployment may consist of any combination of above-mentioned types of deployments. In a non-limiting manner, the aspects of the proposed subject matter, as described herein, are in context of cell which includes multiple TRPs and further multiple beams. As would be appreciated, the aspects of the proposed subject matter may be extended where the network might comprises at least one of one cloud cell or super cell which may include multiple TRPs or multiple small cells. Each cell may or may not include any cell boundary and each cell or TRP may include multiple or single beam. The cell and TRP terms used in this invention may be interchangeable.

Figure 2c illustrates a current handover system 200e as defined for cell-based architecture. Cell Level Mobility requires explicit RRC signaling to be triggered, i.e., handover. A lot of signaling messages are exchanged during Intra gNB handover, inter-gNB handover. Beam Level Mobility does not require explicit RRC signaling to be triggered, however the beam level mobility is only possible within the cell which consist of single TRP (Transmission reception point) i.e., Radio unit. Inter cell beam change is not possible and requires RRC signaling to perform the same.

Overall, cell and beam level mobility mechanism are inefficient for forthcoming technologies i.e., B5G/6G. TRP /cell size may further reduce in 6G due to usage of THz frequency. When the cell size is reduced to tens of meters in 5G cellular NW, there are high chances of frequent HO. Frequent handovers, degrading the user experience in introducing the potential for handover failures or constant back-and forth handovers between adjacent cells.

If the existing mechanism for TRP and beam level mobility for new topology are re-used, then it may cause service interruption and high signaling overhead due to RRC message Latency. Frequent frequency of handover degrades the user experience and causes signaling load at network side.

Figure 3 illustrates another embodiment of network topology 300 for multi TRP per cell having a common Cell ID for multiple TRP for configured set of TRPs which may serve the UE, in accordance with an existing technique. Each TRP may or may not include a unique identifier. In an example, the NW may configure multiple TRPs which may serve the UE. The number of TRPs which may serve the UE depends upon factors, such as UE capability, RF capability, load condition, data rate requirements, etc. In an example, either all TRPs or some TRPs or may be just one TRP may serve the UE. These configured TRP set comprises Active or Current TRP(s) or serving TRP and Candidate or Inactive TRP(s). The active TRP may be a TRP or set of TRPs which is currently serving the UE i.e., data transfer is taking place between the UE and the TRP(s). The candidate or Inactive TRP(s) comprises TRP(s) which are currently not serving the UE, but when the UE come into vicinity of these TRP(s) they may serve the UE. In an example, the activation and deactivation of these TRPs is based on NW decision which depends on signal condition, load, etc. The NW configures the TRP set based on a UE location and it may be changed based on location and signal condition of the UE.

In an example, a UE assistance based mechanism for multi TRP system is discussed. In an example, the NW configures the measurements for the UE and the UE performs the RRM measurements and beam level measurements in connected mode as well as idle mode. For each measurement type, one or several measurement objects may be defined (a measurement object defines e.g., the carrier frequency to be monitored). For each measurement object one or several reporting configurations may be defined (a reporting configuration defines the reporting criteria). In an example, three reporting criteria are used: a) event triggered reporting, b) periodic reporting, and c) event triggered periodic reporting. Based on these reports, the NW decides to perform a TRP change of the UE or redirect the UE. This process is time consuming and lot of signaling is being exchanged between the UE and NW. this method is not suitable for Multi TRP kind of system as coverage of TRP is very less and as a result, the TRP change may be frequent. The present subject matter proposes the UE based mechanism, which may trigger the TRP change procedure instead of sending measurement report to the network. In an example, the UE may indicate the NW to change the TRP or beam during below scenarios:

Beam Failure and recovery

TRP change procedure (intra/inter TRP) due to measurement condition or trigger as configured by the NW

Error cases like RLF and other error cases which triggers RRC re-establishment.

In such cases, the UE may indicate to the NW to perform the TRP change.

Furthermore, in an example, the UE may indicate to the NW to add, delete, or activate /deactivate the TRP or beam in cases such as:

Single connectivity to/from multi connectivity - which may be due to Data rate requirement for new application or new application

Change of TRP set - Add/delete or Activation/deactivation

This may be done if user finds the candidate TRPs of same or better signal condition as current TRP. It may send request to the NW to add, delete, modify the TRPs and current serving TRPs. On receiving such request, NW may be configured to determine whether this request may be honoured or not.

As referred before, Cell Level Mobility requires explicit RRC signaling to be triggered. Beam Level Mobility is only possible within the cell which consist of single TRP (Transmission reception point) i.e., Radio unit. Inter cell beam change is not possible and requires RRC signaling to perform the same.

Accordingly, there lies a need of a UE based TRP change procedure in multi TRP system. There lies a need of inter cell beam change mechanism during beam failure and recovery mechanism.

Figure 4a illustrates an operational flow diagram 400a depicting a method for TRP management for a UE in a multi transmission reception point (TRP) network in accordance with an embodiment of the present subject matter. Accordingly, the present subject matter refers a UE based TRP change procedure in multi-TRP system for changing a TRP for the UE.

In an embodiment, the method may include receiving (step 402a) by the UE, an RRC connection reconfiguration message containing one or more of a TRP Set and a Thz Cell ID. A network node (NW) configures the UE with the RRC connection re-configuration message to trigger the UE based TRP change procedure

Continuing with the above embodiment, the method may include triggering (step 404a), by the UE, the UE based TRP change procedure based on the received RRC connection reconfiguration message. In an embodiment, the RRC connection reconfiguration message further comprises one or more of a reference set, a candidate TRP set, preamble, configuration, measurement configuration, and a candidate TCI set, preamble, configuration, measurement configuration, TCI state index or beam index or index. The TRP set is sent with the RRC Connection Re-Config message when the UE is aware of the TRP ID. The Thz Cell ID is sent with the RRC Connection Re-config message, when the UE is not aware of the TRP ID.

Moving forward, the method may include applying (step 406a) the received configuration for initiating the TRP change to the one or more of the TRP set and the Thz Cell ID upon meeting a pre-determined TRP change condition. The TRP change condition is met when the measurement configurations are above a pre-determined threshold. The applying of received configuration for initiating the TRP change is based on evaluating by UE measurements in the RRC connection re-config message and ascertaining if the measurements fulfill the pre-determined TRP change condition to thereby satisfy for one of the TRP change and a beam level change and a TRP addition/deletion. An RRC layer communicates to the lower layers and upper layers, the new configuration associated with one or more of the TRP Set and the Thz Cell Id. The triggering of the RACH procedure upon applying the received configuration comprises initiating RACH procedure with a dedicated preamble configured in the RRC message.

In response to applying the received configuration, the method may include completing (step 408a) the TRP change of the UE to the one or more of the TRP Set and the Thz Cell ID based on triggering a RACH procedure by the UE. The triggering by the UE comprises triggering and initiating the UE based TRP change procedure based on the RACH or MAC CE procedure for the TRP or the beam change. The MAC CE comprises one or more of a single byte which refers to TRP ID or TCI index to which the UE may be configured to perform the switching or handover, and a format used for TRP change or TRP activation/deactivation or addition/deletion procedure.

The method may further include accepting by the network node the initiated RACH procedure for enabling the TRP change to a new TRP. The accepting by the network node further comprises applying by the network node the received configuration. Further, one or more of reset, re-establish the PDCP, RLC and MAC are performed. The MAC CE or RRC message with new C-RNTI and a status PDU are sent to the UE. In response, the UE receives the MAC CE or RRC message with new C-RNTI, reconfigures the PDCP, RLC and MAC, and sends a status PDU to the network node. In other embodiment, the initiated RACH procedure is rejected by the network node by sending the MAC CE or RRC message of L1 signaling.

Figure 4b illustrates a method 400b for a NW to provide the configuration to support the UE based TRP change mechanism, in accordance with an embodiment of the present subject matter. In an example, the NW may provide the configuration based on whether the UE is aware of TRP ID or not.

Case 1: the UE is aware of TRP ID and THz cell ID or C-RAN ID

In this case NW indicates the below configuration through RRC message or broadcast message i.e., SIB, MIB, SI or unicast message, to the UE.

Candidate TRP set: NW configure the UE with candidate TRP set and reference signals (RS) which may be used to evaluate and measure this TRP set

Preamble: NW may configure the dedicated preamble associated with these TRPs to avoid any delay or dedicated preamble for each UE. It may be associated with the TRP set also.

Configuration: Configuration associated with these TRPs or TRP set i.e., lower layer or high layers configuration. This may be associated with bearers, logical channel, transport or physical channel. It may include configuration of SDAP, PDCP, RLC, MAC, TCP layer etc.

Measurement configuration: Measurement configuration and Triggering criteria

Existing Measurement events or new events depict TRPx or Tx may be defined for the same

Different event conditions, triggering quantity, time to trigger, and triggering threshold, which may be common for all the TRPs or associated with separate TRPs.

Serving cell/ TRP configures the TCI states and CSI-RS resource set for neighbour TRPs (TRP set)

Candidate TCI state: NW configure the UE with Transmission Configuration indicator (TCI) state, reference signals (RS) which may be used to evaluate and measure neighbouring TRP. Each UL CSI will be associated with specific sequence which may be unique for the TRP. As the UE is unaware of any TRPs, the sequence provided in the UL CSI may be used to detect the specific TRP. This information may be configured with some index. Each of this configuration may be associated with certain index or object ID or TCI state ID which the UE may use to indicate to the NW.

Case 2: the UE is not aware of TRP ID and may include either THz cell ID or C-RAN ID or any other ID

In this case NW indicate below configuration through RRC message or broadcast message i.e., SIB, MIB, SI or unicast message.

Candidate TCI state: NW configure the UE with TCI state, reference signals (RS) which may be used to evaluate and measure neighbouring TRP. Each UL CSI will be associated with specific sequence which may be unique for the TRP. As the UE is unaware of any TRPs, the sequence provided in the UL CSI may be used to detect the specific TRP. This information may be configured with some index. Each of this configuration may be associated with certain index or object ID or TCI state ID which the UE may use to indicate to the NW. The serving TRP configures the CSI-RS or any other RS information for neighbour TRPs. Also, serving cell/ TRP configures the Transmission Configuration indicator (TCI) states for neighbour TRPs. The above information may be used to perform the TRP switching. The UE may be configured with a list of TCI-State configurations, CSI-RS-ResourceMapping, CSI-MeasConfig for beam and TRP measurements through RRC message for the serving cell and other cells or TRPs. The TRP-C controller or any other NW entity may share this information.

Preamble: NW may configure the dedicated preamble associated with these TCI candidates or TCI state index to avoid any delay or dedicated preamble for each UE. NW based on preamble may detect that the UE has made request for which TRP.

Measurement configuration: Measurement configuration and Triggering criteria

Different event conditions, triggering quantity, time to trigger, and triggering threshold, which may be common for all the TCI or associated with separate TCI or beams.

Figure 5 illustrates an operational diagram 500 depicting a method for performing the TRP change procedure based on RACH procedure, according to an embodiment of the present subject matter. In an example, a UE may be in a connected state with the network (NW) and the UE may be performing data transmission.

In the method 500 at step 502, a measurement condition of the UE is satisfied to perform TRP change procedure. These measurements may be performed as per NW configuration on configured TRP set or any other TRP or frequency.

Accordingly, at step 504, a RACH procedure on candidate TRP ID is initiated. The Random-Access procedure is initiated by a PDCCH order, by the MAC entity itself, or by RRC for the events in accordance with TS 38.300. The UE may initiate the contention based or contention free based on whether dedicated preamble is available or not. The preamble used to perform RACH procedure may be dedicated preamble which is configured by the NW. The UE may need not to send any signaling message and may directly perform RACH with dedicated preamble at MAC itself. NW based on this preamble may detect the TRP for which the UE wants to perform the switching. This procedure helps in reduction in signaling overhead and also reduce the latency.

At step 506, Once NW receives the RACH indicating the change in TRP, then NW may accept the same and provides a PDCCH grant on new TRP or MAC CE to the UE to complete the procedure.

At step 508, the UE once initiates the RACH procedure, monitor for a PDCCH transmission on the search space indicated by TPPSearchSpaceId of the cell or TRP identified by the C-RNTI while ra-ResponseWindow is running or monitor the PDCCH of the cell. If PDCCH transmission is addressed to the C-RNTI; and if the contention-free Random-Access Preamble for TRP switching or change request was transmitted by the MAC entity, the Random-Access procedure is considered successfully completed. The UE may also monitor for a PDCCH transmission on TRP for Random-Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running depending on initiation of RACH procedure. If the Random-Access Response contains a MAC sub PDU with Random-Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX. Consider this Random-Access Response reception successful.

Once RACH procedure is completed, the UE may start data transmission and reception. In this case C-RNTI remain same for different TRPs. NW may share T-RNTI which may be specific to the TRP.

In another example during the data transmission between the UE and the NW, the measurement condition to perform TRP change procedure may be satisfied. Subsequently, RACH procedure on candidate TRP ID is initiated by the UE.

At step 510, in the current example, due to the load or any other condition the NW may rejects the request from the UE and transmits the MAC CE (reject command) to the UE. This may be TRP switching failure or any other command. On receiving the same, the UE may revert to the older configuration and sync, if needed with the current TRP. In an embodiment, where it is determined that the UE is not able to synchronize to old /source TRP then it may declare the radio link failure procedure. NW instead of rejecting the command may also send the RRC message or MAC CE message to redirect the UE to new TRP. On receiving the same the UE may move to the new TRP and perform the procedure as mentioned for a TRP change command. The decision of sending RRC message or MAC command depends upon whether the UE already includes the new TRP configuration or not.

In an example, in the method 500, the RACH procedure is initiated at MAC level with cause TRP change or beam addition or beam modification or beam removal along with the TRP ID or index. In case of beam change, the UE may directly do RACH new TRP and NW may respond accordingly. In case of beam add/remove, the UE may do RACH on existing TRP and change as per NW command. The NW on receiving the same, may change the TRP and send response to the UE along with additional info (TA etc.). In an example, CFRA based RACH may be used if preamble is provided.

Figure 6 illustrates an operational flow diagram 600 depicting a method for performing the TRP change procedure based on MAC CE procedure, in accordance with an embodiment of the present technique.

As shown at step 602, a UE is in connected state with network (NW) and performing TRP data transmission. Further, a measurement condition of the UE is satisfied to perform TRP change procedure.

At step 604, the UE sends the MAC CE with command as TRP change or switching on existing configured resources and physical channel like PUSCH or PUCCH or any other new physical channel. The NW receives MAC CE (TRP change, Candidate TRP ID) from the UE.

At step 606, the method includes the network accepting the change and transmits the MAC CE (TRP change complete) to the UE. Subsequently, on receiving the same, the UE moves to new TRP ID, perform RACH procedure if needed and starts decoding data. The NW may also indicate the any change in timing advance or any other identifier as needed along with TRP switching complete. There is no need to perform the RACH, if the UE receives such parameters from the UE. If there is change in configuration then NW may respond the UE with RRC message along with configuration. Another possibility is NW may share the configuration with the UE along with some index and send the MAC CE to the UE by indicating the index of configuration. The UE on receiving the same may enable that configuration and apply the same i.e., configure all the layers

At step 608, Furthermore, in another example when the UE and the NW are exchanging data, the MAC CE (TRP change, Candidate TRP ID) is transmitted by the UE to the NW.

At step 610, in said example of step 608, due to the load or any other condition the NW may rejects the request from the UE and transmits the MAC CE (reject command) to the UE. This may be TRP switching failure or any other command. On receiving the same, the UE may revert to the older configuration and sync, if needed with the current TRP. If the UE is not able to synchronize to old /source TRP then it may declare the radio link failure procedure. NW instead of rejecting the command may also send the RRC message or MAC CE message to redirect the UE to new TRP. On receiving the same, the UE may move to the new TRP and perform the procedure as mentioned for a TRP change command. The decision of sending RRC message or MAC command depends upon whether the UE already may include new TRP configuration or not.

UE may also send say TRP addition, change, release request on existing resources which may be PUSCH or PUCCH or RACH. The UE command may be identified through different LC if it is sending MAC CE. For RACH procedures there may be dedicated preambles for each procedures which may be configured by NW or in re-establishment procedure RACH cause or cause may be set as beam change or TRP change, TRP addition, TRP removal or release, etc. on receiving these commands from the UE which may be based on RACH procedure or MAC CE, NW may either accept the same and respond with new MAC CE which indicates the TRP change complete, add, remove, activate, deactivate or reject. It also sends the information like TA if any parameter associated with TRP is changed. TRP controller at the NW or any other entity may take may decisions and inform the UE. The UE may move to new configuration only once NW accepts the same. If NW rejects the same, the UE may be configured to revert to old configuration as mentioned in this invention.

Figure 7 illustrates an operational flow diagram 700 depicting a method performed at the network during TRP change, according to an embodiment of the present subject matter. In an implementation, the method for TRP change or handover procedure when NW take decision to either send L3 message i.e., configuration in RRC message or L1/l2 message i.e., without any configuration of MAC, RLC, PHY, PDCP parameters

At step 702, the NW entity receives the MAC CE or RACH command from a UE and decided to perform TRP or cell switching or handover procedure.

At step 704. The NW may determine if the configuration associated with new TRP is same as that of the existing or current TRP or the UE already includes configuration for new TRP. In a non-limiting example the configuration may be related to RRC, PDCP, MAC, RLC or PHY or say security key refresh. If it is determined that there is any change in configuration associated with such layers then the NW may perform step 708. Further, if it is determined that there is no change in configuration associated with these layers then the NW may perform step 706.

At step 706, the NW may change the TRP and send MAC CE or any L1 message to inform about completion of procedure. It may send MAC CE which indicates the TRP change or handover change complete.

At step 708, the NW send the RRC message along with lower and high layer configuration to perform the TRP or cell switching procedure. The NW may configure the RRC message and send it to the UE as per conventional system. NW may or may not send the same TRP. Decision of sending same TRP or different TRP depends upon load condition, measurement report, data rate requirement etc., NW may also indicate the index of configuration, if the UE already may store configuration and ask the UE to enable it along with the TRP. This may provide the flexibility to the NW to enable the appropriate configuration to the UE as per data rate requirements or load.

At step 710, the UE after performing handover or TRP switching, may send the handover complete through MAC CE or RRC message. It may send RRC message like reconfiguration complete or the TRP switching complete.

Figure 8a illustrates an embodiment 800a depicting the details of MAC Control element (MAC CE) formats which may be used for TRP change or TRP activation/deactivation procedure, according to an embodiment of the present subject matter. In this case MAC CE consists of single byte which refers to TRP ID to which the UE may be configured to perform the switching or handover. The TRP switching MAC CE of one octet is identified by a MAC sub-header with LCID. Candidate or target Cell ID or TRP ID field indicates the identity of the target Serving Cell per TRP for which the UE may be configured to synchronize. The length of the field is 5 bits or 8 bits. In case it is 5 bits other bits may be reserved bits I. The MAC CE sub-header may include logical channel ID from which it may understand that this MAC CE is for TRP switching. Further, any value from reserve LC ID may be used. There may be additional Length field that may be included in sub-header that indicates the length of the corresponding MAC SDU or variable-sized MAC CE. This may be the case when additional information is added to acquire the beam or TRP ID, say TCI state. In case MAC CE is of fixed size then this length field is not required. The UE may send the same information through PDCP status PDU which indicates the TRP switching or RLC control data packet or through L1 signaling which may be like SR, RACH or PUCCH or PUSCH or any new indication. The UE may also some new physical channel or Reference signal to indicate the change of TRP ID.

Figure 8b illustrates another embodiment 800b depicting the details of another MAC Control element (MAC CE) format which may be used for TRP change or TRP activation/deactivation or addition/deletion procedure, according to an embodiment of the present subject matter. This refers MAC CE format which may be used for TRP change or TRP activation/deactivation or addition/deletion procedure. The number of octets needed in this MAC CE depends upon number of TRPs that the NW may configure for the UE. In the figure 8b for sake of brevity a single octet is shown assuming that number of TRPs are 8 at the maximum, however the number of TRPs may be more and the limitation of 8 TRs in the FIG is only for illustration purpose. RRC signals different number of TRPs and associated configuration to the network. Each TRP configuration may include a corresponding TRP index or TRP id to differentiate between the configurations. As shown in figure each TPi field refers to the TRP ID which may be configured by RRC message. The TPi field is set to 1 to indicate TRP switching or TRP change i.e., the indicated TRP may be the current TRP and NW may move to the TRP i.e., NW may associate and apply configuration of this TRP. The TPi field is set to 0 to indicate that the TRP with TRP index i shall be removed from the active set. Another interpretation is this TRP is no more the serving TRP and NW may release all the configuration associated with this TRP. This octet may also consist of R bit that is reserved bit which may be ignored by the NW. the UE may set the bit of TPi which it wants to make as a serving cell. This format may also be used to add /delete the active TRPs for the UE. Once the UE adds/deletes or change the TRP corresponding configuration may also change. The NW may then send the RRC message to provide the change configuration either through dedicated message or common message. Once the UE receives the RRC message or MAC CE to change the TRP or activate/deactivate or add/delete the TRP then it may indicate the upper layers to take further action like re-establish, data recovery or sending status PDU.

Figure 8c illustrates another embodiment 800c depicting the details of another MAC Control element (MAC CE) format which may be used for TRP change or TRP activation/deactivation procedure, according to an embodiment of the present subject matter. MAC CE consists of single byte which refers to TCI state index to which the UE may be configured to perform the TRP switching or handover. This may be used for the case when the UE is not aware which TRP is serving the UE, The NW configures the UE with TCI state, CSI-RS or RS related information which may be used to evaluate and measure the neighbouring TRPs. Each UL CSI may be associated with a specific sequence unique to each TRP. As the UE is unaware of any TRPs, the sequence provided in the UL CSI may be used to detect the specific TRP. The serving TRP configures the CSI-RS or any other RS information for neighbour TRPs. Also, serving cell/ TRP configures the Transmission Configuration indicator (TCI) states for neighbour TRPs. The above information may be used to perform the TRP switching. The UE may be configured with a list of TCI-State configurations, CSI-RS-ResourceMapping, CSI-MeasConfig for beam and TRP measurements through RRC message for the serving cell and other cells or TRPs. The TRP-C controller or any other NW entity may share this information. The NW may also indicate the TCI state or index associated with their configuration. The UE may not be aware of the TRP, but based on index NW may determine which TRP or beam may serve the UE. The UE may perform the measurements and based on that send the TCI state or index associated with specific TRP in MAC CE or L1 signaling as shown in Figure 8c. For TRP activation/deactivation or addition/deletion, the UE may send multiple sequences of these TCI state or index in MAC CE i.e., TCi to TCn. The TCi field is set to 1 to indicate TRP switching or TRP change i.e., the indicated TRP or beam may be the current the TRP or beam and NW may move to this TRP i.e., NW may associate and apply configuration of this TRP. The TCi field is set to 0 to indicate that the TRP with TRP index i shall be removed from the active set. Another interpretation is this TRP is no more the serving TRP and NW may release all the configuration associated with this TRP. Alternatively, the UE may send Index, to index through MAC CE. The NW may send the MAC CE including TCI state which the UE may evaluate. These TCI states may be associated with specific TRP. The MAC CE indicates that these TCI states need to be evaluated. The UE may be able to determine the beams as per existing mechanism and send the MAC CE with TCI state or index which may serve the UE.

Figure 8d illustrates another embodiment depicting the details of another MAC Control element (MAC CE) format for TRP complete procedure for the UE, the NW decides whether to perform path switching or not. It may also send MAC CE which signifies TRP switching completed and handover procedure complete.

Figure 9 illustrates a method 900 depicting details of a UE procedure to perform TRP switching or handover for multi TRP system, according to an embodiment of the present subject matter. In an implementation, the method for the UE behavior on initiate the TRP change or handover command comprises the following steps:

The UE camped on THz cell and performing data transmission and reception. There may be two cases:

Case 1: the UE is aware of TRP ID and THz cell ID or C-RAN ID.

Step 902: NW configures the UE to support the UE based TRP change procedure.

NW send the configuration over RRC message and configure the UE with the UE based TRP change procedure. The UE may receive RRC Connection Reconfiguration (TRP set, preamble, configuration, measurement configuration). The UE evaluate the measurements ad per configured criteria.

Step 904: the UE Trigger and initiation of the UE based TRP change procedure based on RACH or MAC CE procedure.

Once the Measurement condition trigger satisfies for TRP or beam level change or TRP addition/deletion, the RRC layer informs all the lower layers and upper layers to apply for the new configuration.

Once the UE applies the new configuration if any, initiate RACH procedure. This RACH procedure may be initiated with dedicated preamble as configured in the RRC message.

Alternatively, the UE may send the MAC CE for TRP or beam change.

Step 906: NW decision and associated procedure to handle command from the UE.

On receiving the same, NW may accept the change, move to new TRP and apply the corresponding configuration and perform reset, re-establish the PDCP, RLC and MAC and send MAC CE or RRC message with complete or once the UE detects any data with new C-RNTI, it assumes the TRP change procedure is completed. NW may also send some status PDU.

Once the UE receives the above message or detect some data with new C-RNTI or common identifier, it will reset, re-establish the PDCP, RLC and MAC and may perform the data recovery process and send the status PDU. The UE may also do this step when it applies the new configuration.

NW may also reject the UE request and send Mac CE or RRC message of L1 signaling to indicate the reject message.

As the configuration may already have been applied by the UE, it may be configured to revert old configuration and continue data transmission and reception and start measurements.

Case 2a: the UE is not aware of TRP ID and THz cell ID or C-RAN ID.

Step 902: NW configures the UE to support the UE based TRP change procedure.

the UE may receive RRC Connection Reconfiguration (TRP set, preamble, configuration, measurement configuration). The UE evaluate the measurements ad per configured criteria.

Alternatively, the UE may send the MAC CE for TRP or beam change.

Step 906: NW decision and associated procedure to handle command from the UE.

Case 2b: the UE is not aware of TRP ID and may include either THz cell ID or C-RAN ID or any other ID.

Step 902: NW configures the UE to support the UE based TRP change procedure.

UE may receive RRC Connection Reconfiguration (candidate TCI set, preamble, configuration, measurement configuration, TCI state index or beam index or index).

UE evaluate the measurements as per configured criteria.

Once the Measurement condition trigger satisfies for TRP or beam level change or TRP addition/deletion, the RRC layer informs all the lower layers and upper layers to apply for the new configuration associated with particular TCI or TCI index.

Alternatively, the UE may send the MAC CE for TRP or beam change.

Step 906: NW decision and associated procedure to handle command from the UE.

On receiving the same, NW may accept the change, move to new TRP and apply the corresponding configuration and perform reset, re-establish the PDCP, RLC and MAC and send MAC CE or RRC message with complete or once the UE detects any data with new C-RNTI, it assumes the TRP / TCI state change procedure is completed. NW may also send some status PDU.

As the configuration may already have bee applied by the UE, it may be configured to revert old configuration and continue data transmission and reception and start measurements. Alternatively, the UE may apply new configuration only once NW accepts the same.

In an example, the above-described procedure is applicable in any scenario like addition/deletion or activation/deactivation of procedure.

Beam failure and Recovery procedure

In state of art, inter cell beam change is not possible and requires RRC signaling to perform the same. As per prior art 3GPP 38,300, for beam failure detection, the gNB configures the UE with beam failure detection reference signals (SSB or CSI-RS) and the UE declares beam failure when the number of beam failure instance indications from the physical layer reaches a configured threshold before a configured timer expires. SSB-based Beam Failure Detection is based on the SSB associated to the initial DL BWP and may only be configured for the initial DL BWPs and for DL BWPs containing the SSB associated to the initial DL BWP. For other DL BWPs, Beam Failure Detection may only be performed based on CSI-RS. After beam failure is detected, the UE:

-triggers beam failure recovery by initiating a Random-Access procedure on the PCell;

-selects a suitable beam to perform beam failure recovery (BFR0 (if the gNB provides dedicated Random-Access resources for certain beams, those will be prioritized by the UE). Upon completion of the Random-Access procedure, beam failure recovery is considered complete.

The above procedure is applicable only to serving cell. The UE only search for beams which are associated with serving cells. To perform inter cell beam level switching, the UE may be configured to declare the RLF and perform RRC re-est. procedure which cause user interruption, signaling overhead and latency to the system. In multi TRP system as multiple TRPs will be available in cell, so the UE may be able to perform beam selection among multiple TRPs. However, in state of the art inter cell beam change is not possible and requires RRC signaling.

Figure 10a illustrates an operational flow diagram 1000a depicting a method for beam failure detection and recovery procedure management for a UE in a multi TRP network, in accordance with an embodiment of the present subject matter.

In an embodiment, the method may include receiving (1002a) by the UE, a configuration message containing one or more of a TRP Set and a TCI (Thz Cell ID) in a multi TRP system. The configuration message comprises one or more reference signals identifying at least one of candidate beams in serving cell or a neighbouring cell for recovery, and radio-access parameters.

Further, the method includes applying (1004a) the received configuration to select one of the candidates beams in serving cell or neighbouring cell in case of a beam-failure indication. The selecting between the serving cell and neighbour cell beams comprise detecting SSB from the candidate beams in serving cell or neighbouring cell. Based thereupon, one or more of a TRP and a TCI (Thz Cell ID) is identified (1006a) for initiating a TRP change based on the selection of the candidate beam. The beam-failure indication is based on one or more of a communication from a lower layer about a beam failure instance, and a count of beam failure instance reaching a threshold.

Further, the method comprises triggering (1008a) a RACH procedure by the UE to the identified one or more of the TRP and the TCI (Thz Cell ID).

Figure 10b illustrates an operational flow diagram depicting a method 1000b for beam failure detection and recovery procedure and introduces inter cell beam change without explicit signaling, thereby providing a design of inter cell beam change mechanism during beam failure and recovery mechanism. The UE will search for the beams in neighbour beam list also so that it may select the beam from neighbour list.

At step 1002b, in an example, the MAC entity may be configured by RRC per Serving Cell with a beam failure recovery procedure which is used for indicating to the serving gNB of a new SSB or CSI-RS when beam failure is detected on the serving SSB(s)/CSI-RS(s). The Beam failure is detected by counting beam failure instance indication from the lower layers to the MAC entity. In an example, the MAC receives Beam failure instance indication from lower layers. In an example, when counter for beam failure instance indication reaches at maximum level (beamFailureInstanceMaxCoun), it starts the beam recovery procedure.

At step 1004b, in an example, the method 1000 includes initiating a Random-Access procedure on the SpCell or current TRP or neighbour TRP or neighbour cell or candidateBeamRSList or neigbourBeamRSList or any other configured Scell or S -TRP or cells configured in COMP.

At step 1006b, In an example, if at least one of:

the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or neigbourBeamRSList.

the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList or neigbourBeamRSList, is available, then the method 1000 includes selecting an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or neigbourBeamRSList, or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList or neigbourBeamRSList.

At step 1008b, furthermore, the method 1000 includes performing the Random-Access Preamble transmission procedure.

At step 1010b, in an example, if it is not able to detect SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or neigbourBeamRSList, or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList or neigbourBeamRSList, then it may declare the radio link failure to upper layers or go to idle state. In such a case, the UE then follows the conventional procedure as defined in the current system.

The present subject matter provides a method where the UE instead of searching beams only in the serving cell may search for other configured TRPs or neighbour cell. Below are the parameters:

- rsrp-ThresholdSSB: an RSRP threshold for the selection of the SSB for 4-step RA type. If the Random-Access procedure is initiated for beam failure recovery, rsrp-ThresholdSSB used for the selection of the SSB within candidateBeamRSList refers to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE; This list may include serving TRP as well as neighbour TRP values.

- rsrp-ThresholdCSI-RS: an RSRP threshold for the selection of CSI-RS for 4-step RA type. If the Random-Access procedure is initiated for beam failure recovery, rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE; This list may include a serving TRP as well as neighbour TRP values.

CandidateBeamRSList, candidateBeamRSListExt-r16: This may be understood as a list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated RA parameters. The network configures these reference signals to be within the linked DL BWP (i.e., within the DL BWP with the same bwp-Id) of the UL BWP in which the BeamFailureRecoveryConfig is provided. The network configures these reference signals to be linked with neighbouring TRP or cells i.e. inter TRP or cell.The candidateBeamRSList may include a list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated Random-Access parameters which may include a beam list of serving TRP or neighbouring TRP or cell. The serving TRP configures the CSI-RS or any other RS information for neighbour TRPs. Also, the serving cell/ TRP configures the Transmission Configuration indicator (TCI) states for neighbour TRPs.

NeigbourBeamRSList, candidateBeamRSList: A list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated RA parameters. The network configures these reference signals to be within the linked neigbour cell or TRP DL BWP (i.e., within the DL BWP with the same bwp-Id) of the UL BWP in which the BeamFailureRecoveryConfig is provided.

TS 38.321 change, it may be applicable for any 38.xxx or any other 3GPP spec

In an example, if the selected RA_TYPE is set to 4-stepRA, the MAC entity shall:

1> if the Random-Access procedure was initiated for SpCell or current TRP or neighbour TRP or cell beam failure recovery (as specified in clause 5.17); and

1> if the beamFailureRecoveryTimer (in clause 5.17) is either running or not configured; and

1> if the contention-free Random-Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs may be explicitly provided by RRC; and

1> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList is available:

2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList.

And/Or

If the selected RA_TYPE is set to 4-stepRA, the MAC entity shall:

1 > if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in neigbourBeamRSList.or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in neigbourBeamRSList.is available

2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in neigbourBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in neigbourBeamRSList.

In an example, a beam failure detection and a recovery procedure are discussed.

In an example, the MAC entity shall, for each Serving Cell configured for beam failure detection:

if beam failure instance indication may be received from lower layers and counter for beam failure instance indication is reach at maximum level.

2> start or restart the beamFailureDetectionTimer.

2> increment BFI_COUNTER by 1.

2> if BFI_COUNTER >= beamFailureInstanceMaxCount:

3> if the Serving Cell is SCell:

4> trigger a BFR for this Serving Cell;

3> else:

4> initiate a Random-Access procedure (see clause 5.1) on the SpCell or current TRP or neighbour TRP or neighbour cell or as per candidateBeamRSList or neigbourBeamRSList.

TS 38.331 change, it may be applicable for any 38.xxx or any other 3GPP spec

- BeamFailureRecoveryConfig

The IE BeamFailureRecoveryConfig is used to configure the UE with RACH resources and candidate beams for beam failure recovery in case of beam failure detection. See also TS 38.321 [3], clause 5.1.1.

BeamFailureRecoveryConfig information element

-- ASN1START

-- TAG-BEAMFAILURERECOVERYCONFIG-START

BeamFailureRecoveryConfig::= SEQUENCE {

rootSequenceIndex-BFR INTEGER (0..137) OPTIONAL, -- Need M

rach-ConfigBFR RACH-ConfigGeneric OPTIONAL, -- Need M

rsrp-ThresholdSSB RSRP-Range OPTIONAL, -- Need M

candidateBeamRSList SEQUENCE (SIZE(1..maxNrofCandidateBeams)) OF PRACH-ResourceDedicatedBFR OPTIONAL, -- Need M

ssb-perRACH-Occasion ENUMERATED {oneEighth, oneFourth, oneHalf, one, two,

four, eight, sixteen} OPTIONAL, -- Need M

ra-ssb-OccasionMaskIndex INTEGER (0..15) OPTIONAL, -- Need M

recoverySearchSpaceId SearchSpaceId OPTIONAL, -- Need R

ra-Prioritization RA-Prioritization OPTIONAL, -- Need R

beamFailureRecoveryTimer ENUMERATED {ms10, ms20, ms40, ms60, ms80, ms100, ms150, ms200} OPTIONAL, -- Need M

…,

[[

msg1-SubcarrierSpacing SubcarrierSpacing OPTIONAL -- Need M

]],

[[

ra-PrioritizationTwoStep-r16 RA-Prioritization OPTIONAL, -- Need R

candidateBeamRSListExt-r16 SEQUENCE (SIZE(0..maxNrofCandidateBeamsExt-r16)) OF PRACH-ResourceDedicatedBFR OPTION- -- Need

]]

}

neigbourBeamRSList SEQUENCE (SIZE(0..maxNrofCandidateBeamsExt-r16)) OF PRACH-ResourceDedicatedBFR OPTION- -- Need

PRACH-ResourceDedicatedBFR::= CHOICE {

ssb BFR-SSB-Resource,

csi-RS BFR-CSIRS-Resource

}

BFR-SSB-Resource::= SEQUENCE {

ssb SSB-Index,

ra-PreambleIndex INTEGER (0..63),

...

}

BFR-CSIRS-Resource::= SEQUENCE {

csi-RS NZP-CSI-RS-ResourceId,

ra-OccasionList SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER (0..maxRA-Occasions-1) OPTIONAL, -- Need R

ra-PreambleIndex INTEGER (0..63) OPTIONAL, -- Need R

...

}

-- TAG-BEAMFAILURERECOVERYCONFIG-STOP

-- ASN1STOP

neigbourBeamRSList: A list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated RA parameters. The network configures these reference signals to be within the linked neighbour cell or TRP DL BWP (i.e., within the DL BWP with the same bwp-Id) of the UL BWP in which the BeamFailureRecoveryConfig is provided.

The beam selection within neigbourBeamRSList or candidateBeamRSList may also be controlled based on timers or with some configurated parameters. The UE first try to search beam with in candidateBeamRSList or beams which are associated with current serving cell and start the timer Txxx or Tcandidate beam search timer. This timer may be configured by upper layers or share by NW through RRC message or may hold some default value. Once this timer expires then the UE search for the beam which are associated with neighbour TRP or cell which may be part of neighbourBeamRSList or candidateBeamRSList and perform the RACH procedure.

In further to this, it may also be controlled by certain parameters say beamrecoverycandidatemaxcount and beamrecoveryneigbourmaxcounnt, or beamrecoverymaxcount as configured by upper layers or provided by NW through RRC message or any other signaling. The UE may first try for candidateBeamRSList and try till beamrecoverycandidatemaxcount and then may try for neigbourBeamRSList and try till beamrecoveryneigbourmaxcounnt. The UE may maintain counter while trying for candidateBeamRSList and neigbourBeamRSList.

A UE may transmit beam recovery request upon detecting a beam failure event (e.g., the quality of the serving beam is worse that a pre-configured threshold) and identifying a new candidate beam (e.g., the quality of the candidate beam is better than a pre-determined threshold). The BFRQ transmission may be over dedicated PRACH or PUCCH resources to reduce connection re-establishment latency. After transmitting the beam recovery request, the UE monitors the BS's response during configured beam recovery response window. If the beam failure recovery attempt is successful, then the connection is re-established but if the attempt fails, and the response window expires, the UE attempts BFRQ again via an alternate beam until the pre-configured recovery timer expires. In this case, radio link failure (RLF) is declared.

The embodiments herein achieve a method and system for configuring the UE with BFR procedure via one or more TRPs within a Multi TRP per cell. The UE may be connected to one or more TRPs within the Multi TRP per cell. The UE may select one or more TRPs within the Multi TRP per cell for beam failure recovery based on the reference signals measured results (e.g., CSI-RS, SSBs, etc.). The UE may perform BFR via one or more TRPs within the Multi TRP per cell. The UE, can, therefore, quick switch between LoS connections within the Multi TRP per cell.

In the beam failure recovery procedure, the UE first detects a beam failure condition over one or multiple serving TRPs within the Multi TRP per cell. In one embodiment, the UE may be requested to monitor a beam failure detection RS and measure the RSRP of some configured beam covered in the beam failure RS to assess if a beam failure trigger condition is met.

The UE may be configured to monitor multiple BPLs (beam pair links) on the PDCCH. Each BPL corresponds to a pair of one TRP Tx beam and one UE Rx beam. The UE may be configured to monitor the LI RSRP of all configured BPLs. The UE may include more than one serving BPLs as serving control channels with a particular TRP.

The quality of the serving BPL may be acquired by monitoring all or a subset of RSs. The CSI-RS or SSBs which are spatially quasi-collocated with control channel (e.g., PDCCH) DMRS may be used for beam failure detection.

Besides, identifying new beams on the serving TRPs for BFR, the UE may also identify a new candidate beam on the in-active TRPs within the Multi TRP per cell. In one embodiment, the UE may be requested to monitor the LI RSRP of one or more than one RSs from the in-active TRPs within the Multi TRP per cell.

In one example, the network may signal a subset of CSI-RS resource indices for a set of in-active TRP within the Multi TRP per cell and the UE may be requested to monitor the LI RSRP of those CSI-RS resources for the in-active TRP within the Multi TRP per cell.

In one example, the TRP may signal a subset of SS-block time indices and the UE may be requested to monitor the LI RSRP of signals in those SS-blocks for the in-active TRP within the Multi TRP per cell.

To trigger the BFRQ transmission, the UE monitors both serving BPLs and good currently unused BPLs with a serving TRP or one of the in-active TRPs within the Multi TRP per cell.

The condition to transmit beam failure recovery request message may be one of more of the followings.

In one example, the condition may be the LI RSRP measurement of all configured BPLs with serving TRPs is below a configured RSRP threshold for configured time duration, e.g., N slots and a new candidate beam is identified.

In one example, the condition may be out of the configured BPLs, a set of BPLs is defined as the primary BPL set. The LI RSRP measurement of primary BPL set is below a configured RSRP threshold for configured time duration and new candidate beam is identified.

In one example, the condition may be the LI RSRP measurement of primary BPL set is below a configured RSRP threshold for configured time duration.

In one example, the condition may be the LI RSRP measurement of pre-defined number of BPLs with a particular serving TRP is below a configured RSRP threshold for a configured time duration.

In one embodiment, the UE may be configured with an LI RSRP threshold and time duration for each BPL separately.

Once the triggering condition is satisfied, the UE transmits a beam failure recover request (BFRQ) to the identified TRPs/beams within the Multi TRP per cell over beam failure recovery resources. For the transmission of the beam failure recovery request message, the network may configure the UE with both dedicated PUCCH or PRACH resources. The UE is configured with dedicated BFR resources e.g., UL control channel, beam failure recovery resources in PRACH or contention based PRACH resources which may be used for BFRQ transmission.

Note that the UE may be configured with any combination of the above BFR resources with TRPs within the Multi TRP per cell. The network may identify one or more TRPs within the Multi TRP per cell to be configured with BFR related parameters (e.g., BFR resources, etc.) and the UE may select one or more candidate beams from these pre-configured TRPs within the Multi TRP per cell for beam failure recovery.

In one example, the serving TRP may be configured with contention-free PRACH resources for beam failure recovery while one or more in-active TRPs are configured with contention based PRACH resources for BFR.

In another example, the UE is configured with contention free PRACH resources on one or more in-active TRPs within Multi TRP per cell.

In another example, only serving TRP is configured with PRACH resources for BFR.

In some embodiments, the network may pre-configure a set of rules for selecting in-active TRP BPLs for BFR. For example, the rules may include the order of TRPs by which the UE may perform BFR. In other embodiments, the UE may select TRPs within Multi TRP per cell for BFR in an opportunistic manner based on the different BFR resources available for different TRPs. In one example, if PUCCH resource occurs first, it uses PUCCH otherwise use PRACH. In another example, the UE may attempt BFR via TRPs with which contention-free resources are available first when candidate BPLs with multiple TRPs are identified.

Note that the network and the UE may determine the order of TRPs for BFR within Multi TRP per cell based on the system requirements. In one case, to avoid ping-pong effects within the Multi TRP per cell, it might be preferable for UE to achieve beam recovery via the TRP with which beam failure has occurred instead of recovery via an in-active TRP. In such a case, the UE attempts BFRQ via the TRP with which beam failure occurred first and only attempts BFRQ via other TRPs when the maximum attempts for BFRQ via TRP with which beam failure occurred may be exhausted. In another case, to provide quick LoS handovers within Multi TRP per cell, the UE attempts BFRQ via an in-active TRP with contention-free PRACH resources first.

In some embodiments, the UE may be configured with one or more parameters by the NW for BFRQ transmission to different TRPs within the Multi TRP per cell. For example, a length of time window to monitor the beam recovery response from a TRP may be configured. It may be a number of slots, N. It may be a length of time in milliseconds. The UE may be requested to monitor and receive beam recovery response within the configured time window after sending a beam recovery request. It may be signaled through system information, high layer signaling (e.g., RRC), MAC-CE or LI signaling.

In one example, a maximum number of beam recovery request transmission, Mmax may be configured for BFRQ transmission within the Multi TRP per cell. Typically, to avoid ping-pong effects within the Multi TRP per cell, the UE would prefer to achieve beam recovery via the TRP with which beam failure occurred. In such a case, the UE attempts BFRQ via the TRP with which beam failure occurred and the network might set a separate limit on BFRQ transmissions via this TRP, Mmax, S, and BFRQ would be attempted via other TRPs within Multi TRP per cell once Mmax, S is exhausted.

Figure 11 illustrates an operational flow diagram 1100 depicting a method for beam failure detection and recover procedure when NW configures Mmax, S and Mmax, S for BFRQ within the Multi TRP per cell, in accordance with an embodiment of the present subject matter. In this case, the UE prefers to achieve BFR via the serving TRP instead of selecting an alternate TRP for BFR within Multi TRP per cell, if feasible.

At step 1102a, the UE first attempts BFRQ via the identified candidate beams of the TRPs with which the beam failure occurred until the maximum attempts for BFR via the TRP, set by the network, are exhausted or the timer for beam failure expires. The UE may receive the BFRQ-RAR via any of the active TRPs (if any) or via the candidate TRPs candidate team with which BFR was attempted.

At steps 1104a till 1108a, the UE expects the response to BFRQ within a response window.

At step 1110a, the UE attempts BFR via the next best candidate beam, in case no response is received. The Control again transfers to step 1102a to trigger another iteration of steps 1102a till 1110a.

With the maximum number of attempts via TRP with which beam failure occurred, exhausted at step 1108a, the UE instead of declaring RLF, performs step 1102b.

At step 1102b, the UE attempts beam failure via candidate beams of other BFR-configured TRPs within the Multi TRP per cell until maximum attempts for BFR are exhausted or the timer runs out vide steps 1104b till 1108b.

At step 1104b, the UE may select these TRPs/beams within the Multi TRP per cell based on the pre-configured rules set by network or opportunistically based on the BFR resources available with different TRPs as described above. For these BFRQ attempts, the UE may receive the BFRQ-RAR via control signaling via active TRPs (if any) or via the candidate TRPs candidate team with which BFR was attempted.

Steps 1106b correspond to step 1106a.

Steps 1108b till step 1110b in terms of inactive TRPS correspond to steps 1108a till 1110a.

In another example, the network might set separate limits on beam failure recovery attempts (in

steps

1108a, 1108b) via each of the TRPs within the BFR-configured TRPs. In another example, the network might also set separate timers (in

steps

1106a, 1106b) for BFR via TRPs with which beam failure has occurred and for BFR via any other TRP within Multi TRP per cell. In another example, the network might set separate timers for BFR via each TRP within the Multi TRP per cell. It may be signaled through system information, high layer signaling (e.g., RRC), MAC-CE or LI signaling.

In another example, the UE may be requested to calculate the Tx power of beam recovery request based on the path loss measured from the selected new candidate beam with a serving or an in-active TRP. The parameters to determine this may be configured specifically for beam recovery request by the NW. The parameters may also be re-used of the parameters for PUSCH, SRS, PUCCH or PRACH transmission.

The UE may increase the Tx power of beam recovery request transmission in the re-transmission of beam recovery request. The UE may re-calculate the Tx power if the UE changes the selection of new candidate beam within Multi TRP per cell in the re-transmission of beam recovery request.

Figure 12 illustrates an operational flow diagram 1200 depicting a method for a TRP management for a UE in a multi TRP network, in accordance with an embodiment of the present subject matter. In an embodiment, the TRP management may be performed by a network node communicating with a UE. In an embodiment, the TRP management may include changing a TRP of the UE.

In an embodiment, the method includes determining (step 1202), by a network node, whether the UE is aware of a TRP ID in response to receiving a RACH command from the UE.

In an embodiment, upon determining that the UE is aware of a TRP ID, the method includes transmitting (step 1204), by the network node, an RRC connection reconfiguration message containing a TRP set to the UE. In an embodiment, the network node may configure the UE with the RRC connection re-configuration message to trigger a UE based TRP change procedure. In an embodiment, the RRC connection re-configuration message includes one or more of a reference set, a candidate TRP set, a preamble, a configuration, a measurement configuration, and a candidate TCI set, a preamble, a configuration, a measurement configuration, a TCI state index, or a beam index, or and index. In an embodiment, where it is determined that the UE is not aware of the TRP ID, the method includes transmitting a Thz Cell ID with the RRC Connection configuration message. In an embodiment, the network node may be configured to determine whether the UE is aware of the TRP ID or not upon receiving one of a MAC CE and a RACH command from the UE.

Moving forward, the method includes receiving (1206), by the network node, another RRC connection reconfiguration message comprising an indication about completion of the handover from the UE. In an embodiment, the method may include accepting by the network node, an initiated RACH procedure for enabling the TRP change to a new TRP. In an embodiment, the RACH procedure may be initiated by the UE with a dedicated preamble configured in the RRC message to apply the received configuration for initiating the TRP change.

In an embodiment, accepting the initiated RACH procedure may include applying by the network node the received configuration. Further, accepting the initiated RACH procedure may include performing one or more of reset, re-establish the PDCP, RLC and MAC. Moving forward, the accepting may also include sending MAC CE or RRC message with new C-RNTI and a status PDU to the UE.

Moving forward, upon accepting the initiated RACH procedure, the method may include transmitting, by the network node, to the UE, the MAC CE or RRC message with new C-RNTI. In an embodiment, the initiated RACH procedure may be rejected by the network node by sending the MAC CE or RRC message of L1 signaling. Further, the method may include receiving by the network node, from the UE, a status PDU to the network node upon reconfiguration of the PDCP, the RLC and the MAC.

Figure 13 is a diagram illustrating the configuration of a terminal 1300 in a wireless communication system according to an embodiment of the present subject matter. Hereinafter, it is understood that terms including "unit" or "er" at the end may refer to the unit for processing at least one function or operation and may be implemented in hardware, software, or a combination of hardware and software.

Referring to Fig. 13, the terminal 1300 may include a controller 1302 (e.g., at least one processor), a storage unit 1304 (e.g., storage), data 1306 and, module(s) 1308, and a communication unit 1310 (e.g., communicator or communication interface). By way of example, the terminal 1300 may be a User Equipment, such as a cellular phone or other device that communicates over a plurality of cellular networks (such as a 4G, a 5G or pre-5G network or any future wireless communication network). In an embodiment, the controller 1302, the storage unit 1304, the data 1306, and the module(s) 1308, and the communication unit 1310 may be communicably coupled with one another.

As would be appreciated, the terminal 1300, may be understood as one or more of a hardware, a software, a logic-based program, a configurable hardware, and the like. In an example, the controller 1302 may be a single processing unit or a number of units, all of which could include multiple computing units. The processor may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, processor cores, multi-core processors, multiprocessors, state machines, logic circuitries, application-specific integrated circuits, field-programmable gate arrays and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the controller 1302 may be configured to fetch and/or execute computer-readable instructions and/or data 1306 stored in the storage unit 1304.

In an example, the storage unit 1304 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static Random-Access memory (SRAM) and/or dynamic Random-Access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, hard disks, optical disks, and/or magnetic tapes. The storage unit 1304 may store data, such as a basic program, an application program, configuration information, and the like for operating the terminal 1300. The storage unit 1304 may be configured as a volatile memory, a non-volatile memory, or a combination of a volatile memory and a non-volatile memory. The storage unit 1304 may include the data 1306. In addition, the storage unit 1304 may provide data stored therein in response to a request from the controller 1302.

The data 1306 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of, the controller 1302, the storage unit 1304, the module(s) 1308, and the communication unit 1310.

The module(s) 1308, amongst other things, may include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The module(s) 1308 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.

Further, the module(s) 1308 may be implemented in hardware, instructions executed by at least one processing unit, for e.g., controller 1302, or by a combination thereof. The processing unit may be a general-purpose processor which executes instructions to cause the general-purpose processor to perform operations or, the processing unit may be dedicated to performing the required functions. In another aspect of the present disclosure, the module(s) 708 may be machine-readable instructions (software) which, when executed by a processor/processing unit, may perform any of the described functionalities.

In some example embodiments, the module(s) 1308 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities.

The controller 1302 may control overall operations of the terminal 1300. For example, the controller 1302 may transmit and receive a signal via the communication unit 1310. Further, the controller 1302 records data in the storage unit 1304 and reads the recorded data. The controller 1302 may perform the functions of a protocol stack required by a particular communication standard. To this end, the controller 1302 may include at least one processor or micro-processor or may be a part of the processor. Also, a part of the communication unit 1310 and the controller 1302 may be referred to as a communication processor (CP).

Referring to figure 4a, the communication unit 1310 may be configured to receive an RRC connection reconfiguration message containing one or more of a TRP Set and a Thz Cell ID. Further, the controller 1302 may be configured to trigger a UE based TRP change procedure based on the received RRC connection reconfiguration message. Continuing with the above embodiment, the controller 1302 may be configured to apply the received configuration for initiating the TRP change to the one or more of the TRP set and the Thz Cell ID upon meeting a pre-determined TRP change condition. Moving forward, the controller 1302 may be configured to complete the TRP change of the UE to the one or more of the TRP Set and the Thz Cell ID based on triggering a RACH procedure by the UE.

Referring to figure 10a, the communication unit 1310 may be configured to receive, a configuration message containing one or more of a TRP Set and a TCI (Thz Cell ID) in a multi TRP system. Continuing with the above embodiment, the controller 1302 may be configured to apply the received configuration to select one of the candidate beams in serving cell or neighbouring cell in case of a beam-failure indication. Moving forward, the controller 1302 may be configured to identify one or more of a TRP and a TCI (Thz Cell ID) for initiating a TRP change based on the selection of the candidate beam. In response to identifying, the controller 1302 may be configured to trigger a RACH procedure by the UE to the identified one or more of the TRP and the TCI (Thz Cell ID).

While specific language has been used to describe the present subject matter, any limitations arising on account thereto, are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein. The drawings and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.

Claims

A method for managing Transmission Reception Point (TRP) for a user equipment (UE), comprising:

receiving (step 402a), by the UE, a Radio Resource Control (RRC) connection reconfiguration message from a network node wherein the RRC connection reconfiguration message comprises one or more of a TRP Set, a Cell ID, a reference set, a candidate TRP set, a preamble, a configuration, a measurement configuration, and a candidate Transmission Configuration indicator (TCI) set, a preamble, a configuration, a measurement configuration, one of a TCI state index, a beam index, and an index;

triggering (step 404a), by the UE, a UE based TRP change procedure based on the received RRC connection reconfiguration message,

applying (step 406a), by the UE, the received configuration in the RRC connection reconfiguration message for initiating a TRP change to the one or more of the TRP set and the Cell ID upon meeting a pre-determined change condition; and

completing (step 408a), by the UE, the TRP change of the UE to the one or more of the TRP Set and the Cell ID based on triggering a Random-Access Channel (RACH) procedure by the UE.
The method as claimed in claim 1, wherein the TRP set is sent with the RRC Connection reconfiguration message when the UE is aware of the TRP ID.
The method as claimed in claim 1, wherein the Cell ID is a ThZ cell id and is sent with the RRC Connection reconfiguration, when the UE is not aware of the TRP ID.
The method as claimed in claim 1, wherein applying the received configuration for initiating the TRP change is based on the steps of:

evaluating, by the UE, measurements in the RRC connection reconfiguration message;

ascertaining, by the UE, if the measurements fulfil the pre-determined TRP change condition and thereby satisfies for one of the TRP change, a beam level change, and a TRP addition/deletion; and

communicating by an RRC layer to the lower layers and upper layers the new configuration associated with one or more of the TRP Set and the Thz Cell Id.
The method as claimed in claim 1, further comprises:

triggering the RACH procedure with a dedicated preamble configured in the RRC reconfiguration message upon applying the received configuration.
The method as claimed in claim 1, wherein triggering by the UE comprises:

triggering and initiating the UE based TRP change procedure based on one of the RACH and a MAC Control Element (CE) procedure for one of the TRP change and the beam change.
The method as claimed in claim 1, further comprising:

receiving by the UE, one of a MAC CE, and a RRC message with a new Cell Radio Network Temporary Identifier (C-RNTI) transmitted by the network node upon accepting the initiated RACH procedure;

reconfiguring a Packet Data Convergence Protocol (PDCP), a Radio Link Control (RLC) and a MAC; and

sending a status PDU to the network node.
The method as claimed in claim 4, wherein the TRP change condition is met when the measurement configurations are above a pre-determined threshold.
A method for managing Transmission Reception Point (TRP) for a user equipment (UE), comprising:

receiving (step 1002a) by the UE, a configuration message containing one or more of a TRP Set and a Cell ID in a multi TRP system, said configuration message comprising one or more reference signals identifying at least one of:

candidate beams in serving cell or a neighbouring cell for recovery; and

radio-access parameters;

applying (step 1004a) the received configuration to select one of the candidate beams in serving cell or neighbouring cell in case of a beam-failure indication;

identifying (step 1006a) one or more of a TRP and a Cell ID for initiating the TRP change based on the selection of the candidate beam; and

triggering (step 1008a) a RACH procedure by the UE to the identified one or more of the TRP and the Cell ID.
The method as claimed in claim 9, wherein the Cell ID is a Thz Cell ID.
The method as claimed in claim 9, wherein selecting the candidate beam between the serving cell and neighbour cell beams comprises detecting SSB from the candidate beams in the serving cell or the neighbouring cell.
The method as claimed in claim 9, wherein the beam-failure indication is based on one or more of:

communication from lower layer about beam failure instance; and

a count of beam failure instance reaching a threshold.
A method for a TRP management for a UE in a multi TRP network, comprising:

determining (step 1202), by a network node, whether the UE is aware of a TRP ID in response to receiving a RACH command from the UE;

transmitting (step 1204), by the network node, an RRC connection reconfiguration message containing a TRP set to the UE in response to determining that the UE is aware of the TRP ID; and

receiving (step 1206), by the network node, another RRC connection reconfiguration message comprising an indication about completion of the handover from the UE.
The method of claim 12, wherein the network node configures the UE with the RRC connection re-configuration message to trigger a UE based TRP change procedure, wherein the RRC connection re-configuration message comprises one or more of:

reference set;

a candidate TRP set, a preamble, a configuration, a measurement configuration; and

a candidate TCI set, a preamble, a configuration, a measurement configuration, and one of a TCI state index, a beam index, and an index.
The method as claimed in claim 12, further comprises transmitting the Thz Cell ID with the RRC Connection configuration message, if the UE is not aware of the TRP ID.